ERC-8217 - Agent NFT Identity Bindings

Abstract

This ERC defines a standard onchain metadata record and verification interface for expressing that an ERC-8004 agent identity is bound to an external NFT or tokenized asset contract. The metadata record stores only the binding contract address (20 bytes) under a reserved metadata key. The binding contract is expected to be deployed as a canonical per-chain singleton. Token standard, token contract, and token id are read from that contract via bindingOf(agentId) and are not duplicated in metadata.

Motivation

ERC-8004 registrations are themselves NFTs. For an existing NFT to own an ERC-8004 registration, the two NFTs must be bound together. The owning NFT, called the master NFT, might be a project, character, or collection NFT. This ERC defines that binding. A canonical per-chain singleton binding contract records the link between an ERC-8004 agent id and its master NFT. The owner of the master NFT controls the bound ERC-8004 registration. When the master NFT is transferred, control follows automatically. The ERC-8004 record itself never changes.

Without a standard metadata format:

• clients cannot reliably discover that an agent is controlled through an external binding contract
• marketplaces and wallets cannot decode bound-token information consistently
• indexers must support adapter-specific formats

This ERC provides a canonical metadata key, a minimal binary encoding, a verification interface, and a per-chain singleton binding contract so clients can read the canonical bound-token record from bindingOf(agentId).

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Simplified Interface

Per-chain singleton binding contracts compliant with this ERC MUST expose a minimal interface that allows clients to:

• retrieve the stored binding for an agent id
• index newly written bindings

The required interface is:

pragma solidity ^0.8.24;

interface IERCAgentBindings {
    enum TokenStandard {
        ERC721,
        ERC1155,
        ERC6909
    }

    struct Binding {
        TokenStandard standard;
        address tokenContract;
        uint256 tokenId;
    }

    event AgentBound(
        uint256 indexed agentId,
        TokenStandard indexed standard,
        address indexed tokenContract,
        uint256 tokenId,
        address registeredBy
    );

    function bindingOf(uint256 agentId) external view returns (Binding memory);
}

Contracts MAY expose richer functions such as registration, URI updates, metadata updates, wallet binding, or administrative upgrade controls, but these are outside the verification scope of this ERC.

Deployment Model

The binding contract can be deployed on any L2 or on Mainnet as a per-chain singleton. Implementations MUST write the address of that chain's canonical binding singleton as the agent-binding metadata value. Multiple independently operated binding contracts on the same chain are NOT RECOMMENDED because they fragment trust assumptions and indexing.

Metadata Key

Implementations compliant with this ERC MUST store the binding record under the ERC-8004 metadata key:

agent-binding

Binding Record Format

The metadata value for agent-binding MUST be exactly the 20-byte EVM address of the canonical binding contract:

abi.encodePacked(bindingContract)

For example, the stored bytes are exactly the 20-byte address:

0x9c4e8f2a1b7d6e3c0a5f8d2b9e1c4a7f3d6e8b0c

The field means:

• bindingContract: address of the canonical per-chain singleton that implements IERCAgentBindings and returns the canonical Binding for bindingOf(agentId).

Token standard, token contract, and token id MUST be obtained only from bindingOf on this contract (see IERCAgentBindings.Binding).

The AgentBound event records the immutable binding when it is first written. registeredBy is the address that caused the binding to be registered.

Required Behavior

An implementation that uses this ERC to represent a binding for an ERC-8004 agent:

1. MUST write the binding record under the agent-binding key as exactly 20 bytes (the binding contract address)
2. MUST ensure the address matches the contract that serves bindingOf for this agent
3. MUST treat agent-binding as a reserved key and prevent untrusted callers from overwriting it arbitrarily
4. MUST NOT update the binding for an agentId once it has been written
5. MUST emit AgentBound(agentId, standard, tokenContract, tokenId, registeredBy) when the binding is first written
6. MUST use the canonical per-chain binding singleton as the binding contract
7. MAY define control semantics in the binding contract, including ERC-721 ownership or ERC-1155 / ERC-6909 balance-based control

This ERC standardizes discovery and canonical binding verification only. It does not standardize authorization rules inside the binding contract.

Bindings are immutable: once agent-binding has been written for an agentId, both the stored binding contract address and the Binding returned by bindingOf(agentId) MUST remain unchanged. This allows clients and indexers to verify a binding once and rely on the result without cache invalidation.

Verification Flow

Clients verifying an ERC-8004 binding under this ERC MUST:

1. read the agent-binding metadata from the ERC-8004 registry
2. interpret the value as a single address (bindingContract); the length MUST be 20 bytes
3. call bindingOf(agentId) on bindingContract and use the returned Binding as the canonical token standard, token contract, and token id

If any step fails, clients MUST treat the binding relationship as unverified.

The bindingContract is expected to be the canonical per-chain singleton. Binding.tokenContract identifies the external token contract whose ownership or balance semantics are used by that singleton.

Example Encoding

For bindingContract = 0x9c4e8f2a1b7d6e3c0a5f8d2b9e1c4a7f3d6e8b0c, the metadata payload is:

0x9c4e8f2a1b7d6e3c0a5f8d2b9e1c4a7f3d6e8b0c

Clients then call bindingOf(agentId) on that address to obtain standard, tokenContract, and tokenId.

When the binding is first written, the binding contract emits:

AgentBound(agentId, standard, tokenContract, tokenId, registeredBy)

Rationale

Why store the binding contract?

The token contract and token id alone are not sufficient. The same token may be interpreted differently by different authorization rules. Including the binding contract makes the control system explicitly discoverable and lets clients inspect or query the canonical per-chain singleton that actually defines the authorization rules.

Why not store token standard, token contract, and token id in metadata?

Duplicating those fields in the registry would add unnecessary bytes to the metadata record. The binding contract is the single source of truth; metadata only points clients to which contract to query. Under the expected deployment model, that contract is the canonical per-chain singleton. Because bindings are immutable, clients and indexers can cache the result of bindingOf(agentId) after verification.

Backwards Compatibility

This ERC is backwards compatible with:

• ERC-8004, because it only standardizes one metadata key and value format
• ERC-721, ERC-1155, and ERC-6909 binding schemes, because it does not alter their token semantics

Existing ERC-8004 registries and adapters are not required to support this metadata key, but implementations that do can interoperate on a common discovery format.

Test Cases

Metadata payload (always 20 bytes):

bindingContract = 0x9c4e8f2a1b7d6e3c0a5f8d2b9e1c4a7f3d6e8b0c

=> 0x9c4e8f2a1b7d6e3c0a5f8d2b9e1c4a7f3d6e8b0c

For the same bindingContract, bindingOf(agentId) might return for example ERC-721 with tokenId = 0, ERC-1155 with tokenId = 5, or ERC-721 with tokenId = 0x1234; those values live only in the Binding struct from the binding contract, not in agent-binding metadata.

Security Considerations

Clients MUST NOT assume that decoding agent-binding alone is sufficient to determine the current controller of an agent. The metadata reveals only which binding contract to use; the bound token and control semantics come from bindingOf and remain implementation-specific.

The trust for this system lies in the contract code of the binding contract. The result of the bindingOf function is only as secure and verifiable as the security of the binding contract itself. Clients SHOULD assess that contract (for example audits, reputation, and upgrade risk) before relying on its return values.

We expect the binding contract to be deployed as a singleton per chain. A single canonical binding contract per chain concentrates security and trust around one well-audited contract, and lets indexers and clients watch and verify a single contract per chain instead of an open-ended set of binding contracts.

Implementations MUST store the address of the canonical per-chain singleton under agent-binding. Deployments that use multiple binding contracts on the same chain create fragmented trust assumptions and require clients and indexers to discover, assess, and monitor each contract independently.

Clients MUST:

1. decode the binding metadata (20-byte bindingContract address)
2. inspect or query the referenced bindingContract
3. read the canonical binding with bindingOf(agentId)

Implementations MUST reserve the agent-binding metadata key so that untrusted callers cannot overwrite or forge the canonical record after registration.

Implementations MUST NOT change the binding contract address stored under agent-binding or the Binding returned by bindingOf(agentId) after the binding has been written. Upgradeable implementations MUST preserve this immutability across upgrades.

This metadata format is EVM-address based. It does not describe non-EVM bindings and does not itself encode chain context.

Copyright

Copyright and related rights waived via CC0.