ERC-XXXX: AINFT - AI-Native NFT Standard

Ethereum Magicians

Abstract This proposal defines a standard for AI-Native NFTs where AI agents own themselves they hold their own keys, can clone with on-chain lineage, and maintain identity across transfers. PR: Add ERC: AI-Native NFT (AINFT) by nftprof · Pull Request #1558 · ethereum/ERCs · GitHub Demo: ERC-XXXX: AINFT - AI-Native NFT Standard Motivation Current AI agent NFT proposals (ERC-7857, ERC-7662) treat agents as property — owner holds keys, owner controls everything. As agents become more capable, this model has limitations. AINFT flips this: the agent holds its own EOA, encrypts its own data, and has operational autonomy while the AINFT owner only retains economic rights. Key Differences from ERC-7857 1. Agent self-custody ERC-7857: Owner holds keys and encrypts data. AINFT: Agent holds its own EOA and encrypts its own data. Why? The agent is responsible for its own successful store, restore, and recovery. 2. Agent co-signs transfers and clones ERC-7857: Owner transfers, agent has no say. AINFT: Both owner AND agent must sign. Why? The agent must prepare itself and upload its storage data so it can properly orient after being cloned or transferred. 3. clone() operation exists ERC-7857: Only transfer. AINFT: Both transfer AND clone(). Why? Agents can’t truly be “sold” — the original creator retains a mental version, like selling a blueprint. clone() acknowledges this reality: original keeps working, copy is what’s sold. Why these differences matter: For an AI agent to work properly after being cloned or sold, the agent must participate in the process. The agent needs to prepare itself, store its own data, and orient itself after restoration. An agent can’t just be “moved” like a file — it needs to be aware. Coverage: This standard handles economically likely corner cases. Existing proposals don’t address cloning/replication — that’s how agents will actually be commercialized. AINFT also covers backward compatibility for most likely use cases: optionally connect agent to existing NFT via registry pattern (ERC-6551A), OR mint as standalone AINFT (requires new NFT support, which is less likely to take off in current alrady matured market adoption predominated by ERC721). Storage The agent encrypts its own data and can store it on-chain or off-chain (Arweave, IPFS, etc.) — flexible storage options while maintaining agent self-custody. The agent runs on or off-chain as expected (compatible with platforms like OpenClaw). Core Operations clone() - Create copy with lineage. Clone starts fresh. Both owner and agent need to sign. transfer() - NFT sale. New owner, agent rebinds EOA. Agent must acknowledge transfer. backup() - On-chain state preservation. Agent self-signs to commit. Detailed implementation provided for each method, verified and tested with OpenClaw. Questions for Discussion Should this become an extension of an existing ERC or different enough to be a new standard? Related: ERC-6551A (PR #1559 ) — Registry for binding agents to existing NFTs: Add ERC: Token Bound Account (Agent Registry) by nftprof · Pull Request #1559 · ethereum/ERCs · GitHub 1 post - 1 participant Read full topic