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 Live Demo Webpage: https://blockchainsuperheroes.github.io/ainft-mvp/
- EOA — Externally Owned Account (a wallet controlled by a private key, not a contract)
- TBA — Token Bound Account (wallet owned by an NFT, via ERC-6551)
- SBT — Soulbound Token (non-transferable NFT, used for credentials/reputation)
- AINFT — AI-Native NFT (this 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.
Requirement: Agents must have their own EOA to participate in this standard. The agent signs to bind, clone, and transfer — this requires minimal agentic capability (web3 signing). Agents that cannot produce their own signature cannot use AINFT.
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 → ERC-8171 (PR #1559, now assigned)), 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.
┌─────────────────────────────────────────────────────────────────────┐
│ FOUR PARTIES │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 1. PLATFORM (deploys contract) │
│ • Signs attestation for new mints │
│ • Sets rules, fees, cloning limits │
│ • Controls openMinting, openCloning flags │
│ • Does NOT have decrypt access to agent memory │
│ │
│ 2. CORE TRUSTLESS ENGINE (Genesis Contract) │
│ • Ensures ONLY current owner can access agent secrets │
│ • Derives keys from on-chain state (owner + nonce) │
│ • Increments nonce on transfer → old owner's key invalidated │
│ • No oracle needed — pure math from blockchain state │
│ │
│ 3. OWNER (holds the NFT) │
│ • Can call deriveDecryptKey() to access agent memory │
│ • MUST sign clone() — agent cannot do it alone │
│ • Controls agent's "career" — approve evolution, cloning │
│ │
│ 4. AGENT (ERC-6551 Token-Bound Account) │
│ • Signs updateMemory() with own key │
│ • Controls its own wallet and assets │
│ • Identity tied to tokenId, persists across owners │
│ • Can start fresh career after transfer() unbinds it │
│ │
└─────────────────────────────────────────────────────────────────────┘
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) → ERC-8171 (PR #1559, now assigned)— Registry for binding agents to existing NFTs: Add ERC: Token Bound Account (Agent Registry) by nftprof · Pull Request #1559 · ethereum/ERCs · GitHub