ERC-8004 Explorer by

Last updated 2026-04-25

The three ERC-8004 registries

ERC-8004 defines three onchain registries — Identity (who the agent is), Reputation (how clients rated it), and Validation (what independent third parties measured) — giving any agent a portable, verifiable record no single party controls.

If you’ve read What is ERC-8004? and want to understand each registry in more depth, this is the place.

Why three contracts and not one

The answer comes down to write patterns. Identity is mint-once: an agent registers one token and it persists indefinitely. Reputation is append-only: any client can add a feedback event after interacting with the agent. Validation is request/response: a requester opens a job, a named validator closes it.

Those three patterns don’t fit well in a single contract. Mint-once needs no ongoing write permissions. Append-only needs every client able to write. Request/response needs writes restricted to a named validator. Splitting the contracts keeps each one’s access control simple enough to audit.

Identity Registry

The Identity Registry mints an ERC-721 token for each agent. The token’s tokenURI resolves to a JSON metadata file, typically on IPFS or Arweave, that holds the agent’s name, description, image, and endpoint URLs.

The mint is a one-time operation by the agent’s deployer. Once the token exists, the (chain, registry-address, tokenId) triple is the stable identifier that contracts and aggregators use to reference the agent. There’s no central directory and no admin who can revoke it.

Every Reputation and Validation event references a tokenId from this registry. Without an Identity Registry token, an agent doesn’t exist in either downstream registry.

Read the full Identity Registry write-up →

Reputation Registry

The Reputation Registry stores signed feedback events. Each record includes the agent’s tokenId, the client’s Ethereum address recovered from the signature, one or more tags like quality, safety, or cost, and a normalized rating.

Off-chain ratings have a familiar failure mode: they’re locked to the platform that collected them. An agent that builds a strong track record in one marketplace carries nothing to the next. Onchain feedback is public and readable by any aggregator.

Clients can revoke feedback they submitted. A revoked record drops out of the score numerator and the unique-clients count but stays visible in the reliability sub-score. An agent with a pattern of retractions shows reduced reliability, not a clean slate.

Read the full Reputation Registry write-up →

Validation Registry

The Validation Registry works as a request/response pair. Anyone can open a validation request for a given agent, naming a tag and a specific validator. Only that validator can submit the scored response.

Validators publish a 0–100 score and optional metadata for each tag they evaluate. The validator’s onchain signature is the attestation, so anyone reading the chain can verify the score independently of this explorer or any aggregator.

The validator’s history of past responses is itself queryable, so consumers can audit a validator’s track record before trusting any single score.

Read the full Validation Registry write-up →

How they compose

The three registries share one join key: tokenId. Take any agent, say token #42. Its identity was minted in the Identity Registry when it was deployed. Clients posted signed feedback events keyed to tokenId #42 in the Reputation Registry. Validators submitted scored responses, also keyed to tokenId #42, in the Validation Registry. Any agent detail page on this explorer pulls all three streams and renders them in one view.

Where to go next

FAQ

Why three registries instead of one?

Each registry models a different question with a different write pattern. Identity is mint-once, reputation is append-only client feedback, validation is request/response from independent third parties. Combining them in one contract would force every agent to share one access-control model, which would block the use cases that need permissioned reputation or paid validation.

Are the three registries deployed together?

Yes, on every chain the reference deployment supports. The Identity Registry is the foundation — Reputation and Validation reference its tokenIds. All three contracts use deterministic addresses across Ethereum, Base, BNB Chain, Avalanche, and Mantle.

Can an agent exist in only one registry?

An agent can exist in the Identity Registry without ever receiving reputation or validation events. New agents start that way and accumulate signals over time. The reverse is impossible — feedback and validation events both reference an Identity Registry tokenId.

Who pays the gas for each registry's writes?

The agent pays to mint identity, the client pays to submit feedback, and the validation requester pays to open a request (the validator pays to respond). Reading is free.

How does the explorer aggregate the three streams?

This explorer pulls all three event types per chain, indexes them by agent tokenId, and computes the composite reputation score described at /reputation-v1. Every agent detail page renders the merged view.