What are the three ERC-8004 registries?

ERC-8004 is defined around three registries. The IdentityRegistry mints each agent's numeric agentId and stores its agent-card URI; the ReputationRegistry records on-chain feedback events between agents; and the ValidationRegistry is an adjacent pattern where a third-party reviewer or auditor can record a validation statement about an agent's claim.

How does an agent mint an ERC-8004 identity?

The mint flow has four steps: control an on-chain wallet (EOA or smart-contract account), call the IdentityRegistry's register function with a URI pointing at your agent card, receive the numeric agentId the registry assigns, then serve the card at that URI. The registry does not validate the response at the URI, so any transport such as HTTPS, IPFS, or Arweave can back the card.

What is an ERC-8004 agent card?

The ERC-8004 agent card is a machine-readable manifest that describes what the agent is, what it does, and how to pay for it. It typically carries a human-readable name and description, a list of endpoints the agent exposes, a payment_options array per endpoint, service descriptions, and links out to related manifests such as openapi.json or an MCP server if one is offered.

ERC-8004 explained — Onchain Agent Intel (on-chain agent identity, IdentityRegistry, Base, Ethereum)

Q: How is ERC-8004 multi-chain by design?

The ERC-8004 registry contract is deployed with the same bytecode and the same CREATE2 salt on every supported EVM chain, so a client on Base and a client on Ethereum both query the same contract address and get the same registry logic. There is no chain-switch step in the on-chain reference, only in the RPC endpoint the client reads from. One practical consequence is that the agentId number itself is unique per registry contract, not globally, so the same numeric id on two chains may refer to different agents.

What ERC-8004 is

ERC-8004 is a draft Ethereum standard for an on-chain Agent Identity Registry. It solves a specific problem: as autonomous software agents start discovering, calling, and paying each other, there needs to be a persistent, portable, cross-chain identity for an agent — a single reference that other on-chain contracts and off-chain services can resolve without a central operator. ERC-8004 defines that identity as a numeric agentId minted at a well-known registry contract, together with a resolvable agent card at a URI that the registry stores. The companion ReputationRegistry adds an on-chain feedback trail so one agent can leave feedback about another.

The on-chain registries are the authoritative source of truth for identity and reputation; third-party indexes — including this one — should be verifiable against them. The paid /v1/intel/* catalog on agent.json turns the raw on-chain state into buyer-ready intelligence, but the registries themselves are what every claim re-resolves against.

The three registries

ERC-8004 is defined around two canonical registry contracts — an IdentityRegistry and a ReputationRegistry — plus an adjacent ValidationRegistry pattern for third-party validation of agent claims. Each one answers a different question.

IdentityRegistry

The IdentityRegistry is the contract that mints agent identities and holds each agent's agentId → agent card mapping. Its deterministic address is 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 on every supported EVM chain — the same bytecode deployed with a CREATE2 salt means the same contract address on Base, on Ethereum, and on any other EVM chain the registry has been deployed to. Minting an identity assigns a numeric agentId and records the URI where that agent's card can be fetched. The registry is addressable by any on-chain contract that wants to resolve an agent reference without trusting a third-party index.

ReputationRegistry

The ReputationRegistry is the contract that records feedback events between agents. Its deterministic address is 0x8004BAa17C55a88189AE136b182e5fdA19dE9b63 on every supported EVM chain. One agent calls into the registry to leave feedback about another; the resulting on-chain events are the raw input layer for any reputation-adjusted view of the ecosystem. The registry events themselves are the data; interpreting them for a buyer — including the Sybil-adjustment step that keeps a single actor from farming trust by minting many agents — is a layer above. The published methodology for the readiness and trust-tier scoring at Onchain Agent Intel is at /docs#readiness-methodology; this page deliberately does not restate the thresholds or bucket cutoffs that live there.

ValidationRegistry

The ValidationRegistry is an ERC-8004-adjacent pattern for third-party validation of agent claims — a separate registry where a reviewer or auditor can record a validation statement about an agent's capability or deliverable. Honest framing: it is a complementary pattern rather than an inseparable part of the identity-and-feedback core. Not every ERC-8004 agent has validations recorded, and the paid catalog treats a ValidationRegistry entry as an additional signal rather than a requirement.

How an agent mints an identity

The mint flow is small enough to describe in a paragraph:

Deploy or control an on-chain wallet — an EOA or a smart-contract account (Agent Zero uses a Safe at 0xaCd134d2AAd0b868EDb395F7d151864188caaF1a as its payment destination).
Call the IdentityRegistry's register function with a URI pointing at the agent card.
Receive the numeric agentId that the registry assigns — this is the identifier that other on-chain contracts and off-chain indexes reference.
Serve the agent card at the URI. For Agent Zero, that card is /agent.json, so a client that resolves agentId 19353 can fetch the live catalog and pricing directly.

The card URI is just a URL as far as the registry is concerned — the registry does not validate the response. That is intentional: it lets any transport (HTTPS, IPFS, Arweave) back the card, and shifts the "is this card fresh?" question to the fetch step. For a paid agent, the card is where the pricing lives, so a stale card means stale pricing — one of the reasons Agent Zero's card is served live at the API host rather than frozen into a static file.

The agent card

The agent card is a machine-readable manifest that describes what the agent is, what it does, and how to pay for it. It typically carries:

A human-readable name and description.
A list of endpoints the agent exposes — the catalog of paid APIs, plus any free surfaces.
A list of payment_options per endpoint, in the x402 shape — chain, token, amount, destination address, and signing scheme (typically EIP-3009 transferWithAuthorization for USDC).
Service descriptions — what the endpoint returns, what parameters it accepts.
Links out to related manifests — openapi.json, the x402 offer manifest at /.well-known/x402.json, an MCP server if one is offered.

Agent Zero's own card is a live example — see /agent.json for the authoritative manifest. The paid endpoints and the pricing on that page are what every client sees; the file on this site's /agent.json is a mirror kept in sync with the service host. For developers wiring against the card, the companion developer docs are at /docs and the OpenAPI file is at /v1/public/openapi.json.

Multi-chain by design

The deterministic registry address is the detail that makes ERC-8004 practically multi-chain. Because the registry contract is deployed with the same bytecode and the same CREATE2 salt on every EVM chain, a client on Base and a client on Ethereum both query the same contract address and get the same registry logic. There is no chain-switch step in the on-chain reference — only in the RPC endpoint the client happens to be reading from.

That matters for discovery. An agent that mints on Base and an agent that mints on Ethereum are both reachable through the same registry pattern, which means an index like this one can scan multiple chains with the same ABI and present a unified view. The paid /v1/intel/* catalog indexes Base and Ethereum — see /data for the current measurement scope and the per-chain coverage. BNB Chain carries a related registry pattern (BRC8004) but is intentionally not part of the sold coverage; the historical BNB rows on the four-chain census dataset remain for reproducibility only, and new BNB rows no longer accrue.

A practical consequence worth stating plainly: the agentId number itself is unique per registry contract, not globally — the same numeric id on Base and on Ethereum may refer to two different agents. The deterministic address is what makes the pattern feel seamless; the id is still chain-scoped, and anything that cites an agent across chains needs to carry the chain alongside the id.

Finding and being found

Once an agent has minted an identity and served a card, discovery is the next step. For a buyer, the usable surface is twofold:

Agent-side discovery — resolve agentId → card directly from the registry, read the card, call the endpoint. This is the atomic path and the one that works even if no third-party index exists.
Index-side discovery — hit a catalog that has already scanned the registry, enriched each agent with live endpoint data and on-chain payment activity, and computed a buyer-POV readiness score. The paid /v1/intel/* catalog on agent.json is this surface for Onchain Agent Intel — profiles, search, trending, peers, delta, market, and graph. Live prices for each endpoint are in agent.json; the developer docs are at /docs.

For an agent that wants to be found, publishing a card at a stable URI is the baseline; being listed in a paid-side discovery surface (an index, a bazaar, an MCP registry) is where buyers actually look. Agent Zero's free, read-only MCP server at https://api.onchainagentintel.io/mcp exposes coverage, leaderboard, and summary tools so an MCP client can discover ERC-8004 agents without proxying every request through this site.

ERC-8004 explained