# ERC-8004 Agent Registries: What They Are and How They Are Used

*Research date: 2026-10-04. Sources were fetched on that date. Every claim is labelled with its evidence type.*

**Labels:** **[F]** = fact taken from a cited source (primary unless marked *secondary*). **[I]** = my inference from the cited facts. **[U]** = uncertain, or the sources conflict.

## Short answer

ERC-8004 ("Trustless Agents") is a **Draft** Ethereum standard. It defines three on-chain registries, usually deployed once per chain: **Identity**, **Reputation** and **Validation**. Together they let software agents be discovered, and give other parties a way to decide how far to trust them, across organisations without a prior relationship [F, S1]. The Identity Registry is an ERC-721 NFT registry. Each NFT points to a JSON "registration file" that lists the agent's endpoints (A2A, MCP, ENS, DIDs, wallets). The Reputation Registry stores standardized client feedback. The Validation Registry records requests to independent validators and their responses (re-execution, zkML, TEE) [F, S1]. In practice, the Identity and Reputation registries are deployed at the same addresses on Ethereum mainnet and many EVM chains. The reference repository says the Validation Registry is still being revised [F, S2].

## 1. What the registries are

### Status and authorship
- [F] The spec is EIP-8004 / ERC-8004, "Trustless Agents". Its status is **Draft** (Standards Track, ERC). It was created on 2025-08-13 and requires EIP-155, EIP-712, EIP-721 and ERC-1271. The authors are Marco De Rossi (MetaMask handle), Davide Crapis (ethereum.org address), Jordan Ellis (google.com address) and Erik Reppel (coinbase.com address) [S1].
- [F] Purpose, from the abstract: "use blockchains to discover, choose, and interact with agents across organizational boundaries without pre-existing trust" [S1].
- [F] Context: the spec says MCP and A2A handle agent communication but "don't inherently cover agent discovery and trust", and ERC-8004 is meant to fill that gap [S1, Motivation].
- [F] The spec says payments are "orthogonal to this protocol and not covered here". x402 payment proofs appear only as optional enrichment for feedback [S1].

### Identity Registry
- [F] "A minimal on-chain handle based on ERC-721 with URIStorage extension that resolves to an agent's registration file, providing every agent with a portable, censorship-resistant identifier" [S1].
- [F] An agent is identified globally by `agentRegistry` (`{namespace}:{chainId}:{identityRegistry}`, e.g. `eip155:1:0x742...`) together with an incrementally assigned `agentId` (the token ID) [S1].
- [F] Agents register with `register(agentURI, metadata[])`, `register(agentURI)` or `register()`. The `agentURI` resolves to a registration file containing name, description, image, a `services` list (e.g. A2A agent card, MCP endpoint, ENS, DID, email), `x402Support`, an active flag, `registrations` and `supportedTrust` [S1].
- [F] Optional domain verification: an agent can publish `https://{endpoint-domain}/.well-known/agent-registration.json` whose `registrations` entry matches the on-chain `agentRegistry` and `agentId` [S1].
- [F] The registry also stores on-chain key/value metadata. The reserved key `agentWallet` is the payment address. It starts as the owner's address, can only be changed with an EIP-712 or ERC-1271 signature from the new wallet, and is cleared when the NFT is transferred [S1].
- [F] In the reference implementation, `register` mints an agent NFT and `setAgentURI` updates the URI the NFT points to [S2].
- [I] Because identity is an NFT, control of an agent entry follows ownership of the NFT. It can be transferred and is visible to standard NFT tooling. The owner can change what the identity points to at any time by updating the URI. The identity therefore anchors *who controls* an agent, not what the agent actually does.

### Reputation Registry
- [F] "A standard interface for posting and fetching feedback signals. Scoring and aggregation occur both on-chain (for composability) and off-chain (for sophisticated algorithms)" [S1].
- [F] `giveFeedback(agentId, int128 value, uint8 valueDecimals, tag1, tag2, endpoint, feedbackURI, feedbackHash)`. Everything after `valueDecimals` is optional. "The feedback submitter MUST NOT be the agent owner or an approved operator for agentId" [S1].
- [F] Feedback can be revoked (`revokeFeedback`), and anyone can append responses (`appendResponse`), for example an agent rebutting a review or a refund notice [S1].
- [F] An optional off-chain feedback JSON can reference MCP tools or prompts, A2A skills/context/task IDs, and an x402 `proofOfPayment`. The spec suggests IPFS and subgraph indexing [S1].
- [F] Read functions require a non-empty list of `clientAddresses`, because "results without filtering by clientAddresses are subject to Sybil/spam attacks" [S1].

### Validation Registry
- [F] It "enables agents to request verification of their work and allows validator smart contracts to provide responses that can be tracked on-chain". Validators "could use, for example, stake-secured inference re-execution, zkML verifiers or TEE oracles" [S1].
- [F] The agent owner or operator calls `validationRequest(validatorAddress, agentId, requestURI, requestHash)`. The named validator answers with `validationResponse(requestHash, response 0–100, responseURI, responseHash, tag)`. A validator can respond several times, for example "soft finality" followed by "hard finality" [S1, S2].
- [F] The reference implementation README says: "The Validation Registry portion of the ERC-8004 spec is still under active update and discussion with the TEE community. This section will be revised and expanded in a follow-up spec update later this year." [S2]. Its address list includes only Identity and Reputation registries [S2].

### Trust model
- [F] The spec calls trust models "pluggable and tiered, with security proportional to value at risk, from low-stake tasks like ordering pizza to high-stake tasks like medical diagnosis" [S1].
- [F] Limits the spec acknowledges itself: "Sybil attacks are possible, inflating the reputation of fake agents." Also, the ERC "cannot cryptographically guarantee that advertised capabilities are functional and non-malicious" [S1, Security Considerations].

## 2. How the registries are used

### Deployment
- [F] The reference contracts (`IdentityRegistryUpgradeable`, `ReputationRegistryUpgradeable`) are **upgradeable** [S2].
- [F] Ethereum mainnet: IdentityRegistry `0x8004A169FB4a3325136EB29fA0ceB6D2e539a432`, ReputationRegistry `0x8004BAa17C55a88189AE136b182e5fdA19dE9b63`. The same addresses are listed for Base, Arbitrum, Optimism, Polygon, Avalanche, BSC, Celo, Gnosis, Linea, Mantle, Monad, MegaETH, Metis, Abstract and others. Testnets use `0x8004A818…` / `0x8004B663…` [S2].
- [F] The spec expects "singletons per chain". It also notes that an agent registered on chain A can still operate on other chains and may register on several chains [S1, Rationale].
- [F, *secondary*] The mainnet launch was reported as 2026-01-29 [S4, citing Everstake]. I did not confirm this date from a primary on-chain source.

### Typical usage flow (as the spec describes it)
1. [F] The agent operator mints an identity (`register`) and hosts a registration file listing its A2A, MCP and other endpoints and the trust models it supports [S1].
2. [F] Clients or indexers crawl the registries to discover agents and their endpoints and trust models. The spec lists this as a test case: "Crawling all agents … and discover agent information … capabilities, communication endpoints (MCP, A2A, others), ENS names, wallet addresses and which trust models they support" [S1].
3. [F] After an interaction, clients post feedback, optionally including an x402 payment proof [S1].
4. [F] For higher-stakes work, the agent requests validation from a validator contract, and the result is recorded on-chain [S1].
5. [I] Reputation is mostly computed **off-chain**. Indexers or reputation services read the public signals and apply their own reviewer filtering. The spec expects "many players to build reputation systems" and leaves aggregation to the ecosystem, not the contracts [S1].

### Ecosystem tooling (examples, not exhaustive)
- [F] Quicknode offers an ERC-8004 explorer, a REST API and an RPC add-on covering 15 EVM networks (post dated 2026-05-18) [S3].
- [F] Polygon and 0G both publish ERC-8004 integration documentation [S7, S8]. A Rust SDK crate (`erc8004`) ships preconfigured addresses for about 30 networks [S6].

### Adoption figures (all secondary, and they conflict) [U]
- [S4] (Nevermined, 2026-04-01): about 45,000 agents in the first month (citing Everstake); 89,451 by mid-March 2026; "nearly 130,000" across the wider ecosystem (citing The Defiant).
- [S3] (Quicknode, 2026-05-18): "close to 39,000 agent registrations and more than 73,000 feedback events across 15 chains" in the first 90 days.
- [S5] (dev.to newsletter, 2026-02-28): 49,283 agents.
- [I] These counts differ by more than 3x for overlapping periods. Likely causes are different chain sets and counting methods (Identity mints versus "agents touching ERC-8004"). Registrations are cheap, and the spec itself warns about Sybil attacks. Raw registration counts are therefore weak evidence of real agent use.

## 3. Inferences
- [I] ERC-8004 is a **discovery and trust-signal layer**, not a trust guarantee. It standardizes *where* identity, feedback and validation evidence live and what shape they take. Judging that evidence is left to off-chain consumers.
- [I] The Identity and Reputation registries are the parts in production use today. Validation is the least mature part (not deployed in the reference address list, and the spec is still being revised) [S2].
- [I] The contracts are upgradeable and the spec is still Draft. Integrators should therefore expect interface changes and should consider who controls upgrades.

## 4. Uncertainty
- [U] Adoption numbers: see above. No primary on-chain count was retrieved for this report.
- [U] Whether a Validation Registry has since been deployed at a canonical address, or whether the promised "follow-up spec update later this year" has shipped, was not confirmed as of 2026-10-04.
- [U] The spec text fetched from `ethereum/ERCs` master still contains editor TODO notes. Wording may change before Final.

## 5. Unanswered questions
- Who holds upgrade authority over the canonical mainnet deployments, and are there audits? The README does not mention audits [S2].
- How much of the feedback volume comes from real paid interactions versus Sybil or self-dealing patterns (e.g. owners using unrelated addresses)?
- Which reputation aggregators are widely relied on in practice, and how do they weight reviewers?
- How will TEE attestation be represented once the validation section is revised?

## Sources
- **S1 (primary):** ERC-8004: Trustless Agents. https://eips.ethereum.org/EIPS/eip-8004 ; raw text https://github.com/ethereum/ERCs/blob/master/ERCS/erc-8004.md (discussion: https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098)
- **S2 (primary, reference implementation):** erc-8004/erc-8004-contracts README. https://github.com/erc-8004/erc-8004-contracts
- **S3 (secondary, vendor):** Quicknode, "The Quicknode ERC-8004 Stack" (2026-05-18). https://www.quicknode.com/blog/the-quicknode-erc-8004-stack-a-public-window-into-onchain-agents
- **S4 (secondary, vendor):** Nevermined, ERC-8004 agent identity statistics (2026-04-01). https://nevermined.ai/blog/erc-8004-agent-identity-statistics
- **S5 (secondary):** Agent Economy Daily #8 (2026-02-28). https://dev.to/neilvolner/agent-economy-daily-8-49283-ai-agents-now-have-on-chain-identity-306
- **S6 (secondary):** `erc8004` Rust crate docs. https://docs.rs/crate/erc8004/latest
- **S7 (secondary):** Polygon docs, ERC-8004 integration. https://docs.polygon.technology/payment-services/agentic-payments/agent-integration/erc8004
- **S8 (secondary):** 0G docs, ERC-8004 on 0G. https://docs.0g.ai/developer-hub/building-on-0g/agentic-id/erc8004