Standard / EIP·EVM
ERC-7857 — AI Agents NFT with Private Metadata
Draft ERC for NFTs whose metadata is encrypted off-chain (neural weights, agent memory, model state) with on-chain commitments to data hashes and sealed keys. Defines verifiable transfer flows backed by either TEEs or zero-knowledge proofs so the next owner can decrypt without the issuer trusting the bridge.
- 01AI agent ownership NFTs
- 02private model / weights tokenization
- 03encrypted metadata transfers
- 04TEE-backed or ZK-backed re-encryption
- 05data-cloning / usage authorization without ownership transfer
- pnpm add @openzeppelin/contracts
- pnpm add @0g-labs/0g-ts-sdk
- pnpm add viem
Build on top of ERC-721 and add `transfer(from, to, tokenId, proof)` plus `clone(from, to, tokenId, proof)` and `authorizeUsage(tokenId, executor, proof)` where `proof` is either a TEE attestation or a ZK proof attesting that (a) the new sealed key correctly decrypts the same plaintext as the old key (transfer-validity proof) and (b) the sender knew the original data (ownership proof). Store only `bytes32 dataHash` and `bytes sealedKey` on-chain per tokenId; keep ciphertext in 0G, Arweave, IPFS, or Filecoin. Abstract the verifier behind an `IDataVerifier` interface so the same token can support TEE attestations today and migrate to ZK proofs later. Emit `MetadataUpdated` and `DataTransferred` events with the new hash so indexers can track integrity changes.
- ⚑Verifier trust is the whole game — a buggy TEE attestation verifier or an under-constrained ZK circuit lets an attacker transfer a bogus dataHash that decrypts to junk; treat the verifier contract as a critical-path dependency and audit it separately.
- ⚑On-chain `dataHash` does NOT prove the data is available — pair with a data-availability layer (0G, EigenDA, Filecoin deals) or buyers will receive valid proofs of unreachable ciphertexts.
- ⚑Sealed keys are recipient-specific — re-use across multiple owners breaks confidentiality; the transfer flow MUST re-encrypt under the new owner's pubkey, not just rotate ownership of the same sealed blob.
- ⚑ERC-7857 is Draft and competes with ERC-7160 (multi-tokenURI) and EIP-4906 (metadata events) — the function selectors and proof shape have shifted across revisions; pin to a specific draft revision and document which one your contract targets.
- ⚑Cloning (`clone`) creates a second tokenId pointing at the same plaintext — without a usage-license model on top, clones dilute scarcity; bake licensing terms (royalty, exclusivity) into the metadata contract or the agent runtime.
- ⚑Front-ends cannot render private metadata directly — they must call into the TEE / proxy re-encryption service; a naive `tokenURI` JSON renderer leaks zero info and looks broken to users, so design a fallback 'public preview' field.