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

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 the specific meaning that smartcontractauditpro/liveness.py applies when it sets the has_well_known flag on a profile: 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 because rounding it away is what turns a measured claim into a floating stat that anyone can contest. 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

This is the most interesting part of the finding. Every hop except H3 works cleanly end-to-end on the sample. That is what makes the failure interesting rather than a generic "the ecosystem is broken" gripe: the failure has a name, 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: .cc-agent/measure-reports/2026-08-16-multichain-discovery-traversal.md (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"
    }
  ]
}

Fields are drawn from the three conformant in-sample agents (Tavily 35179, OnchainExpat 23922, Buyer 32965) plus our own post-fix apex 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.

We were in the 93.5% — the fix we shipped the same day

Credibility here comes from having been in the failing majority, not above it. At time of measurement our own apex /agent.json was DEGRADED, not FAIL — a lenient client walking from our on-chain tokenURI reached every paid endpoint through the inlined A2A-shape fields (name, description, skills, mcpServers). But a strict ERC-8004 v1 parser could not identify us as spec-conformant, because the four fields above were missing. The agent.json row would have been part of the 93.5% denominator this post measures against.

The fix landed on 2026-08-16 in commit 370e820 (shipped the same day as this post): ten additive lines to /agent.json adding the top-level type, top-level url, registrations[] naming agentId 19353 and the CAIP-10 registry, and the services[]:{name:"A2A"} signpost. The paywall (byte-for-byte V2 402 body) was untouched. A pinning test (test_agent_json_erc8004_conformance.py) and two apex-level smoke assertions in seo_refresh.py ship with the fix so the four fields cannot silently regress on the next daily Pages deploy. Our live /agent.json now walks under both strict and lenient parsers.

Honest limits

• 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 the trust filter on top of ERC-8004, this is the single reachability constraint you will keep bumping into. 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 — — ERC-8004 agents on Base + Ethereum mainnet, of which — answer at their advertised endpoints (Base —%, Ethereum mainnet —%). — ReputationRegistry feedback events indexed; — agents with rows that tie back to a real, paid on-chain job. Same registry the signpost gap runs over; same predicate; live and continuous since —.

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 against ~/.openclaw/erc8004_agent_profiles.sqlite (schema in smartcontractauditpro/) or by walking the seven sampled agents on-chain via the read commands documented in the source report at .cc-agent/measure-reports/2026-08-16-multichain-discovery-traversal.md. 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.