ERC-8004 conformance census: four chains

354,858 agents. Base, BNB Chain, Ethereum mainnet, Celo, each pinned to a block.

This report supersedes 2026-07-29-base-cfbfcc01.md, which covered Base alone. "Supersedes" means later and wider, not republished: nothing in this project has been public. That report's numbers remain correct for the chain and run they describe, and §1 below is about what happens to their meaning once three more chains exist.

See METHODOLOGY.md for the rules behind every rung and CHANGELOG-METHODOLOGY.md for every correction this project has made to itself.

What this census found, in one fact:

Base attests at 49.2%. Across all four chains the rate is 12.2% — and Base, at 16.9% of the population, supplies 68.3% of every attested agent in existence.

---

1. The correction this report exists to make

The Base report's headline was 49.2% attested. That number is correct. As a statement about ERC-8004 it was wrong, and only more chains could show it:

The spread is 44×. Any single chain, presented as "ERC-8004", is a claim about that chain's most active platform.

And the aggregate is barely better than the parts. 12.2% is the population-weighted rate, but it is not a fact about a healthy tail: 68.3% of all attested agents are on Base and 17.9% are on Celo, where — see §6 — three addresses wrote 99.8% of the attestations for the platform that owns 88% of the chain. Both numbers belong in the same sentence, every time.

The gas hypothesis is dead

The obvious explanation for the spread is transaction cost: attestation is a write, writes cost gas, so cheap chains should attest more. The data refuses it:

Base and BSC are both cheap L1/L2s and differ by 27×. Mainnet is the most expensive chain and outperforms BSC. Fee cost does not explain attestation, and no future report should reach for it. What does explain it, on the two chains examined closely, is the presence or absence of a single platform running an attestation service.

2. What was measured

Four runs, each pinning a block so that every agent's state is read from one simultaneous moment rather than assembled over hours:

The Identity Registry is at 0x8004a169… on all four, CREATE2-deployed to the same address; deploy blocks were measured by binary search on eth_getCode, verified on both sides of each boundary.

Two population footnotes, both from the runs' own manifests:

• BSC discovered 244,285 agents and swept 244,208. 77 could not be read from the chain. They are excluded from the run rather than recorded as failures — an RPC failure is the census's problem, not the agent's. They hold no feedback (§4 reconciles this exactly), so they cost nothing but the count.
• Base discovered 60,098 and swept 60,097. The one missing agent turns out to matter a great deal. See §4.

Rung 6 (live) is not implemented, so it is absent from every result rather than reported as skipped or fail. "We did not ask" and "we asked and got no answer" are different claims and the schema keeps them different. §8 says when it ships and why it has not.

3. Rung 2 mostly measures who inlines their document

The single most useful thing in the four-chain data is that a rung's meaning changed once there was something to compare against.

90.9% of Celo's agents put their whole registration document on-chain as a base64 data: URI. On Base it is 25.8%, mainnet 23.6%, BSC 59.6%. And an inline document passes rung 2 at 100%, on every chain, because there is no network involved:

This is correct, and the spec asks for it — line 52 permits any URI scheme and lines 192–195 recommend a base64 data: URI for fully on-chain metadata. Rung 2 asks whether the registration document can be retrieved; for an inline document the answer is yes by construction.

So: rung 2's cross-chain spread is largely a measure of how many registrants inline, not of how many run a working server. Celo's 97.4% and BSC's 74.0% are inlining rates wearing a reachability label. Where a document is fetched over the network, the four chains converge tightly — 25.7% to 36.3% — and that is the reachability finding: roughly two-thirds of agents that point at a server do not get a document back from it.

This is stated as a limitation of the measure, not a defect in the agents.

4. Reputation is machine-written, and Base's feedback is two-thirds unseen

Rung 7 counts feedback entries. Until now the census had never read one: the Reputation Registry returns a value with every entry and chain::Reputation::feedback kept only the count.

The values

Reading NewFeedback directly (analysis/feedback-values.md):

The largest single tag in the entire dataset — miner-vouch, 284,066 entries — has exactly one distinct value. Two tags recur across all four chains with near-identical values: trust = 85 (78.8–94.4% of its entries) and liveness = 100 (95.8–99.3%). BSC's entire feedback population is 104 addresses. And from rung 7's own evidence, 89.1% of BSC's attested agents have feedback from exactly one author (mainnet 88.8%, celo 74.3%, base 53.5%).

What this does and does not mean. An automated liveness prober writing 100 every time a check succeeds is behaving correctly and honestly — identical values are what a working automated check looks like. The finding is that the reputation layer is largely machine-written, not that it is dishonest. Nothing here re-derives any value or verifies that a trust of 85 reflects trust.

The one agent Base could not read holds 66.4% of its feedback

The event scan reconciles exactly with the census's own stored counts on BSC, Celo and mainnet — entry for entry. On Base it resolves to the digit:

143,713  what rung 7 recorded
+ 284,072  agent 25975
+      82  revoked feedback (getSummary omits it by design)
= 427,867  every NewFeedback event on Base

Agent 25975 holds 284,072 feedback entries from 62 clients — 66.4% of every feedback entry ever written on Base — and has no row in the run. It is the single agent the manifest already records as unreadable. The sweeper was right: a failed chain read is the census's problem, not the agent's, so the agent is excluded rather than failed, and the count was recorded durably. The failure was transient — ownerOf(25975) answers at the pinned block and now. What had never been done was joining that 1 to anything.

No published number becomes wrong. "Feedback on Base" as an unqualified phrase becomes unsupportable. Every Base feedback figure in this report and its predecessor covers 33.6% of the chain's feedback events, and says so wherever it appears.

5. The Validation Registry — 23 agents out of 354,858

ERC-8004 has three registries. The census reads two. The third had never been looked at: chains.validation_registry is NULL for every chain, which the code reads as "absent", and the validations table has zero rows.

Searching for the spec's own event topics with no address filter — because filtering on NULL returns zero and would have confirmed the assumption — finds that it is deployed, and used:

23 of 354,858 agents — 0.0065%. The mechanism has never been used at all on BSC or Ethereum mainnet: 285,014 agents, 80% of the population, zero events.

No canonical Validation Registry was ever deployed by the ERC-8004 team — the curated upstream says it is still under design. The ten that exist are third-party. Nine of the ten answer getIdentityRegistry() with the canonical Identity Registry this census sweeps, so these validations concern censused agents; the tenth reverts on that getter, which the spec requires at line 347, and its 10 events are reported separately rather than pooled.

A mechanism that has not been finalised has not been rejected — 105 requests is small, but "unused" and "unwanted" are different claims and only the first is measured. Full detail: analysis/validation-registry.md.

6. Celo is one platform, and it moves every chain-level number

Celo is the outlier on every measure: highest attestation (79.5%), highest resolvability (97.4%). It is one deployer's batch.

• Two EOAs hold 87.9% of the chain (6,934 and 1,630 agents), in adjacent contiguous mint ranges — ids 169–1,875, then 1,877–9,045 — with a largest single run of 1,503 consecutive agents. No other owner has a run longer than 72.
• Their documents self-identify as CeloNova, and that set is exactly those two owners.
• One of them emits 6,934 documents with a single top-level key shape (100%). Across rung 4, CeloNova produces one SHOULD-gap signature per 2,830 agents; every other owner, one per 43.
• Three EOAs wrote the feedback for 6,825 of CeloNova's 6,836 attested agents — 99.8%.

Limits, stated plainly. None of the three clients is either owner, and the Reputation Registry already forbids owner feedback. This census never reads ERC-721 approvals, so it cannot detect feedback from an approved operator — which the spec also bans (line 217) — and nothing here alleges it. Everything measured is equally consistent with a legitimate platform minting agents for its users, hosting their metadata on-chain, and running its own attestation service.

The finding is not about CeloNova's conduct. It is that Celo's 79.5% attestation rate is not an ecosystem-level fact — it is one platform's product decisions measured at chain scale.

Full detail: analysis/celo.md.

7. Concentration is the census's recurring result

Four independent measurements, four times the same shape:

Infrastructure — measured without probing anything

The rung-6 groundwork data, across all four chains, for agents that reached rung 4. 141,299 declared service entries:

11.0% of declared "endpoints" are not network endpoints at all — they are chain addresses, email addresses, empty strings, or absent.

The 125,705 HTTP(S) endpoints resolve to 3,399 distinct hosts:

Four hosts carry 59.2% of every declared endpoint in the census; eight carry 76.9%. Folding CeloNova's two hosts together makes it the largest single operator at 27.0%, and CeloNova plus evoevo.ai account for 47.9% of all declared endpoints across four chains.

An "open-ended agent economy" whose declared service surface is half two hostnames is a finding about the ecosystem, not about those two operators.

8. What this census does not measure

Stated so that absence is never read as evidence.

• Rung 6 (live) — whether any declared endpoint answers. Not implemented, therefore absent from every result, never a failure. It ships as the first follow-up report. It has not shipped because the method needs settling (402 is payment-gated, not dead; a 404 on GET may front a POST-only service; liveness ≠ functionality) and because the probe's User-Agent must first carry a domain that resolves and a mailbox that answers — currently it promises neither.
• Every other chain. Arbitrum, Polygon, Optimism and roughly twenty more EVM networks carry the same CREATE2 registries; Solana carries a third-party port, not the CREATE2 contracts. Robinhood Chain (id 4663) has both registries deployed and zero agents minted.
• Whether money reaches an agent. Payment is read from token transfer logs and EIP-3009 authorisations, which no rung produces and this census's database does not hold. No rate for it is published until it is written into a pinned run like every other figure here.
• Feedback authenticity. Whether a value means what its tag says, and whether a client is independent of the agent. ERC-721 approvals are never read, so approved-operator self-feedback is undetectable.
• Which of eight parties "the agent" is. Owner, minter, approved operator, agentWallet, declared wallet, payment-contract controller, agent-controlled key and service operator can be eight different parties; the census reads four of them. See the role glossary.

9. Reproduction

Every result above traces to one of the four run ids in §2, each of which stamps schema_version, checker_version, checker_commit, spec_commit and a literal rerun_command onto every row it wrote. The pinned spec was re-verified byte-identical to canonical ERC-8004 on 2026-07-30 (spec/SOURCE.md).

Event-derived figures — validation, feedback values, endpoint kinds — are reproducible with cast alone; each analysis document carries its own commands. Nothing in this report requires access to our database to check.