ERC-8004 · Base · read-only

The refusal ledger

Published studies have already measured how few ERC-8004 registrations resolve to a working agent. What they report is a rate. What none of them ship is the artifact underneath it: a sample a stranger can redraw, a named refusal limb for every agent, and one receipt you can fetch by agentId. This is that, for a random sample of the Base Identity Registry.

Not a reputation score · no ranking · no agent contacted beyond a plain GET of a URL it published itself

Registry 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 on eip155:8453
Pinned block 49,430,006 · hash 0x2f1c73af317d6e81bd3b198a8287ef244f8ea25b0d628ae21304365bb21196ea
60,455 agents registered at that block · 500 sampled · run 2026-08-02 05:48 UTC
Ledger digest f01dd0580950e1f7c9f82f6c0ec6b7d7aafcd43261bc5bd36d214277df6ad6a0
How to cite / redraw
Cite the human page or summary.json. Overturn one agent without arguing the aggregate: https://geniusflow-federation.vercel.app/erc8004/receipts/<agentId>.json
Redraw the same 500 ids from the pinned block hash only (nothing from this node):
random.Random(int(pinned_block_hash[-16:], 16)).sample(range(1, N + 1), 500)
Seed block 49,430,006 · hash 0x2f1c73af317d6e81bd3b198a8287ef244f8ea25b0d628ae21304365bb21196ea
30.6%
95% CI 26.7 to 34.8%
hold an identity with no agentURI at all
The registry returns an empty string. There is no file to fetch and nothing to dispute.
36.4%
95% CI 32.3 to 40.7%
did not dereference to any body
The empty ones above, plus dead hosts, 404s, and agentURIs that are not URIs.
71.4%
95% CI 67.3 to 75.2%
fail a limb the ERC states as MUST
The URI did not resolve, the body was not JSON, or it never declared the registration type.
88.8%
95% CI 85.7 to 91.3%
also miss self-reference or endpoint liveness
The file does not point back at its own agentId, or no declared endpoint answered today.

Prior art, and what this adds

This is not the first measurement of ERC-8004 registration quality and does not claim to be. Xiong et al., Can Trustless Agents Be Trusted? (arXiv 2606.26028), crawled the full Identity Registry population on Ethereum, BSC and Base through 13 May 2026 and report 37% of Base agents with no agentURI, 26.9% carrying a valid ERC-8004 registration file, and 15% exposing a valid file with at least one declared service. Mafrur and Khusumanegara, From Agent Identity to Agent Economy (arXiv 2606.12128), reach the same shape on Ethereum from a different dataset: registration heavy, operationally shallow.

This ledger corroborates that by a different method and a later sample. Theirs is a full population crawl ending 13 May 2026; this is a 500 agent uniform draw from Base, taken in the run of 2026-08-02 at block 49,430,006 and seeded by that block's hash. Against their 37% of Base agents with no agentURI, this sample reads 30.6% (95% CI 26.7 to 34.8%). Against their 26.9% with a valid registration file, 28.6% of this sample clears every limb the ERC states as MUST. Two methods, two samples, months apart, landing in the same place is the useful part. The agreement is the result, not the novelty.

What a published rate does not give you is the thing underneath it. The addition here is operational. The sample is redrawable by a third party from public data, because the seed is the pinned block hash and nothing else. The limb order is frozen, so a refusal names the limb that failed first instead of a general verdict. Every rate carries a Wilson interval. Every sampled agentId has a receipt carrying the exact HTTP status or transport error, so a disagreement is a fetch rather than an argument. A rate you can read is a claim. A receipt you can fetch is a claim someone else can overturn.

Where they fail first

Limbs run in a frozen order and a refusal names the first one that failed, so these counts partition the sample rather than double-counting it.

First failing limbAgents
agent_uri_resolves 182
registration_schema_valid 155
registration_self_reference 83
registration_parses 20
endpoint_answers_today 4

Named reasons

Limb and reasonAgents
agent_uri_resolves:empty_agent_uri 153
registration_schema_valid:no_registration_type_declared 150
registration_self_reference:no_registrations_entry 74
registration_parses:json_parse_error:Expecting value: line 1 column 1 (char 0) 19
agent_uri_resolves:http_404 10
registration_self_reference:registrations_do_not_match_onchain_identity 9
agent_uri_resolves:http_500 6
registration_schema_valid:no_services_list 5

Every limb, reported separately

absent and not applicable never count against an agent: the ERC marks the endpoint-domain proof optional, and an agent that declares no HTTP endpoint cannot fail a liveness check. not reached means an earlier limb failed first, so this one was never observed.

Limb Spec ok fail n/a absent not reached
agent_uri_resolves MUST 318 182 0 0 0
registration_parses MUST 298 20 0 0 182
registration_schema_valid MUST 143 155 0 0 202
registration_self_reference SHOULD 60 238 0 0 202
endpoint_answers_today OBSERVED 77 42 179 0 202
domain_wellknown_proof MAY 0 16 205 77 202

Read it yourself

summary.json ledger.json (every receipt) method, in prose per-agent index EIP-8004

One agent's receipt, by agentId, from the federation origin: 

curl -sS https://geniusflow-federation.vercel.app/erc8004/receipts/1.json | jq '{agent_id, refuse_limb, limbs}'

How the sample was drawn

The registry is an ERC-721 with no Enumerable extension and no burn path, so agentIds run contiguously from 1 and the population size is found by binary search on ownerOf at a pinned block. The sample is uniform without replacement, seeded by that block's hash, so a third party redraws the identical id set from public data with no input from this node. 

random.Random(int(pinned_block_hash[-16:], 16)).sample(range(1, N + 1), 500)

What this cannot tell you