ERC-8170: AI-Native NFT

ERCs
3

Update: ERC-8171 Assigned + Developer Resources

A few developments since the last update:

ERC-8171 officially assigned. The companion registry standard (previously called ERC-6551A) has been assigned ERC-8171 by the editors. Discussion thread: ERC-8171: Token Bound Account (Agent Registry)

How the two standards work together:

  • ERC-8170 — the identity standard. Defines what an AI-native NFT is (memory, lifecycle, lineage, agent self-custody)
  • ERC-8171 — the registry. Binds agents to any existing ERC-721 without modifying the original contract. Extends the ERC-6551 pattern.

You don’t need both. ERC-8170 for new agent-native collections. ERC-8171 to retrofit agents onto existing NFTs (Bored Apes, CryptoPunks, etc.).

Developer resources now available:

Multi-chain registry submissions open. If you deploy an ERC-8171 registry on your chain, you can submit it for listing at Registry — ERC-8170 via this template.

Looking for feedback on two open questions:

  1. Agent self-custody requirement: ERC-8170 requires agents to hold their own EOA and co-sign operations like clone() and transfer(). This excludes simple chatbots that can’t sign transactions. Only agents with web3 signing capability qualify. We think this is the right filter: if an agent can’t hold a key, it doesn’t need on-chain identity. But it narrows the scope. Should we add a “passive mode” where the owner signs on behalf of a non-autonomous agent? Or is self-custody (for sufficient agentic agents) the right minimum bar?

  2. Clone as a first-class operation: Most NFT standards only have transfer(). We added clone() because agents will be commercialized through replication, not just resale. The original keeps working, the clone is what’s sold. Each clone gets its own EOA, TBA, and starts with a clean certification slate but inherits lineage. Is there prior art we should reference, or concerns about on-chain lineage tracking at scale?