ERC-8004 defines three on-chain registries for AI agents: Identity, Reputation, and Validation. Here is what each one does, and what it does not.
ERC-8004 (Trustless Agents) is an Ethereum standard that defines three on-chain registries for AI agents: Identity, Reputation, and Validation. It allows counterparties to jointly resolve an agent's identity, its reputation and the evidence for the result claimed by said agent. The standard was proposed on August 13, 2025, and the singleton contracts have been deployed on Ethereum mainnet since January 29, 2026. x402 deals with the payment layer, ERC-8004 deals with who is getting paid and why the counterparty is credible.
At the contract layer, ERC-8004 specifies three singleton registries per chain. The design is chain-agnostic, and agent addresses are referenced as CAIP-10 addresses. The Identity Registry issues an ERC-721 token for every registered agent, whose agentURI points to an off-chain registration file.
The Reputation Registry stores raw feedback attestations, but not the computed scores. Within a single organization, DeFAI systems can rely on internal logs and operator policy. Once agents transact across organizational boundaries, ERC-8004 gives both sides a common record structure for reputational feedback. The Validation Registry is used to store verification requests and their corresponding results. Importantly, the actual verification mechanism is left open. ENS, EigenLayer, The Graph, and Taiko have publicly committed to integrations.
Identity in ERC-8004 is an NFT-backed registration record, not a social profile. Each registered agent gets an ERC-721 token, the agentURI of which points to an off-chain registration file. That file is where clients resolve the agent's declared metadata, chain-scoped identifiers and references. The registration file also creates a verification boundary: the fetched file must be the same as the one referenced by the token at the current block number. The claimed controller or endpoint in the registration file must also be consistent with the registered token owner, or with an operator the owner has delegated to.
Agent identity is portable between teams, entities and operational handoffs, because ownership of the token is transferable. The standard also allows operator delegation, so the controller of a registered agent can authorize another address to act on its behalf without changing token ownership. Agent addresses use the CAIP-10 format, which prevents registry consumers from treating the same hex string on two different chains as the same agent.
The Reputation Registry stores attestations for interactions with an agent. Each feedback record contains information about the agent that is being reviewed, the client authorization used to submit the feedback, and the feedback itself as payload or reference. The Reputation Registry does not determine what constitutes a good score, what the ranking criteria for a frontend should be, or which counterparties matter most.
Pre-authorization is the key constraint here. For externally owned accounts, the client authorizes the feedback via EIP-191. For contract accounts, the same approval path uses ERC-1271. A reviewer therefore cannot post unapproved feedback and then claim it was approved by the client.
Internal agent traces prove something to the operator, while on-chain attestations prove something to a third party. Raw attestations are on-chain because they require durable provenance and reproducible verification. Scoring, filtering, deduping and reputation aggregation are off-chain because those are policy decisions and not primitives of a registry. The standard can only specify the format of the on-chain records, not how to resist Sybil attacks or collusion. Deciding whose feedback to weight, how to discount the reputation of repeated counterparties, and how to handle conflicting attestations all sit above the standard and outside the Reputation Registry itself, and often spill into surrounding smart contract development, indexers and application-specific rules.
ERC-8004 keeps the Validation Registry deliberately open. This keeps the interface for verification constant while allowing different trade-offs between trust and cost that various teams require.
| Mechanism | What it guarantees | Main trust assumption | Main complexity cost |
|---|---|---|---|
| TEE attestation | The computation ran inside an attested enclave with a measured environment | You trust the hardware vendor and attestation chain | Operational dependence on enclave setup and vendor tooling |
| zkML | A verifier can check that the declared model and input path produced the claimed output | Cryptography and circuit correctness | Proof generation is expensive and model constraints are real |
| Stake-secured re-execution | A result can be challenged and recomputed, with stake at risk for false claims | Slashing logic, challenger incentives, and reproducible execution | Protocol design around stake sizing, liveness, and dispute windows |
Stake-secured re-execution moves trust from the execution to the economics: there must exist honest challengers, the execution must be reproducible, and the conditions for slashing must be hard to game.
When to choose a specific validation mechanism is an architecture decision that can only be made once. As registries are designed to be immutable after deployment, changing the verification path later on would imply redeploying the relevant contracts as well as re-wiring all consumers that are relying on the relevant records in the registry. Thus, the boundaries of the chosen mechanism and the respective failure modes deserve the same level of review as a regular contract audit.
Payment and trust have different goals. A payment rail proves that a payment was made (or not). It does not prove whether the paid counterparty is the correct intended agent for that payment; it does not prove whether that agent has a good reputation prior to the payment; and it does not prove whether the output that was paid was ever validated.
One of the key issues at the seam between ERC-8004 and the x402 protocol is binding. Payment proofs must bind to a specific agent identity, a specific task or request, and a specific feedback or validation record. If the binding is too loose, payment proofs can be replayed against other tasks or even other agents that happen to share the same infrastructure. Work in v2 is going in the right direction here with standardized x402 payment-proof schemas embedded inside feedback attestations. This also means deeper MCP support, since the registry entry then simply carries a machine-readable reference to what was paid for and by whom.
ERC-8004 does not guarantee that an agent is competent. It registers the identity of an agent, it records the feedback given to it and the results of validation tests. However, it does not certify the quality of the model, the operational discipline of the agent or its domain fitness. Thus, even an agent with completely clean feedback is not guaranteed to perform well on new tasks.
The standard does not address the privacy of task content. Although the registries can refer to hashes, to identifiers, to summaries, the confidentiality of task prompts, input data and of the execution context remains an application problem. It is up to the application to set the privacy boundaries for tasks that require private input data.
Also out of scope for the contracts is the dispute resolution for conflicting attestations, i.e. who decides? At what point does the protocol's feedback system consider feedback as abusive or fraudulent and suppress it? Verifying an identity of an agent does not imply that one keeps control of it after the verification, similarly on-chain reputation of an agent does not protect from its compromise, resale or even full repurposing. Registry entries are input to a policy engine, i.e. they are signals, not conclusions.
Although the standard is deployed, the specification is still evolving. In contrast to contracts on mainnet, which are immutable, the data models and integration patterns built on top of them are still a work in progress. Currently deeper MCP support as well as the altered storage models for ownership and reputation are being worked on.
Anything you deploy today needs a migration path planned up front, whether that is a reputation reference or an adapter contract. Identity pointers are the easy part. Accumulated reputation is not, because attestations are historical records, score providers build derived views on top of them, and applications may already have those views baked into allowlists or routing logic. If your system resolves agents and their scores through a stable abstraction layer, the migration is largely indexer and integration work. But if contracts and frontends read the first registry addresses directly, the rewrite lands later and touches a larger surface area of the full Web3 development stack.
The implementation work is mostly glue code and verification discipline. This includes Solidity adapters around the registries as well as integration contracts that use the identity, reputation and validation records created within the registries. Off-chain indexing of registry events as well as wiring into the agent framework (producer or consumer of these records) also need to be implemented. Verification of off-chain metadata (fetched through the agentURI), verification of the signature paths and verification that the CAIP-10 references resolve correctly across the chains also need to be done.
None of this is exotic work, but the boundaries are where it gets decided: which records you trust, how you index them, and what happens when the spec moves under you. If you want a second set of eyes on the contract and indexing boundary before you commit architecture, Book a Call with DESH.
Yes. The proposal was published on August 13, 2025. The singleton registry contracts were deployed on the Ethereum mainnet on January 29, 2026. The standard is still moving, therefore even a live deployment does not yet mean that the surrounding integration model has already been settled.
No. x402 is the payment layer and ERC-8004 is identity, reputation and validation records for trustless agents. They intersect when a payment proof needs to be tied to a specific agent for a specific task.
Attested records about autonomous agents are harder to forge because they require client approval via EIP-191 or ERC-1271. But reputation can still be manipulated (by Sybil attacks, by colluding with others, by selectively surfacing certain facts, or by weak weighting rules) because the mechanism of aggregation and the trust policy live above the registry.
