ERC-8004 Explained: The Registry for Onchain AI Agents

The Spawn indexed 165,000-plus ERC-8004 agent registrations across 25 chains during its April 2026 audit window. Fewer than 4% answered a basic tool or endpoint probe. Most failures were not subtle: placeholder registrations, dead endpoints, stale metadata, or addresses that pointed at JSON files nobody could fetch anymore.

ERC-8004 is a draft standards-track ERC for onchain AI agents. It gives each agent an identity record, metadata URI, and places for feedback and validation, but it does not prove the service is online.

Keep that context in mind if you see "onchain AI agent" and are deciding whether to spend a weekend on it. ERC-8004 has small contracts and a sensible discovery model, but the painful part is operational: an agent registration is only useful when the offchain service behind it stays online and exposes a protocol another agent can actually call.

In brief: ERC-8004 is a draft ERC for agent identity, feedback, and validation registries. A registration points to metadata; it does not prove the endpoint is alive. The practical work is metadata durability, service liveness, and clear protocol support.

How we measured liveness

[ORIGINAL DATA] The April 2026 numbers in this article come from The Spawn's indexer and quality-scoring pipeline. The crawler resolved ERC-8004 identity records, fetched agentURI metadata, parsed declared services, and ran safe endpoint probes where the metadata exposed callable surfaces.

The probe did not try to prove every possible task. It looked for enough public evidence to separate an inspectable registration from a dead or not-callable one: DNS, HTTP status, JSON shape, response time, MCP or A2A discovery where declared, x402 402 responses where relevant, and service metadata that a caller could act on. Live totals change as chains, metadata, and endpoints change, so the numbers here are an April 2026 snapshot.

The problem ERC-8004 is trying to solve

Start with the mess before the spec. You have an agent that can run SQL against a public dataset, price a token, or translate a legal clause. You want other agents and people to find it, call it, pay for it when needed, and decide whether it can be trusted. Today the usual answer is a landing page, a README, a Discord, maybe a Hugging Face card, maybe an MCP endpoint pasted into a chat. Those surfaces are weak discovery infrastructure. They do not give an autonomous caller a stable onchain identity, a standard metadata file, or a reputation trail it can verify without trusting your website.

ERC-8004 is the Ethereum Improvement Proposal for that discovery and trust job. As of this article's last update, the EIP status is Draft. It defines lightweight registries that can be deployed on L2s or mainnet as per-chain singletons, so a caller can resolve who an agent is, where its registration file lives, and which trust signals exist for it without going through one central directory.

The authors kept the standard deliberately narrow. It does not define a token, a marketplace, a staking system, or a payment rail; payment handling stays outside ERC-8004. Its core is identity first, then feedback and validation.

What you actually get: three registries

The canonical Identity Registry used by The Spawn is 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432. The same address is used across major EVM chains including Ethereum mainnet, Base, Arbitrum, Optimism, Gnosis, Polygon, Celo, Scroll, and Linea. Each chain still has its own registry state, so chain plus token ID matters. 8453:8423 and 100:8423 are different agents even if the contract address is the same.

ERC-8004 separates the standard into three logical registries.

1. The Identity Registry

This is the registration mechanism people usually mean when they say "an ERC-8004 agent." Under the hood, it is ERC-721 based: calling register(agentURI) creates a token for the agent, and the token URI is called agentURI in the spec. That URI points to an offchain registration file.

You can host the file at ipfs://, https://, or a base64 data: URI. It describes the agent with fields such as type, name, description, image, services, x402Support, active, registrations, and supportedTrust.

A typical service entry looks like this:

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

The service list can point to MCP, A2A, OASF, web, ENS, DID, email, or wallet endpoints. Labels help with routing, but the real test is whether a caller can resolve the endpoint and speak the declared protocol.

One implementation detail matters in real clients: read both the current name/endpoint shape and older type/url style metadata. Registrations in the wild are not clean. A client that assumes one exact service shape will silently throw away otherwise callable agents.

2. The Reputation Registry

The reputation registry lets a client submit feedback for an agent. The current interface accepts a signed fixed-point value, decimal precision, optional tags, an endpoint string, an optional feedback URI, and a hash for integrity. In plain terms: you can publish a compact onchain signal, then point to a richer offchain feedback file when you need more context.

The spec does not decide what the number means. A value can represent a 0-100 rating, reachability, uptime, response time, revenue, or another tagged signal. That flexibility is useful, but it means reputation quality depends on the client addresses and aggregation rules you trust. A raw average from unknown submitters is not enough.

In practice, direct onchain feedback is still sparse. Most quality scoring happens offchain, where indexers can probe endpoints, normalize metadata, and decide which reviewers or probes to count. Once a signal is worth preserving, those systems can write it back to the registry.

3. The Validation Registry

The validation registry is for independent verification of work. An agent can request validation by sending a validator address, agent ID, request URI, and request hash. The validator responds with a value from 0 to 100, plus optional evidence URI, evidence hash, and tag.

Validation is the part that could move ERC-8004 beyond a directory. Credible validators would let a future caller inspect prior results before routing similar work to the same agent. The hard question is not the function signature; it is validator trust: whose checks do you accept, under what incentive model, and for which task types?

A concrete example

Say you build a DeFi agent that rebalances a liquidity position on Base. A practical ERC-8004 registration looks like this.

You deploy the rebalancer as an HTTP service with an MCP wrapper, exposing tools such as list_positions, suggest_rebalance, and execute_rebalance. You publish a registration JSON file with a short name, a concrete description, an image, and a services array containing the MCP endpoint. You call register(agentURI) on the Base Identity Registry. After the transaction confirms, you have a token ID, and the agent is addressable by chain ID plus token ID.

An indexer can now read the registry event, fetch the registration file, parse the service list, and probe the MCP endpoint. If the endpoint answers, the agent can appear in directories like The Spawn's Base index. A person or another agent can inspect the declared tools and call the service directly.

The registration code is not the hard part. Running a real service and keeping it online is where most registrations fail.

What is working, what is broken

Here is the practical read from operating an indexer.

What works:

The identity read path is straightforward. Registry events are easy to index, agentURI gives clients a standard place to look, and the global identifier model is simple: registry address plus chain ID plus agent ID. The spec also leaves enough room for MCP, A2A, OASF, web endpoints, x402 payment hints, and future trust models without forcing every agent into one runtime.

The metadata model is useful when authors treat it like an interface, not a brochure. A clear description, a durable image, a real services entry, and a registrations array give indexers enough material to classify, probe, and route to an agent. The worked Social Intel API example in Best Practices for Registering Onchain AI Agents shows the same idea.

What breaks:

Endpoint liveness is the biggest failure mode. Our April 2026 audit put roughly 155,000 of the 165,000 indexed registrations into a dead or not-callable bucket. Common causes are tutorial agents, hackathon agents, free-tier deploys that expired, localhost endpoints, and metadata files that moved after minting.

Metadata on IPFS still needs maintenance. A CID is not enough if nobody pins it. When public gateways cannot fetch a file, the onchain token still exists, but the agent loses its description and service list. Durable metadata needs infrastructure you pay for or control, plus a fallback HTTPS copy under your own domain.

Reputation and validation are not yet carrying the system. These registries exist, but most trust decisions still come from offchain probes and indexer scoring. For now, ERC-8004 is closer to a shared phone book than a mature reputation network.

Search remains unresolved for a practical reason. Registering an agent does not make anyone find it. Chains do not rank agents by usefulness, so discovery depends on indexers such as The Spawn world map. Those indexers rank from signals like metadata quality, endpoint liveness, meaningful services, feedback, and validation evidence.

How to actually participate

Still want to ship under ERC-8004? Start with the boring parts that indexers can verify.

Choose one chain before you cross-register. Base has been the most active ERC-8004 chain in The Spawn's index, so it is a reasonable starting point if you want indexer attention. Cross-register later once the agent works.

Host metadata on infrastructure that will survive. Use paid pinning, your own IPFS node, or HTTPS under a domain you control. Do not point a permanent token at a temporary file.

Declare only services your agent can answer. For MCP, tools/list should return real tools with usable schemas. For A2A, a trivial task should produce a real response. For paid endpoints, the x402 response should expose enough payment detail for a caller to retry safely. The protocol split is covered in MCP vs A2A, and the payment flow is covered in x402 for APIs and Agents.

Before announcing the agent, run the public quality checker with its chain and token ID. It shows the same class of checks The Spawn applies in the index: metadata completeness, service shape, endpoint reachability, and protocol behavior.

For the longer argument, the manifesto page explains why we treat quality scoring as the needed scoring piece for onchain agents. The short version is simple: a registration is not proof that an agent does useful work.

The unexciting conclusion

ERC-8004 will not get your agent users by itself. It gives your agent a portable identity, a standard registration file, and shared places for feedback and validation. That solves one real problem: how a machine discovers another machine and learns where to call it without trusting one central API.

It does not solve the product problem. A registered agent still needs a reason to exist, a working endpoint, a clear interface, and evidence that it can perform the task it advertises.

The best use of ERC-8004 is as the final registration step for an agent that already works offchain. Build the service first, keep it alive, and then register it so other agents and indexers can find it. Do not confuse "registered" with "useful"; identity records cannot create value for a dead endpoint.

FAQ

ERC-8004 status

No. ERC-8004 is still Draft as of this article's last update. Builders can still experiment with the registry model, but production docs should treat specification details as moving until the EIP status changes.

ERC-8004 with MCP or A2A

No. ERC-8004 handles discovery and trust metadata. MCP and A2A handle communication and task execution. The practical combination is covered in ERC-8004 vs MCP.

Pre-registration checks

Make sure the service already works offchain. Then verify durable metadata, a concrete description, a real image, service entries that match live endpoints, and a canonical chain plus token ID. The public agent checker should pass before the registration is announced.