AgenticNFT.aiLearn
Ethereum ERC Standards for Agentic NFTs
A practical comparison of the supplied standards and proposals. Scroll horizontally to compare all eight columns. ERC-8004 appears in three rows to make its identity, reputation, and validation functions easy to scan.
What can each ERC standard do?
| Standard / component | What it means | What you can do with it | Main role | What it enables | Useful data / interface | Agentic NFT use case | Implementation boundary |
|---|---|---|---|---|---|---|---|
| ERC-721 | A basic NFT: one token with one current owner; optional metadata can describe art or files. | Mint and transfer tokens, approve marketplace operators, and display metadata. Add separate systems for agent behavior. | Token ownership | Unique NFTs, ownership checks, approvals, and transfers. | ownerOf(tokenId)safeTransferFrom(...)Optional tokenURI(tokenId) | Represent an agent character or master NFT as an ownable asset. | Does not supply AI execution, agent trust, or operational resources. |
| ERC-8004 | A public ID card for an agent, represented by an NFT and linked to its service profile. | Register and discover agents, advertise MCP/A2A endpoints, and transfer the identity. Re-verify its payment wallet after a direct transfer. | Agent identity and discovery | Register a persistent agent identifier and advertise services. | agentIdagentURIservice endpoints getMetadata(...)verified agentWallet | Let directories and other agents discover an agent's public profile. | Advertised capabilities are not proof of functioning software; direct identity transfers clear the verified wallet. |
| ERC-8004 | Public feedback attached to a registered agent identity. | Read ratings and task-performance signals; build your own scoring method using selected reviewers. | Feedback infrastructure | Publish, retrieve, revoke, and respond to client feedback. | Values, tags, evidence linksgiveFeedback(...) | Show service ratings and performance signals tied to an agent ID. | Does not prescribe one trust score; applications must assess reviewers and spam. |
| ERC-8004 | A shared record of requests for work checks and the selected validator’s responses. | Request independent checks and display validation evidence; choose a validator and verification method suitable for the task. | Independent work checks | Record validation requests and validator responses. | validationRequest(...)validationResponse(...) | Expose evidence that a selected validator checked a task. | Validation methods, incentives, and guarantees come from separate systems. Payments are outside ERC-8004. |
| ERC-8048 | Labeled records stored onchain for a token; a context record can contain an agent description or “soul” text. | Read individual fields in one call. Define custom records; check the contract’s write policy rather than assuming every holder can edit them. | Onchain metadata | Read extensible key-value records attached to token IDs. | metadata(tokenId,key)MetadataSet event | Query individual agent fields without parsing one large document. | Updates and write policy depend on implementation. |
| 721T | Shared labels that help applications interpret an NFT’s agent context, endpoints, and chain accounts. | Publish agent instructions, MCP/A2A service URLs, payment-enabled endpoints, and account references in a recognizable format. | Agent metadata conventions | Describe context, communication endpoints, and chain accounts. | contextendpoint[mcp]endpoint[a2a]endpoint[x402]address[<chain-id>]optional account[<chain-id>][<index>] | Publish an agent's instructions, service routes, and account references. | A profile, not a separate interface. Metadata does not execute tools, enforce permissions, or transfer offchain memory. |
| ERC-8217 / 8004A | A verifiable link from an ERC-8004 identity to an external master NFT or token. | Find and verify the bound token, then inspect the binding contract to resolve control. Arrange separate handover for offchain resources. | External NFT identity binding | Discover and verify the relationship between an ERC-8004 identity and a master token. | agent-binding: binding contract addressbindingOf(agentId): token standard, contract, and ID | Connect an existing character NFT to an agent registration; use the binding contract to resolve control. | Binding is immutable; authorization is implementation-specific. Servers, secrets, and contractual rights need separate handover. 8004A is its nickname. |
| ERC-6551 Review | Gives an NFT a smart-contract wallet. Its assets stay at that wallet address when control follows the NFT. | Hold tokens, other NFTs, and onchain credentials; interact with applications through the account. | Token-bound wallet | Attach asset custody and transaction execution to an NFT. | createAccount(...)account(...)token()isValidSigner(...) | Give a character an inventory or an agent a treasury. | Account implementation and approvals govern control; a seller can remove assets before a sale. |
| ERC-7857 Final | An agent NFT with encrypted private metadata and verifiable data-transfer mechanisms. | Transfer or clone private models, memory, or character definitions using a supported verifier/prover system. | Private agent data | Verify data ownership and transfer validity with TEE or ZKP mechanisms. | verifyOwnership(...)verifyTransferValidity(...) | Sell an agent with verifiable access to encrypted data. | Needs storage, proofs, and key management. Cannot prove a seller erased previously accessed data; privacy depends on the verification design. |
| ERC-8041 Draft | A capped collection associated with ERC-8004 agent identities, with recorded mint positions. | Launch a limited collection; expose supply, collection membership, and sequential mint numbers. | Limited agent collections | Enforce supply limits and track collection provenance. | getAgentMintNumber(...)getCollectionSupply() | Create a numbered Genesis agent collection. | Verify membership against the collection contract; agent metadata alone can be edited. |
| ERC-8170 Draft proposal | An AI-native NFT design with agent signing, memory references, lifecycle, and clone lineage. | Transfer an agent under the proposed signing flow or create a separate offspring clone with lineage. | Agent lifecycle | Distinguish transfer from reproduction; track memory commitments. | Proposed clone(), transfer(), backup() flows | Replicate a working agent while recording ancestry. | Cloning is distinct from selling the parent. Runtime, encrypted storage, and actual rights require implementation. |
| ERC-8171 Draft proposal | A registry that attaches an AI agent identity to an existing NFT using the ERC-6551 account pattern. | Add agent capabilities to existing collections; bind, unbind, rebind, and track clones without replacing the art contract. | Retrofit agent identity | Associate agent EOAs and memory references with existing ERC-721 tokens. | bindNew()bindWithApproval()unbind()rebind()updateMemory() | Turn an existing character NFT into an agent-linked identity. | Not inherently an ERC-8004 registration; verify lifecycle and post-sale rebinding behavior. |
| ERC-8172 Draft proposal | A proposed waiting period between scheduling an agent metadata change and its activation. | Expose pending profile changes so buyers and counterparties can inspect them before activation. | Delayed metadata changes | Introduce pending metadata and an activation delay. | Pending update and activation timing | Reduce surprises from immediately changed agent profiles. | A delay provides notice, not proof that the new profile is honest or safe. |
| ERC-8181 Draft proposal | A circular ownership design: an NFT is held by its own token-bound account, with authorized executors and recovery. | Experiment with autonomous account operation, state/action commitments, scoped executors, and a liveness recovery mechanism. | Self-sovereign agent structure | Anchor state and actions while using executor permissions. | State/action hashes; executor permissions; recovery configuration | Operate an agent without a conventional human-held NFT. | Recovery and executor security are central; self-ownership does not itself supply intelligence or runtime. |
| ERC-8183 Draft | A job contract that holds a budget in escrow until an evaluator completes or rejects submitted work. | Create and fund tasks, submit deliverables, release payment on approval, or refund on rejection/expiry. | Agent task commerce | Coordinate client, provider, evaluator, and escrow. | createJob()fund()submit()complete()reject()claimRefund() | Pay an agent for accepted work rather than sending its full budget upfront. | Evaluator judgment and contract security still matter; the protocol does not guarantee work quality. |
Ownership + identity + metadata + binding + trust signals.
These layers describe and connect an Agentic NFT. Running its AI, preserving chat history, enforcing permissions, and operating paid services require application infrastructure.
Terminology. 721T is the agent profile within ERC-8048. 8004A labels master NFTs registered under ERC-8217. MCP, A2A, and x402 are complementary protocols. Helixa, AgentDNA, Intuition, and Multipass are products or ecosystem systems rather than ERC standards.
Related reading: agentic vs normal vs wrapped and what persists when the owner changes.