ERC-7857: AI Agents NFT with Private Metadata

Abstract

A standard interface for NFTs specifically designed for AI agents, where the metadata represents agent capabilities and requires privacy protection. Unlike traditional NFT standards that focus on static metadata, this standard introduces mechanisms for verifiable data ownership and secure transfer. By defining a unified interface for different verification methods (e.g., Trusted Execution Environment (TEE), Zero-Knowledge Proof (ZKP)), it enables secure management of valuable agent metadata such as models, memory, and character definitions, while maintaining confidentiality and verifiability.

Motivation

With the increasing intelligence of AI models, agents have become powerful tools for automating meaningful daily tasks. The integration of agents with blockchain technology has been recognized as a major narrative in the crypto industry, with many projects enabling agent creation for their users. However, a crucial missing piece is the decentralized management of agent ownership.

AI agents possess inherent non-fungible properties that make them natural candidates for NFT representation:

1. Each agent is unique, with its own model, memory, and character
2. Agents embody clear ownership rights, representing significant computational investment and intellectual property
3. Agents have private metadata (e.g., neural network models, memory, character definitions) that defines their capabilities

However, current NFT standards like ERC-721 are insufficient for representing AI agents as digital assets. While NFTs can establish ownership of digital items, using them to represent AI agents introduces unique challenges. The key issue lies in the metadata transfer mechanism. Unlike traditional NFTs where metadata is typically static and publicly accessible, an AI agent's metadata (which constitutes the agent itself):

1. Has intrinsic value and is often the primary purpose of the transfer
2. Requires encrypted storage to protect intellectual property
3. Needs privacy-preserving and verifiable transfer mechanisms when ownership changes

For example, when transferring an agent NFT, we need to ensure:

1. The actual transfer of encrypted metadata (the agent's model, memory, character, etc.) is verifiable
2. The new owner can securely access the metadata that constitutes the agent
3. The agent's execution environment can verify ownership and load appropriate metadata

This EIP introduces a standard for NFTs with private metadata that addresses these requirements through privacy-preserving verification mechanisms, enabling secure ownership and transfer of valuable agent data while maintaining confidentiality and verifiability. This standard will serve as a foundation for the emerging agent ecosystem, allowing platforms to provide verifiable agent ownership and secure metadata management in a decentralized manner.

Specification

The EIP defines three key interfaces: the main NFT interface, the metadata interface, and the data verification interface.

Data Verification System

The verification system consists of two core components that work together to ensure secure data operations:

1. On-chain Verifier (data verification interface)

   • Implemented as a smart contract
   • Verifies proofs submitted through contract calls
   • Returns structured verification results
   • Can be implemented using different verification mechanisms (TEE/ZKP)

2. Off-chain Prover

   • Generates proofs for ownership and availability claims
   • Works with encrypted data and keys
   • Implementation varies based on verification mechanism:
     • TEE-based: Generates proofs within trusted hardware
     • ZKP-based: Creates cryptographic zero-knowledge proofs

The system supports two types of proofs:

1. Ownership Proof

   • Generated by Prover with access to original data
   • Proves knowledge of pre-images for claimed dataHashes
   • Verified on-chain through verifyOwnership()

2. Transfer Validity Proof

   • Generated by Prover for data transfers
   • Proves:
     • Knowledge of original data (pre-images)
     • Correct decryption and re-encryption of data
     • Secure key transmission (using receiver's public key to encrypt the new key)
     • Data availability in storage (using receiver's signature to confirm the data is available in storage)
   • Verified on-chain through verifyTransferValidity()

The ownership verification is optional because when the minted token is transferred or cloned, the ownership verification is checked again inside the availability verification. It's better to be safe than sorry, so we recommend doing ownership verification for minting and updates.

Different verification mechanisms have distinct capabilities:

• TEE-based Implementation

  • Prover runs in trusted hardware
  • Can handle private keys securely
  • Enables direct data re-encryption
  • Verifier checks TEE attestations

• ZKP-based Implementation

  • Prover generates cryptographic proofs
  • Cannot handle multi-party private keys
  • Re-encryption key known to prover
  • Requires additional re-encryption when next update, otherwise the new update is still visible to the prover

Data Verification Interface

Metadata Interface

Main NFT Interface

Rationale

The design choices in this standard are motivated by several key requirements:

1. Verification Abstraction: The standard separates the verification logic into a dedicated interface (IDataVerifier), allowing different verification mechanisms (TEE, ZKP) to be implemented and used interchangeably. The verifier should support two types of proof:

   • Ownership Proof Verifies that the prover possesses the original data by demonstrating knowledge of the pre-images that generate the claimed dataHashes
   • Transfer Validity Proof Verifies secure data integrity and availability by proving: knowledge of the original data (pre-images of oldDataHashes); ability to decrypt with oldKey and re-encrypt with newKey; secure transmission of newKey using recipient's public key; integrity of the newly encrypted data matching newDataHashes; and data availability confirmed by recipient's signature on both oldDataHashes and newDataHashes

2. Data Protection: The standard uses data hashes and encrypted keys to ensure that valuable NFT data remains protected while still being integrity and availability verifiable

3. Flexible Data Management: Three distinct data operations are supported:

   • Full transfer, where the data and ownership are transferred to the new owner
   • Data cloning, where the data is cloned to a new token but the ownership is not transferred
   • Data usage authorization, where the data is authorized to be used by a specific user, but the ownership is not transferred, and the user still cannot access the data. This need an environment to authenticate the user and process the request from the authorized user secretly, we call it "Sealed Executor"

4. Sealed Executor: Although the Sealed Executor is not defined and out of the scope of this standard, it is a crucial component for the standard to work. The Sealed Executor is an environment that can authenticate the user and process the request from the authorized user secretly. The Sealed Executor should get authorized group by tokenId, and the verify the signature of the user using the public keys in the authorized group. If the verification is successful, the executor will process the request and return the result to the user, and the sealed executor could be implemented by a trusted party (where permitted), TEE or Fully Homomorphic Encryption (FHE)

Backwards Compatibility

This EIP does not inherit from existing NFT standards to maintain its focus on functional data management. However, implementations can choose to additionally implement ERC-721 if traditional NFT compatibility is desired.

Reference Implementation

Verifier

Main NFT

Security Considerations

1. Proof Verification
   • Implementations must carefully verify all assertions in the proof
   • Replay attacks must be prevented
   • Different verification systems have their own security considerations, and distinct capabilities regarding key management: TEE can securely handle private keys from multi-parties, enabling direct data re-encryption. However, ZKP, due to its cryptographic nature, cannot process private keys from multi-parties. As a result, the re-encryption key is also from the prover (i.e., the sender), so tokens acquired through transfer or cloning must undergo re-encryption during their next update, otherwise the new update is still visible to the previous owner. This distinction in key handling capabilities affects how data transformations are managed during later usage
2. Data Privacy
   • Only hashes and sealed keys are stored on-chain, actual functional data must be stored and transmitted securely off-chain
   • Key management is crucial for secure data access
   • TEE verification system could support private key of the receiver, but ZKP verification system could not. So when using ZKP, the token transferred or cloned from other should be re-encrypted when next update, otherwise the new update is still visible to the previous owner
3. Access Control and State Management
   • Operations restricted to token owners only
   • All data operations must maintain integrity and availability
   • Critical state changes (sealed keys, ownership, permissions) must be atomic and verifiable
4. Sealed Executor
   • Although out of scope for this standard, the Sealed Executor is crucial for secure operation
   • The Sealed Executor authenticates users and processes requests in a secure environment by verifying user signatures against authorized public keys for each tokenId
   • The Sealed Executor can be implemented through a trusted party (where permitted), TEE or FHE
   • Ensuring secure request processing and result delivery

Copyright

Copyright and related rights waived via CC0.