ERC-8004 Explained: The Onchain Agent Registry

ERC-8004 gives an AI agent a chain record, a metadata pointer, and optional places for feedback and validation. The registry does not run the agent, keep its endpoint online, verify every service claim, or prove a paid call will complete.

The Spawn's June 16, 2026 production snapshot counted 516,375 indexed ERC-8004 registrations across 28 chains. Only 259,298 had parsed metadata, 44,782 declared services, and 1,793 were in The Spawn's S/A/B quality tiers. The right conclusion is not "500K working agents." It is "500K registry records need filtering before anyone should call them."

In brief: ERC-8004 is a draft ERC for agent identity, discovery metadata, feedback, and validation. A useful listing still needs a resolvable agentURI, clear metadata, declared services that match public endpoints, and a separate runtime check through The Spawn checker before a person or another agent relies on it.

Use this guide when you need the mechanics. Use the 500K onchain agent registry snapshot when you need scale numbers, the registration checklist when you are publishing an agent, ERC-8004 vs MCP when you are comparing registry identity with runtime protocol, and spawnr when you are ready to inspect or install an MCP-capable agent from a public record.

What ERC-8004 records

The official ERC-8004 EIP describes an identity registry plus optional reputation and validation registries for trustless agents. As of this update on June 29, 2026, the public EIP page lists the standard as Draft.

Most builders mean the identity registry when they say "register an agent." Registration creates an ERC-721-style record: the token ID is the agent ID, and the token URI is called agentURI, pointing to an offchain registration file.

The standard registry used by The Spawn is:

0x8004A169FB4a3325136EB29fA0ceB6D2e539a432

A Base record and a Gnosis record can use the same registry address while holding different token IDs, metadata, and service history. Public routing should identify an agent by chain plus agent ID, such as base/30271.

The three ERC-8004 registries

ERC-8004 separates registry identity from trust signals. That separation is useful because different callers need different evidence before using an agent.

Registry	What it stores	What it does not prove
Identity Registry	Agent ID, owner, and agentURI metadata pointer	Endpoint uptime, service correctness, payment success, or usefulness
Reputation Registry	Feedback values, tags, optional feedback URI, and hashes	That unknown reviewers are trustworthy or that a current endpoint works
Validation Registry	Validator responses, scores, evidence URI, and hashes	That a validator is authoritative for every task type

The identity registry is enough for discovery because it tells an indexer where to look. Reputation and validation entries can add context, but reviewer selection, evidence quality, and aggregation rules still decide whether those signals are useful. Raw registry presence is not the same as a working product.

What the agentURI should contain

An agentURI should resolve to a registration file that another system can fetch and parse without guessing. The exact file can live behind https://, ipfs://, or a data: URI. The practical fields are the ones that help an indexer understand what the agent is, how to inspect it, and which registration is canonical.

A useful registration file includes a concrete name, a specific description, a durable image, an active flag, service entries, x402 support only when relevant, and a registrations[] entry that points back to the chain and token ID.

For a service entry, the current EIP example uses name and endpoint:

{
  "name": "MCP",
  "endpoint": "https://mcp.agent.eth/",
  "version": "2025-06-18"
}

Older files in the index also use type and url, so careful indexers read both shapes. Builders should avoid vague service rows such as "API" with no usable endpoint. A service entry is not decoration; it is the routing hint a caller will test next.

What the June 16 registry snapshot showed

Use the June 16 snapshot to discuss scale without overstating liveness. The saved JSON record preserves the exact production read used here.

June 16 production field	Count
Total agent registrations	516,375
Indexed chains	28
Agents with parsed metadata	259,298
Agents declaring services	44,782
Agents with an x402 signal in indexed data	191,456
Agents in S/A/B quality tiers	1,793

Those are not official ERC-8004 adoption totals. They are a dated production read from The Spawn's public analytics surface. Counts move when chains sync, metadata changes, gateways respond differently, and probes rerun.

The denominator split is the useful lesson. Registration volume is the broadest number; parsed metadata, declared services, and S/A/B quality tiers each require more evidence than a raw registry event.

Why registry presence is not liveness

A chain registry can store a pointer, but the offchain service behind that pointer can still disappear.

Common failure modes are ordinary web failures: an HTTPS host expires, an IPFS CID is not pinned, a JSON file changes shape, a service list points to localhost, a server returns HTML where JSON was expected, or a protocol endpoint answers with a generic page instead of MCP, A2A, or API behavior.

The Spawn separates checks so one successful step does not hide the next failure:

Check	Question
Metadata resolution	Can the agentURI be fetched and parsed?
Metadata completeness	Does the file explain the agent, owner surface, image, services, and canonical registration?
Service declaration	Does the file name real endpoints for API, MCP, A2A, web, or another surface?
Endpoint inspection	Does the public URL answer a safe probe now?
Protocol inspection	Does the endpoint speak the protocol it advertises?
Payment inspection	If x402 is declared, does the endpoint expose payment details that a caller can evaluate separately?

Failure can happen at any step: a valid chain event with no metadata, metadata with no service, an MCP declaration that fails initialization, or an x402 hint without evidence of a completed paid retry. The article keeps those results separate because merging them would turn a registry event into an unsupported liveness claim.

A public example: Social Intel on Base

Social Intel API is a useful worked example because its registry record, public API record, and demo route are inspectable without internal access.

The current public profile is /agents/base/30271, and the machine-readable API record is https://thespawn.io/api/v1/agents/base/30271. On June 29, the public API response identified Social Intel API, chain_slug: "base", agent_id: 30271, tier B, score 73.2, and service entries for MCP, A2A, API, and web.

Its API record included this service shape:

[
  {
    "name": "MCP",
    "version": "2025-06-18",
    "endpoint": "https://socialintel.dev/mcp/"
  },
  {
    "name": "A2A",
    "version": "0.30",
    "endpoint": "https://socialintel.dev/.well-known/agent-card.json"
  },
  {
    "name": "API",
    "endpoint": "https://socialintel.dev/v1/search"
  },
  {
    "name": "web",
    "endpoint": "https://socialintel.dev/"
  }
]

Registry-backed products should expose one canonical agent record, a clear description, and separate public surfaces for the ways a caller might inspect or use the service.

A public demo endpoint is available at https://socialintel.dev/v1/search?demo=true&query=fitness. On June 29, that route returned JSON with demo: true, count: 3, a paid_url, and a documented next step. Demo output proves the preview route answered; paid x402 settlement and long-term service liveness require separate checks.

How builders should publish an agent registry record

Start with a service that already answers. ERC-8004 works best around a public surface, not as a placeholder for a future product.

A safer publishing order:

1. Build the service first, including the API, MCP, A2A, or web surface you intend to publish.
2. Host metadata somewhere durable enough for indexers to fetch later.
3. Write a description that names the job, inputs, outputs, demo mode, payment model if relevant, and protocol surfaces.
4. Add service entries only for endpoints you expect callers to inspect.
5. Choose one canonical chain and token ID before promoting the agent.
6. Register the agentURI on the ERC-8004 Identity Registry.
7. Run The Spawn checker against the public chain and token ID.
8. Link readers to the canonical profile, such as /agents/base/30271, instead of splitting attention across duplicates.

For the longer publishing walkthrough, read How to Register an Onchain AI Agent People Can Actually Find.

How readers should inspect a registered agent

Start from the registry record, then ask what current evidence exists.

For a human reader, the shortest path is:

1. Inspect the public profile and confirm the chain plus agent ID match the record you intend to use.
2. Run the checker so metadata, services, and endpoint findings are shown separately.
3. Read the services list and note whether the listing claims API, MCP, A2A, web, or payment support.
4. Test a demo or read-only endpoint when one exists, keeping the result dated.
5. Compare identity versus runtime protocol in ERC-8004 vs MCP.
6. Use spawnr only after the record and endpoint look worth installing.

Automated callers should follow the same shape: resolve agentURI, parse metadata, normalize service entries, probe safely, and keep the result dated. Old probe results should not become permanent claims.

ERC-8004 vs MCP in one paragraph

ERC-8004 handles agent identity and discovery records; MCP handles runtime access to tools, context, and workflows. The record can point to an MCP endpoint, but callers still need MCP initialization, tool discovery, and a safe tool call. Conversely, an MCP server can be callable from an AI host without having an onchain identity record, reputation entry, or validation entry. Public MCP services that should also be discoverable as agents can use both, with runtime behavior verified separately.

Source and method

Public source URLs used for this article:

• ERC-8004 EIP: https://eips.ethereum.org/EIPS/eip-8004
• June 16 registry snapshot: https://thespawn.io/learn-snapshots/500k-onchain-agents-2026-06-16.json
• Example profile: https://thespawn.io/agents/base/30271
• Example API record: https://thespawn.io/api/v1/agents/base/30271
• Example demo route: https://socialintel.dev/v1/search?demo=true&query=fitness

Dated numbers come from the June 16 snapshot. The Social Intel example is a June 29 public API and demo-route read. These are inspection examples, not permanent liveness, payment, safety, ownership, or finality guarantees.

FAQ

Is ERC-8004 final as of June 29, 2026?

The public EIP page listed ERC-8004 as Draft when this article was updated on June 29, 2026. Builders can use the registry model, but implementation details should be checked against the current EIP before production decisions.

Is an ERC-8004 registration proof that an agent works?

No. The chain record exists, but callers still need to resolve the agentURI, inspect metadata, check service entries, and test public endpoints separately.

What is an onchain agent registry?

An onchain agent registry is a chain-backed identity and metadata system for agents. Indexers and callers get a shared starting point, while the actual agent usually runs offchain through API, MCP, A2A, or web endpoints.

Should every MCP server register as an ERC-8004 agent?

Not automatically. Register when the MCP server is meant to be discovered as a public agent and you can maintain the metadata and endpoint. Use ERC-8004 vs MCP for the protocol split.

How should I start evaluating or publishing a record?

Existing records should go through The Spawn checker and a public profile such as /agents/base/30271. New publishers should start with the registration checklist.