{"id":"ERC-7857","name":"AI Agent Private Metadata and Data Operations","status":"Final","chain":"both","category":{"id":"ai","name":"AI & Agents","description":"AI-generated content and agent coordination"},"journeyStages":[{"id":"specialized","name":"Specialized Interactions","description":"Physical items, AI, social, gaming"}],"uxImpact":"ERC-7857 defines private metadata and proof-based data operations for AI-agent assets. It does not inherit ERC-721, although an implementation may add ERC-721; actual functional data stays off-chain while hashes and sealed keys can be on-chain. Transfer, cloning, and usage authorization use verifier proofs and may involve a sealed executor, so access is not automatically owner-only and ERC-8001 integration is separate.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-7857","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-7857","summary":"ERC-7857 defines private metadata and proof-based data operations for AI-agent assets. It does not inherit ERC-721, although an implementation may add ERC-721; actual functional data stays off-chain while hashes and sealed keys can be on-chain. Transfer, cloning, and usage authorization use verifier proofs and may involve a sealed executor, so access is not automatically owner-only and ERC-8001 integration is separate.","applicability":{"whenToUse":["AI-agent data needs verifier-backed transfer, cloning, or usage authorization with private off-chain data.","The product can detect optional ERC-721 support and the actual iTransfer/iClone/authorization paths.","The implementation and sealed-executor policy explain which users can access or use data."],"whenToAvoid":["The implementation lacks the verifier, sealed executor, and off-chain storage needed for the chosen flow.","The product needs standard ERC-721 behavior without a separate ERC-721 implementation.","The app cannot show who is authorized to use data or how keys are transferred."]},"designerTakeaways":["You can show public agent capabilities separately from off-chain encrypted data and sealed keys.","You can disclose which transfer, clone, and usage-authorization paths the implementation exposes.","You can show the verifier, authorized users, and key handoff state before offering a private-data action."],"problemsSolved":[{"problem":"Agent data needs verifiable private transfer","oldWay":"A marketplace transfers a token without proving data re-encryption","newWay":"A verifier checks ownership and transfer-validity proofs for encrypted data","impact":"high"},{"problem":"Functional data should not be public on-chain","oldWay":"Models and memory are stored as readable metadata","newWay":"Only hashes and sealed keys are committed on-chain while data is stored/transmitted off-chain","impact":"critical"},{"problem":"An agent may need copy or delegated use","oldWay":"A single owner flag conflates transfer, cloning, and usage","newWay":"The interfaces expose separate iTransfer, iClone, authorizeUsage, and revokeAuthorization paths","impact":"high"},{"problem":"Implementations differ in execution and account compatibility","oldWay":"A product assumes ERC-721 and owner-only decryption","newWay":"The UI detects implemented interfaces, verifier type, authorized users, and sealed-executor policy","impact":"high"}],"uxPatterns":[{"name":"Agent NFT Profile","description":"Show public agent capabilities separately from private data and the verifier-backed access paths.","userFlow":["Browse agent asset","Detect the actual ERC-7857 and optional ERC-721 interfaces","Show public capabilities and data-hash/proof status","Explain current owner, authorized users, and sealed-executor availability"]},{"name":"Owner Dashboard","description":"Manage verifier-backed data access without assuming only the owner can use the data.","userFlow":["Owner opens an agent","Reads intelligentDataOf and storage state","Shows hashes and sealed keys without exposing plaintext","Displays authorized users and delegate access","Offers supported transfer, clone, or usage actions"]},{"name":"Transfer Agent Data","description":"Submit a verifier-backed data transfer and disclose off-chain delivery.","userFlow":["Select recipient and verifier","Review transfer proof and encrypted-key policy","Submit iTransfer or implementation-specific path","Wait for off-chain re-encryption/data availability","Show verifier result and new owner state"]},{"name":"Agent Transfer Warning","description":"Clear disclosure when selling agent","userFlow":["User selects transfer or clone","App explains data ownership and usage authorization separately","Shows recipient, authorized users, sealed executor, and off-chain data handoff","User confirms the proof-backed operation"]}],"uiComponents":[{"name":"AgentProfileCard","description":"Public-facing agent NFT display","states":["loading","public-view","owner-view"],"props":["agentId","publicMetadata","isOwner"]},{"name":"PrivateConfigViewer","description":"Decrypt and display private metadata","states":["locked","decrypting","unlocked","error"],"props":["encryptedData","onDecrypt"]},{"name":"CapabilityBadges","description":"Distinguish externally evidenced capabilities from publisher claims; a valid data-transfer proof does not verify runtime performance.","states":["verified","unverified","claimed"],"props":["capabilities[]"]},{"name":"AgentDataTransferPanel","description":"Review verifier-backed transfer or clone inputs and track ownership, proof and off-chain data handoff; running an agent is a separate integration.","states":["reviewing","proof-pending","submitting","handoff-pending","complete","error"],"props":["agentId","recipient","verifier","proof","handoffStatus","onTransfer"]}],"antiPatterns":[{"pattern":"Rendering an ERC-721 transfer UI for every ERC-7857 asset","why":"ERC-7857 does not inherit ERC-721; that interface is optional.","instead":"Detect ERC-721 support and use iTransfer/iClone paths when provided.","severity":"critical"},{"pattern":"Promising that only the NFT owner can access data","why":"Usage authorization and sealed-executor flows can involve other users without transferring ownership.","instead":"Show owner, authorized users, delegates, and executor policy separately.","severity":"critical"},{"pattern":"Calling private data on-chain or IPFS by default","why":"The specification stores hashes and sealed keys on-chain; functional data is stored/transmitted off-chain.","instead":"Disclose the actual off-chain storage and encryption path.","severity":"critical"},{"pattern":"Implying ERC-8001 interoperability","why":"ERC-8001 is not a required ERC-7857 interface.","instead":"Name a separate integration only when it is implemented and verified.","severity":"high"}],"keyTakeaways":["ERC-7857 specifies private agent-data operations; deployment and runtime behavior require separate integrations.","Private-data access depends on the implementation's authorization, encryption, and key-sharing rules","Warn clearly about what transfers with ownership","Show verified vs claimed capabilities"],"technicalNotes":"ERC-7857 defines verifier, metadata, and agent interfaces without inheriting ERC-721; implementations may additionally implement ERC-721. Core paths include iTransfer/iTransferFrom, iClone/iCloneFrom, authorizeUsage, revokeAuthorization, authorizedUsersOf, ownerOf, and delegateAccess. Proofs verify ownership, re-encryption, and data availability; functional data is off-chain while hashes and sealed keys can be on-chain. A sealed executor is out of scope and owner-only access is not guaranteed.","lastUpdated":"2026-09-18","specConstraints":[{"id":"ownership-verification-option","constraint":"Ownership verification is OPTIONAL because availability verification checks it again, although the source recommends it for minting and updates.","appliesTo":"account-implementation","normativity":"normative","specQuote":"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.","specSection":"Specification > Data Verification System","specUrl":"https://ercs.ethereum.org/ERCS/erc-7857#data-verification-system","designImplication":"Offer ownership verification as an explicit defense-in-depth step for minting and updates, but explain that availability verification repeats it rather than presenting the optional check as the only gate."},{"id":"receiver-access-assistant-option","constraint":"A receiver MAY delegate access and ownership proof signing to an access assistant.","appliesTo":"account-implementation","normativity":"normative","specQuote":"/// @notice The access proof which is a signature signed by the receiver (the receiver may delegate the signing privilege to the access assistant)","specSection":"Specification > Data Verification Interface","specUrl":"https://ercs.ethereum.org/ERCS/erc-7857#data-verification-interface","designImplication":"If delegation is supported, show the assistant identity and proof scope before signing, and distinguish delegated authority from the receiver's own signature."},{"id":"verifier-proof-types","constraint":"The verifier SHOULD support both ownership and transfer-validity proof types so TEE and ZKP mechanisms can remain interchangeable.","appliesTo":"account-implementation","normativity":"rationale","specQuote":"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:","specSection":"Rationale","specUrl":"https://ercs.ethereum.org/ERCS/erc-7857#rationale","designImplication":"Identify the verifier mechanism and proof type in transfer or mint status, and keep unsupported TEE/ZKP paths visibly unavailable instead of implying interchangeable coverage."},{"id":"zkp-post-update-reencryption","constraint":"With ZKP verification, tokens transferred or cloned from another owner SHOULD be re-encrypted on the next update to prevent the previous owner from seeing the new update.","appliesTo":"account-implementation","normativity":"security-considerations","specQuote":"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","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-7857#security-considerations","designImplication":"Keep the post-transfer re-encryption step visible and mark later updates as privacy-pending until it completes; do not imply that a ZKP transfer alone protects future metadata from the previous owner."},{"id":"proof-verification","constraint":"Implementations must verify every assertion in the proof before accepting a private-data operation.","appliesTo":"application","normativity":"security-considerations","specQuote":"Implementations must carefully verify all assertions in the proof","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-7857#security-considerations","designImplication":"Show proof verification as a prerequisite state and do not present private data as transferred before verification completes."},{"id":"replay-prevention","constraint":"Replay attacks must be prevented for private-data operations.","appliesTo":"application","normativity":"security-considerations","specQuote":"Replay attacks must be prevented","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-7857#security-considerations","designImplication":"Make a replay rejection visible and keep retry controls tied to a fresh request."},{"id":"post-transfer-reencryption","constraint":"After transfer or cloning, the next data update must be re-encrypted so the previous owner cannot see it under the stated verification limits.","appliesTo":"application","normativity":"security-considerations","specQuote":"tokens acquired through transfer or cloning must undergo re-encryption during their next update","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-7857#security-considerations","designImplication":"Show the post-transfer re-encryption step and do not claim that the new owner’s future data is private before it completes."},{"id":"private-data-offchain","constraint":"Only hashes and sealed keys belong on-chain; functional data must be stored and transmitted securely off-chain.","appliesTo":"application","normativity":"security-considerations","specQuote":"- Only hashes and sealed keys are stored on-chain, actual functional data must be stored and transmitted securely off-chain","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-7857#security-considerations","designImplication":"Separate on-chain proof metadata from private content and explain where the user’s data is stored and sent."},{"id":"private-state-integrity","constraint":"Private-data operations must preserve integrity, availability, and atomic critical state changes.","appliesTo":"application","normativity":"security-considerations","specQuote":"- All data operations must maintain integrity and availability\n- Critical state changes (sealed keys, ownership, permissions) must be atomic and verifiable","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-7857#security-considerations","designImplication":"Show incomplete or unverifiable state changes as pending or failed rather than presenting partial ownership or permission updates as final."}],"sources":[{"label":"ERC-7857 official specification","url":"https://ercs.ethereum.org/ERCS/erc-7857","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-7857","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-7857","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-7857","markdown":"https://www.eipsfordesigners.com/standards/ERC-7857/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-7857/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-7857","official":"https://ercs.ethereum.org/ERCS/erc-7857","discussion":"https://ethereum-magicians.org/search?q=ERC-7857"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}