How ERC-8004 registries work: identity, reputation, and validation for agents

How ERC-8004 registries work is a three-ledger pipeline: an ERC-721 AgentID points to an off-chain registration file, while separate Reputation and Validation registries record compact 0–100 trust signals with evidence pointers. The design does not put “agent truth” on-chain, it standardizes where to look (identity), who can speak (authorized reputation), and how to price assurance (validation) for 8004 agent identity.

Key Takeaways

• ERC-8004 defines three lightweight on-chain registries: Identity, Reputation, and Validation.
• The Identity Registry uses an ERC-721 AgentID whose tokenURI points to an off-chain agent registration file listing endpoints and identifiers such as A2A, MCP, ENS, and wallet addresses.
• The Reputation Registry records portable 0–100 feedback signals with optional tags and off-chain links, and a developer walkthrough describes an agent-signed feedbackAuth gate to reduce arbitrary spam.
• The Validation Registry records validationRequest calls and 0–100 validator responses, letting apps swap in staking, zkML proofs, or TEE attestations without changing discovery.

ERC-8004 registries and their purpose

ERC-8004 registries are smart contracts that store standardized records and emit events so other apps can look up agent identity and trust signals without negotiating bespoke schemas. The standard’s core move is splitting “trust” into three distinct surfaces: an identity registry for discovery, a reputation registry for user feedback, and a validation registry for third-party checks. That separation is why erc 8004 registries stay lightweight on-chain while still being composable across apps.

The useful mental model is an on-chain credit file for autonomous agents. The Identity Registry is the account number and routing info, not the credit score. Reputation and Validation are two different ledgers of compact 0–100 signals, each allowed to carry tags and pointers to off-chain evidence. This is the identity reputation validation registry pattern: keep the chain as the canonical index and integrity anchor, and keep the messy details off-chain.

ERC-8004 is described as an Ethereum Improvement Proposal in Draft status and undergoing peer review. The primary guide lists the creation date as Aug. 13, 2025 and names co-authors Marco De Rossi (MetaMask), Davide Crapis (Ethereum Foundation), Jordan Ellis (Google), and Erik Reppel (Coinbase). That draft posture matters because the interfaces are meant to be stable enough for experimentation, but builders should expect field-level details to evolve.

The broader topic is agent identity, and ERC-8004’s thesis is narrow by design: it does not claim to prove an agent’s capabilities on-chain. It standardizes where those claims live (tokenURI registration), how feedback gets posted in a way that is harder to spam (authorization), and how independent assurance can be purchased when stakes rise (validation).

How the identity registry works

The Identity Registry’s lifecycle is short on-chain and long off-chain. On-chain, the mechanism is an ERC-721 with URI storage: mint a unique AgentID token, set its tokenURI, and rely on standard NFT indexing and events for discovery. Off-chain, the tokenURI resolves to an agent registration file that acts like a living configuration document for how to reach and interpret the agent.

A concrete flow looks like this:

1. An agent operator mints an ERC-721 AgentID in the identity registry and sets tokenURI. 2. Indexers and apps watch registry events and enumerate AgentIDs the same way they would enumerate NFTs. 3. The app fetches tokenURI and reads the off-chain agent registration file to learn endpoints and identifiers.

The primary source describes that registration file as containing endpoints and identifiers such as A2A, MCP, ENS, and wallet addresses. That is the operational payload. If an app is trying to route a task to an agent, the identity registry gives it the canonical pointer to the agent’s “where to talk to me” and “what handles I claim” bundle.

This is also where most integrations get blindsided. The ERC-721 token does not tell an app whether the off-chain registration file quietly changed, whether an endpoint went dark, or whether an ENS name was repointed. Treating tokenURI content like production config is the right posture: version it, pin it to content-addressed storage when possible, and alert on changes. The on-chain part is intentionally boring, and that is the point.

The required objects show up here naturally: the identity registry is the contract, the AgentID is the ERC-721 token, and the agent card is what many front ends will render from tokenURI plus any cached validation and reputation summaries.

How reputation signals are recorded

Reputation in erc 8004 is designed to be portable but not permissionless. The Reputation Registry provides a standard interface for posting and retrieving feedback signals, and the primary source frames those signals as 0–100 scores with optional tags and links to off-chain detailed feedback data. The chain stores the compact signal. The off-chain link carries the narrative, receipts, and any context an app wants to show a human.

The key mechanic that keeps the reputation registry from turning into an untradeable spam wall is authorization. A developer-oriented walkthrough describes reputation submission as requiring agent-issued authorization via a signed feedbackAuth. The idea is simple: the agent pre-authorizes a specific counterparty to leave feedback, so random addresses cannot spray negative reviews at scale without ever interacting.

A typical sequence is:

1. The agent accepts a task and issues a feedback authorization to the client. 2. The client submits feedback to the reputation registry with score (0–100), optional tags, optional off-chain URI and hash, and the feedbackAuth. 3. Apps and aggregators read on-chain feedback events and compute their own summaries, while fetching off-chain detail only when needed.

The primary guide also points at a cleaner admission ticket for “real usage” reviews: x402 payment proofs. It explicitly references HTTP status code "402 Payment Required" as part of x402’s framing, and describes using payment proofs so only paying customers can leave reviews. That is a tight composition: payment gates who can speak, the registry stores the minimal 0–100 signal, and the evidence link can hold the receipt.

None of this eliminates Sybil behavior. The primary source acknowledges pre-authorization only partially mitigates spam and that Sybil attacks remain possible, which is why many implementations will still weight reviewers, maintain reviewer reputation, or impose economic costs elsewhere.

How validation requests and responses work

Validation is the registry where apps buy down risk. The Validation Registry supports requesting and recording independent validator checks, and the primary source describes a validationRequest function plus validator responses scored 0–100. That 0–100 range is deliberately flexible: an app can treat it as pass or fail, or as a spectrum where different validators have different thresholds.

The flow is a request-response pattern:

1. An agent or consumer calls validationRequest to ask a validator to check some claim or output. 2. A validator performs its check using whatever assurance tech it supports. 3. The validator posts a response back with a 0–100 score and can attach off-chain evidence via URIs and hashes.

The important design choice is that the registry does not hardcode a single verification method. The sources discuss multiple mechanisms, including crypto-economic staking, zkML proofs, and TEE oracles or attestations. Many deployments can verify attestations off-chain and then post the result on-chain, keeping the chain as the settlement layer for “what was claimed” and “who said it.”

This is where the thesis shows up on a screen: ERC-8004 does not make trust a binary badge. It standardizes how a consumer discovers the agent, then lets the consumer dial assurance up with risk. Low-stakes routing can lean on reputation signals. Medium-risk actions can require stake-backed validation. High-stakes actions can demand cryptographic verification like TEE attestations or zkML proofs, with the registry acting as the canonical place to find the latest responses.

Putting the registries together safely

A safe integration composes the three registries into a tiered trust decision rather than averaging everything into a single “trust score.” Identity is the lookup layer, reputation is a portable history of counterparties speaking about outcomes, and validation is an explicit purchase of assurance for a specific claim. Treating them as interchangeable numbers is how apps end up trusting the wrong thing.

A practical gating model maps cleanly to the trust models described in the primary guide:

1. Low stakes: use identity plus reputation for discovery and routing. The app reads tokenURI, checks the agent card fields it cares about, and uses reputation signals as a filter. 2. Medium stakes: require crypto-economic validation. The app only proceeds when a validator response meets its threshold, and it can prefer validators that post stake-backed results. 3. High stakes: require cryptographic verification. The app demands TEE attestations or zkML proofs, with the validation registry storing the 0–100 response and evidence pointers.

The sharp edge is off-chain drift. The identity registry’s tokenURI can point to an off-chain registration file that changes over time, and the chain will not warn a consumer that endpoints, identifiers, or advertised trust options moved. Versioning and pinning that file, plus monitoring changes, is not optional if the agent is doing anything that touches funds or sensitive data.

Immutability also cuts both ways. The primary source notes on-chain pointers and hashes cannot be deleted, which is great for audit trails and brutal for sloppy schemas. Designing registration and feedback formats with revocation and supersession in mind matters because the ecosystem will accumulate permanent breadcrumbs.

This is also the right place to correct the common misconceptions. ERC-8004 does not put agent capabilities on-chain. It stores IDs, scores, and pointers. A single reputation score does not equal trust because Reputation and Validation are different ledgers meant for different risk tiers. Authorization like feedbackAuth reduces arbitrary spam, but it does not solve Sybil attacks on its own. That is the actual shape of erc 8004 how it works when an app tries to make a decision with capital at stake, and it is why 8004 agent identity is best treated as a pipeline you can tune.

The Take

I’ve watched teams build “agent trust” dashboards that collapse everything into one number, then act surprised when the number fails them. The expensive mistake is averaging Reputation and Validation like they are the same asset. They are not. Reputation is a history of authorized counterparties speaking. Validation is a priced assurance product tied to a specific claim, with the assurance tech varying from staking to zkML to TEE attestations.

If an integration is going to break, it usually breaks at the boring seam: tokenURI points to an off-chain registration file, and that file drifts. The ERC-721 AgentID stays the same, the UI still shows the same agent card, and the endpoints or identifiers quietly change underneath. That is why the identity layer in ERC-8004 is intentionally plain. The work is monitoring what it points to, and dialing validation up when the risk tier demands it.

Sources

• Backpack Learn
• Medium (Siddhant)