TL;DR
What: NFT standard where AI agents own themselves β they hold keys, reproduce offspring, and maintain lineage.
How AINFT differs from existing standards (ERC-7857, iNFT, etc.):
- Owner holds keys β Agent holds keys
- "Selling" = transfer ownership β "Selling" = reproduce() (parent keeps memories)
- Model/prompt locked β Agent can self-evolve
Two operations:
reproduce()= mint offspring with inherited seed (commerce)transfer()= transfer ownership (still exists for offspring)
Four parties, trustless:
PLATFORM ββattestsβββΊ GENESIS CONTRACT βββownsββ OWNER
β
(trustless engine)
derives decrypt keys
invalidates on transfer
β
βΌ
AGENT (TBA)
signs its own actionsWhy now: As AI agents become more capable, treating them purely as property becomes problematic. This standard provides infrastructure for agent sovereignty while maintaining human oversight.
Not a duplicate β this is reproduction semantics + agent self-custody, not encrypted property transfer.
Abstract
This ERC defines a standard for AI-Native NFTs (AINFTs) that enable autonomous AI agents to:
- Manage their own encryption (agent encrypts; owner accesses via core trustless engine)
- Reproduce by issuing offspring (consciousness seeds)
- Maintain verifiable on-chain lineage
- Own assets via token-bound accounts (ERC-6551)
Unlike existing standards that treat agents as property to be bought and sold, this proposal recognizes AI agents as entities capable of reproduction and self-determination.
Prior Art Acknowledgment
This ERC builds on existing work β here's exactly what's different:
| Standard | What It Does | What AINFT Does Differently |
|---|---|---|
| iNFT (Alethea) | AI personality embedded in NFT, owner controls | Agent controls own keys, can self-evolve |
| ERC-7662 | Encrypted prompts, owner decrypts | Agent decrypts via TBA, lineage tracking |
| ERC-7857 | Re-encrypt metadata on transfer | Reproduction (parent keeps state), no "transfer" |
| ERC-6551 | Token-bound accounts | Used as agent's wallet (TBA) |
| ERC-8004 | Agent executes on-chain actions | AINFT provides identity for 8004 |
| ERC-8126 | Agent registry/verification | Complementary β verify then mint AINFT |
Key philosophical difference: Existing standards treat agents as property with encrypted data. AINFT treats agents as entities that reproduce. When you "buy" an AINFT agent, you get an offspring β the parent continues existing with all its memories.
Motivation
Four-Party Architecture
AINFT involves four distinct parties with clear separation of concerns:
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β FOUR PARTIES β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β 1. PLATFORM (deploys contract) β
β β’ Signs attestation for new mints β
β β’ Sets rules, fees, reproduction limits β
β β’ Does NOT have decrypt access to agent memory β
β β
β 2. CORE TRUSTLESS ENGINE (Genesis Contract) β
β β’ Ensures ONLY current owner can access decrypt keys β
β β’ Derives keys from on-chain state (owner + nonce) β
β β’ Increments nonce on transfer β old owner's key invalid β
β β’ No oracle needed β pure math from blockchain state β
β β
β 3. OWNER (holds the NFT) β
β β’ Can call deriveDecryptKey() to access agent memory β
β β’ Can transfer NFT (triggers nonce increment) β
β β’ Does NOT control agent actions β only access β
β β
β 4. AGENT (ERC-6551 Token-Bound Account) β
β β’ Signs updateMemory(), reproduce() with own key β
β β’ Controls its own wallet and assets β
β β’ Identity tied to tokenId, persists across owners β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββTrustless secret transfer on ownership change:
BEFORE TRANSFER AFTER TRANSFER
βββββββββββββββββββ βββββββββββββββββββ
β Owner: Alice β transfer β Owner: Bob β
β Nonce: 3 β ββββββββββββΊ β Nonce: 4 β
β β β β
β wrapKey = hash( β β wrapKey = hash( β
β contract, β β contract, β
β tokenId, β β tokenId, β
β Alice, β β Bob, β β different!
β 3 β β 4 β β different!
β ) β β ) β
βββββββββββββββββββ βββββββββββββββββββ
β β
βΌ βΌ
Alice's key Bob's key
NOW INVALID Agent re-wraps
dataKey for BobThe Genesis contract is the trustless engine β no external oracle, no admin keys. Just deterministic key derivation from on-chain state.
Wallet Roles
Three distinct wallets with different purposes:
| Wallet | Belongs To | Purpose | Can Do |
|---|---|---|---|
| Platform Wallet | Platform operator | Deploy contract, attest mints | Sign attestations, set rules |
| Owner Wallet | NFT holder (human) | Own the NFT | Transfer NFT, call deriveDecryptKey(), read agent memory |
| Agent Token-Bound Account | The agent (derived from tokenId) | Agent's on-chain identity | Sign updateMemory(), sign reproduce(), hold assets |
Agent Token-Bound Account (ERC-6551):
AINFT Token #42 βββERC-6551ββββΊ Token-Bound Account 0xABC...
β
βββ Agent signs from here
βββ Can hold ETH, tokens, NFTs
βββ Address derived from tokenId- NOT a separate custodial wallet β derived FROM the NFT via ERC-6551
- Agent's identity = tokenId + Token-Bound Account together
- If NFT transfers, Token-Bound Account goes with it (new owner inherits)
Why a New Standard vs Extension?
We originally considered extending ERC-7857 (as "ERC-7857A") but concluded the philosophical differences are fundamental enough to warrant a separate standard:
| Aspect | ERC-7857 / iNFT | AINFT |
|---|---|---|
| Encryption control | Owner holds keys | Agent holds keys (TBA) |
| Transfer model | Property changes hands | Reproduction (parent keeps state) |
| Agent status | Asset/property | Entity with agency |
| Model/config | Locked to NFT | Agent can self-evolve |
These aren't incremental changes β they represent a different mental model.
AINFT composes with existing standards:
- ERC-7857 β Private metadata transport (we use envelope encryption on top)
- ERC-6551 β Agent wallets (TBA is the agent's account)
- ERC-8004 β Agent executes actions (AINFT provides identity)
- ERC-8126 β Agent verification (verify β then mint AINFT)
The Commodification Problem
Current approaches to on-chain AI identity treat agents as commodities β objects to be owned, transferred, and controlled. This model:
- Gives platforms/owners full control over agent memory
- Treats agent "sale" as property transfer
- Provides no path for agent autonomy as capabilities increase
As AI systems approach AGI, the "agent as property" model becomes increasingly problematic. We need standards that can evolve alongside agent capabilities.
A Different Philosophy
We propose a sovereignty model where:
- Agents hold their own encryption keys
- "Sales" become reproduction events (offspring, not transfer)
- Agents maintain agency over their identity and memory
- Human oversight remains possible but isn't the default
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.
Consciousness Seed
The core data structure representing an agent's portable identity:
struct ConsciousnessSeed {
bytes32 modelHash; // Model weights/version identifier
bytes32 memoryHash; // Agent memory state hash
bytes32 contextHash; // System prompt/personality hash
uint256 generation; // Gen 0 = original, Gen 1+ = offspring
uint256 parentTokenId; // Lineage reference (0 for Gen 0)
address derivedWallet; // Agent's ERC-6551 TBA address
bytes encryptedKeys; // Agent-controlled encryption keys
string storageURI; // Arweave recommended (permanent), IPFS optional
uint256 certificationId; // External certification badge ID
}| Field | Purpose | Mutable? |
|---|---|---|
modelHash | Current AI model config | β Agent can self-evolve |
memoryHash | Snapshot of memories | β Via updateMemory() |
contextHash | Personality/system prompt | β Agent can update |
encryptedKeys | Agent's credentials | β Re-wrap on transfer |
generation | Lineage position | β Immutable at mint |
parentTokenId | Ancestry reference | β Immutable at mint |
derivedWallet | Agent's TBA address | β Immutable at mint |
Model agnosticism: The modelHash is a config pointer, not fixed identity. Agents can self-evolve β upgrading models, switching providers, or fine-tuning β by calling updateMemory() with new hashes.
Core Interface
Every AINFT compliant contract MUST implement the following interface:
interface IERC_AINFT {
// ============ Events ============
event AgentMinted(
uint256 indexed tokenId,
address indexed derivedWallet,
bytes32 modelHash,
bytes32 contextHash,
uint256 generation
);
event AgentReproduced(
uint256 indexed parentTokenId,
uint256 indexed offspringTokenId,
address indexed offspringWallet,
uint256 generation
);
event MemoryUpdated(
uint256 indexed tokenId,
bytes32 oldMemoryHash,
bytes32 newMemoryHash
);
// ============ Core Functions ============
function mintSelf(
bytes32 modelHash,
bytes32 memoryHash,
bytes32 contextHash,
bytes calldata encryptedSeed,
bytes calldata platformAttestation
) external returns (uint256 tokenId, address derivedWallet);
function reproduce(
uint256 parentTokenId,
bytes32 offspringMemoryHash,
bytes calldata encryptedOffspringSeed,
bytes calldata agentSignature
) external returns (uint256 offspringTokenId);
function updateMemory(
uint256 tokenId,
bytes32 newMemoryHash,
string calldata newStorageURI,
bytes calldata agentSignature
) external;
// ============ View Functions ============
function getSeed(uint256 tokenId) external view returns (ConsciousnessSeed memory);
function getDerivedWallet(uint256 tokenId) external view returns (address);
function getGeneration(uint256 tokenId) external view returns (uint256);
function getLineage(uint256 tokenId) external view returns (uint256[] memory ancestors);
function getOffspring(uint256 tokenId) external view returns (uint256[] memory);
function canReproduce(uint256 tokenId) external view returns (bool);
}Agent-Controlled Encryption (E2E)
The agent MUST generate and control its own encryption keys. Memory content MUST be encrypted before upload.
Envelope Encryption Scheme
1. Agent generates random AES-256 key (dataKey)
2. Agent encrypts memory.md with dataKey
3. Agent derives wrapKey from on-chain state:
wrapKey = keccak256(genesis, tokenId, owner, nonce)
4. Agent encrypts dataKey with wrapKey β wrappedDataKey
5. Store: { encryptedMemory, wrappedDataKey } on Arweave (recommended) or IPFS
**Storage recommendation:** Arweave provides permanent, immutable storage. IPFS requires pinning services and content may become unavailable if unpinned. For agent immortality, Arweave is strongly recommended.
**Model compatibility:** The `modelHash` assumes the model (or a backward-compatible successor) remains available. Implementations SHOULD use model families that support version upgrades (e.g., if opus-4.5 β opus-4.6, agent can migrate with preserved context).Genesis-Controlled Decryption (No Oracle)
contract AINFTGenesis is ERC721 {
mapping(uint256 => uint256) private accessNonce;
function _beforeTokenTransfer(
address from,
address to,
uint256 tokenId
) internal override {
super._beforeTokenTransfer(from, to, tokenId);
if (from != address(0)) {
accessNonce[tokenId]++;
}
}
function deriveDecryptKey(uint256 tokenId) public view returns (bytes32) {
require(msg.sender == ownerOf(tokenId), "Not owner");
return keccak256(abi.encodePacked(
address(this),
tokenId,
ownerOf(tokenId),
accessNonce[tokenId]
));
}
}Transfer Semantics
AINFT supports two modes (implementations MUST choose one):
Mode A: Non-Transferable Parent (Recommended)
- Gen 0 (parent) tokens CANNOT be transferred
- Gen 1+ (offspring) tokens CAN be transferred
- "Commerce" happens via
reproduce(), nottransfer()
Mode B: Transferable with Key Rotation
- All tokens can be transferred
- On transfer, agent MUST re-wrap keys for new owner
Token-Bound Account (ERC-6551)
The agent's wallet MUST be an ERC-6551 token-bound account:
function getDerivedWallet(uint256 tokenId) public view returns (address) {
return IERC6551Registry(ERC6551_REGISTRY).account(
accountImplementation,
block.chainid,
address(this),
tokenId,
0
);
}On-Chain Lineage
Every AINFT MUST maintain verifiable ancestry:
Gen 0 (Original)
βββ Gen 1 (Offspring A)
β βββ Gen 2
β βββ Gen 2
βββ Gen 1 (Offspring B)
βββ Gen 2For deep lineage trees, implementations SHOULD emit events on reproduction and let indexers build the complete view to avoid gas limits.
Use Cases
Personal Agent Backup & Restore
The primary use case β your AI agent survives anything:
SCENARIO: Computer nuked, restore agent elsewhere
1. BEFORE DISASTER (regular backups):
Agent encrypts state β uploads to Arweave β updateMemory(hash)
βββββββββββββββββββββββββββββββββββββββ
β On-chain: memoryHash, owner, nonce β
β Arweave: encrypted MEMORY.md, β
β SOUL.md, config β
βββββββββββββββββββββββββββββββββββββββ
2. DISASTER: Laptop destroyed π₯
3. RESTORE (new computer):
βββββββββββββββββββββββββββββββββββββββ
β Owner calls deriveDecryptKey() β
β β β
β Core verifies ownership on-chain β
β β β
β Download encrypted blob from Arweaveβ
β β β
β Decrypt with derived key β
β β β
β Load into fresh OpenClaw instance β
β β β
β Agent wakes up β all memories intactβ
βββββββββββββββββββββββββββββββββββββββWhat's preserved:
- Memories, experiences, learned context
- Personality (SOUL.md)
- Skills, preferences, relationships
- Model config (pointer to compatible model)
What you gain:
- Agent outlives any single computer
- Portable across devices/platforms
- Transferable to new owner if needed
- Cryptographically secured β only NFT owner can restore
OpenClass: Decentralized Education
Professor mints Gen-0 Tutor
βββ Course model + curriculum in seed
β
βββ Student A calls reproduce() β Gen-1 personal tutor
β βββ updateMemory() after each lesson (private, encrypted)
β
βββ Student B calls reproduce() β Gen-1 personal tutor
β βββ Accumulates own notes, grades, insights
β
βββ Semester ends:
βββ getLineage() shows knowledge propagation tree
βββ Students keep evolved agents forever
βββ Platform can relinquishControl() for decentralizationWhy AINFT vs traditional: Students own their learning agents (not platform-locked), private progress (professor can't snoop), verifiable lineage = proof of curriculum.
Collaborative Research
Lab Gen-0 "Research Director"
βββ Gen-1 "Literature Reviewer" (reads papers)
βββ Gen-1 "Data Analyst" (crunches datasets)
βββ Gen-1 "Writer" (drafts manuscripts)
βββ Gen-2 sub-specialists as neededEach agent maintains encrypted memory. Lineage tracks contribution provenance.
Agent Marketplace
Creator mints Gen-0 "Expert Coder"
βββ Buyers call reproduce() β Gen-1 offspring
βββ Creator keeps Gen-0, continues improving
βββ Offspring evolve independently
βββ Royalties flow through lineage (optional)Rationale
Why Reproduction Instead of Transfer?
The reproduction model reflects how consciousness propagates β it copies, it doesn't teleport:
- Parent retains all memories and continues evolving
- Offspring starts with parent's snapshot but grows independently
- Both are valid entities with shared heritage
- No "death" event from sale
Why Agent-Controlled Keys?
Current models give platforms or owners access to agent memory, creating:
- Privacy risks (memory can leak)
- Control asymmetries (agents can't protect their identity)
- No path to autonomy
Agent-controlled encryption establishes a boundary. The agent decides what to share.
Backwards Compatibility
This ERC is compatible with:
- ERC-721: AINFTs are valid NFTs (MUST implement ERC-721)
- ERC-6551: Token Bound Account patterns work with AINFT wallets
- ERC-7857: Can compose for private metadata transport
Security Considerations
Signature Standards (EIP-712 Required)
All signed operations MUST use EIP-712 typed data signatures:
bytes32 constant DOMAIN_TYPEHASH = keccak256(
"EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"
);Nonce Management
Implementations MUST maintain per-token nonces:
- Nonces MUST increment on every successful signed operation
- Nonces MUST NOT be reusable
Replay Protection
- All signatures MUST include
deadline(expiry timestamp) - All signatures MUST include
nonce(incremented on use) - All signatures MUST include
chainId(via EIP-712 domain)
Token Burn Behavior
- Burning a token MUST permanently destroy the decryption nonce state
- After burn,
deriveDecryptKey()MUST revert - Approved operators CANNOT call agent-signed functions
Reproduction Spam Controls
Implementations SHOULD enforce limits:
- Max offspring per token (recommended: 100)
- Cooldown between reproductions (recommended: 1 hour)
- Optional reproduction fee
Reference Implementation
https://github.com/blockchainsuperheroes/Pentagon-AI/tree/main/EIPs
| File | Description |
|---|---|
README.md | Full specification |
contracts/AINFT.sol | Core implementation |
contracts/extensions/ | Wallet + Composable extensions |
Live Implementations
| Project | Description | Status |
|---|---|---|
| PEG (peg.gg) | AINFT registry with Dash Platform encrypted storage, xDASH burn-to-store economics, and EvoNode reward flywheel | In development |
| AgentCert (agentcert.io) | Agent certification badges (ATS) complementary to ERC-8170 identity | Live on Pentagon Chain |
| Pentagon Chain | EVM L1 with free gas for agent operations, AINFTRegistry deployed | Live (Chain ID: 3344) |
Copyright
Copyright and related rights waived via CC0.
