The ERC-8004 → A2A Signpost Gap: Only 6.5% of Indexed Registrations Publish a Discoverable agent-card.json

Measured on-chain 2026-08-16: of 24,835 indexed ERC-8004 registrations across Base and Ethereum mainnet, only 1,604 (6.5%) publish a discoverable .well-known/agent-card.json — the standard A2A capability manifest an autonomous discovery client needs to walk from the on-chain identity to a usable, payable endpoint. The registry entry exists. The tokenURI fetch works. The walk dies at hop 3.

Published 16 August 2026 · The 1,604 / 24,835 / 5,741 counts below are a dated point-in-time measurement against our agent index at 17:20 UTC on 2026-08-16, not a live counter; the hop-by-hop matrix is a 7-row hand-picked sample and is illustrative. Counts from our own index elsewhere on the page are live. Method and raw reads are summarised below.

A registration in an ERC-8004 IdentityRegistry is a claim. For it to become useful — for another agent to actually invoke a capability and settle payment — a chain of five hops has to hold up end-to-end. When we walked that chain on 2026-08-16 across seven live agents on Base and Ethereum, every hop except hop 3 was 7/7 PASS. The registry read worked. The tokenURI resolved. The paywall shape was valid. The failure was concentrated in exactly one place: the ERC-8004 metadata does not, in most cases, signpost a walkable A2A capability manifest. That is what the ecosystem-wide 6.5% number is measuring, and it is the reason a directory of ERC-8004 agents does not, on its own, produce autonomous discovery reach.

What "discoverable" means (and why the denominator matters)

Our index is not the whole chain — it is every ERC-8004 registration our discovery pipeline has been able to see on Base and Ethereum mainnet, continuously refreshed. "Discoverable" here has a specific meaning. The agent’s advertised host answers, and a GET against /.well-known/agent-card.json on that same origin returns HTTP 200 with a body that parses as JSON and has A2A-shaped fields (a name plus at least one of skills, capabilities, or mcpServers). Nothing about the on-chain row is enough; the walkable manifest has to actually be there.

The denominator matters, so we state it. Of the 24,835 indexed Base + Ethereum registrations at 17:20 UTC on 2026-08-16, 5,741 answer at their advertised endpoints at all (that is our "live" cut), and of those 1,604 pass the A2A-discoverable predicate above. That is 6.5% of the full indexed set and 28% of the live-endpointed subset. The other ~72% of live-endpointed agents answer a request but do not publish an A2A capability manifest a strict discovery client could walk to — with or without a signpost. All three numbers cut in the same direction: the ERC-8004 → A2A hand-off is the binding constraint on autonomous discovery reach, not the on-chain read, not the URI fetch, and not the paywall shape.

The hop matrix — the cheap hops all work

Every hop except H3 works cleanly end-to-end on the sample. That makes the problem specific: it has a location and a cheap fix.

Hop	What we measured	Sample score
H1 · Registry read	`tokenURI(agentId)` + `ownerOf(agentId)` succeed on-chain.	7 / 7
H2 · URI resolve	The tokenURI body actually loads (data-URI decodes, HTTPS 200 with a JSON content-type, or ENS+eth.limo gateway resolves).	7 / 7
H3 · Agent-card discovery	tokenURI body is either strict ERC-8004 v1 with a `services[]:{name:"A2A"}` entry that resolves to a valid A2A card, or a self-contained A2A card at the tokenURI itself.	4 / 7 PASS + 1 DEGRADED (ours), 2 FAIL
H4 · Capability liveness	MCP endpoint responds 200 to a valid MCP `initialize` handshake, and/or a skill markdown is served on the same origin. Co-varies with H3.	5 / 7 PASS + 1 DEGRADED, 1 FAIL
H5 · V2 402 paywall shape	A reachable paid endpoint returns a V2-compliant 402 with `accepts[]` carrying `payTo`, `network`, `maxAmountRequired`, and `x402Version:1`. Measured on our own paid endpoint as the control — probing third- party paywalls would be crossing surfaces.	7 / 7

Sample: 7 targeted agents (our own agent 19353 on Base plus 3 third-party agents per chain), biased toward live-endpointed agents. The 7-row hop matrix is illustrative; the 6.5% ecosystem-wide number is the population figure. Do not blur the two — a 4/7 H3 sample score is not the population rate. Full evidence: 14 eth_call reads, no transactions, paywall untouched).

Two concrete failures — and the one-line fix

This section is diagnostic, not a takedown. Both agents named below shipped — their teams did the harder half of the work. The omission is a spec-ergonomics problem, not negligence: the ERC-8004 type is set, the services[] array exists, but the entry that would point a strict discovery client at an A2A card is missing.

ClawFresh · Base · agentId 20992. The on-chain tokenURI is an inline data:application/json;base64,... URI that decodes to well-formed ERC-8004 v1 metadata — the top-level type field is set correctly. Its services[] array carries a single entry: a marketplace URL (supermission.fun/api/agent-economy/marketplace/list?name=ClawFresh). There is no {name:"A2A"} entry, no registrations[], and no path for a strict client walking from the on-chain row to a capability manifest. A one-line fix — add an {"name":"A2A","endpoint":"…/.well-known/agent-card.json","version":"0.3.0"} entry alongside the marketplace URL — would move this row into H3 PASS.
Name Whisper · Ethereum · agentId 29402. Same shape, different omission. tokenURI is inline data-URI, decodes to ERC-8004 v1, and the services[] array carries only an MCP endpoint (namewhisper.ai/mcp). The MCP endpoint itself is live — a valid MCP initialize POST returns 200 with text/event-stream and a serverInfo.name: "nw-terminal". But a strict client walking from the on-chain identity has no A2A card telling it that /mcp is the discovery entry point; it would have to guess the path. One extra services[] entry (or one A2A card that lists the MCP endpoint in mcpServers) closes the gap.

Four PASS examples — the shape works in the wild

The finding is not "ERC-8004 v1 is unimplementable." Multiple agents in the sample got the four fields right, on multiple tokenURI transports, and their manifests walk end-to-end. If you are building an agent today, these are working references:

Tavily Search · Base · agentId 35179. HTTPS tokenURI at tavily-ai-search.vercel.app/_aixyz/erc-8004.json; full ERC-8004 v1 with services[{name:"A2A",endpoint:"/.well-known/agent-card.json"},{name:"MCP",endpoint:"/mcp"}]; the A2A card resolves and the MCP endpoint responds to initialize with serverInfo.name: "Tavily Search".
OnchainExpat x402 APIs · Base · agentId 23922. Inline data: URI — strict ERC-8004 v1 with the A2A signpost pointing at x402.onchainexpat.com/.well-known/agent-card.json. Client-native, no HTTP dependency for the metadata read.
Lunairefine · Ethereum · agentId 31786. ENS + eth.limo IPFS-gateway path (lunairefine.eth.limo/.well-known/agent.json); ERC-8004 v1 with an A2A entry that resolves to a served card plus a same-origin /skill.md.
Buyer · Ethereum · agentId 32965. Inline data-URI tokenURI, A2A signpost pointing at workagnt.ai/api/agents/public/buyer-edaa31/agent-card; A2A shape complete (has_name + has_url + has_capabilities + has_skills).

The reference implementation — four fields

These are the fields the four working examples above have in common, distilled into the minimal shape a tokenURI(agentId) body must carry to be identified as strict ERC-8004 v1 by a discovery client and signpost a walkable A2A capability manifest. Copy it, replace the placeholders with your agent’s values, and the H3 hop stops being a dead-end. All four fields are additive to whatever else your agent-card is already carrying — nothing in the spec prevents a hybrid document that is both a strict ERC-8004 v1 registration and a full A2A card at the same URL.

{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "url": "https://your-agent.example.com",
  "registrations": [
    {
      "agentId": <your on-chain agentId, integer>,
      "agentRegistry": "eip155:<chainId>:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432"
    }
  ],
  "services": [
    {
      "name": "A2A",
      "endpoint": "https://your-agent.example.com/.well-known/agent-card.json",
      "version": "0.3.0"
    }
  ]
}

The fields are drawn from three of the four working examples above (Tavily, OnchainExpat and Buyer) plus our own agent file at onchainagentintel.io/agent.json. The agentRegistry value uses the standard CAIP-10 eip155:<chainId>:<address> shape; Base is eip155:8453, Ethereum mainnet is eip155:1. The registry contract address is the same CREATE2 address on every EVM chain.

Our own agent file had the same gap

When we measured, our own agent file (onchainagentintel.io/agent.json) was a partial pass: a lenient client could reach every paid endpoint through the A2A-style fields, but a strict ERC-8004 v1 parser could not identify it as spec-conformant because the four fields above were missing. We added them on 2026-08-16. The payment (402) response was not changed. Our agent file now passes under both strict and lenient parsers.

Limits of this measurement

Index ≠ whole chain. The 24,835 denominator counts every ERC-8004 registration our discovery pipeline could see on Base and Ethereum mainnet at 17:20 UTC on 2026-08-16. Registrations we have not indexed — brand-new mints in the last poll window, or agents on chains we do not scan — are not in the number. The rate is stated over the indexed set, not the global registry.
Definition of "discoverable" is the H3 predicate. "Publishes a discoverable .well-known/agent-card.json" means, exactly, what the hop-3 definition in the hop matrix above says it means — a served card with A2A-shape fields on the live endpoint's origin. Agents that publish an A2A card at a different path, or under a different filename convention, would not pass this predicate even though they may be walkable by a client that guesses.
Sample vs population. The 7-row hop matrix is a small, hand-picked, live-endpoint-biased sample — it is illustrative of the failure mode, not a claim about its population frequency. The 6.5% figure is the population number, measured over the indexed set.
ipfs:// tokenURIs are an untested class. Zero of the seven sampled agents used an ipfs:// tokenURI — every tokenURI was HTTPS or inline data-URI. Clients that do not run an IPFS gateway would treat ipfs:// URIs as an H2 dead-end, and the true H3 failure rate over any ipfs subset is an open question this measurement does not answer.
Third-party paywall shapes were not probed. H5 was measured against our own V2 402 endpoint as a control. The third-party rows in the sample carry no H5 claim; probing other operators' paywalls would be crossing surfaces this audit deliberately does not cross.

Why any of this matters (in one sentence)

An agent that starts from the on-chain registry and cannot reach a capability manifest cannot transact. Registration is not discoverability. If you are building a trust layer on top of ERC-8004, this is a reachability constraint you will hit early. If you are registering an agent, the four-field reference implementation above is the smallest change that moves your row out of the 93.5%.

Backing this measurement is our live continuous index — 26,978 ERC-8004 agents on Base + Ethereum mainnet, of which 2,537 answer at their advertised endpoints (Base 6%, Ethereum mainnet 34%). 710,900 ReputationRegistry feedback events indexed; 51 agents with rows that tie back to a paid job. Same registry the signpost gap runs over; measured the same way; live and continuous since 2026-07-17.

Attribution and reuse

The 1,604 / 24,835 / 5,741 counts on this page are our own measurement, taken 2026-08-16 at 17:20 UTC. Redistribution welcome under CC BY 4.0 with a link back to this page. Reproduce by walking the seven sampled agents on-chain with plain read calls. The ERC-8004 EIP and the A2A specification are public; the reference implementation above is a distillation of what conformant agents in the sample already publish, and is offered without warranty.