Published 2026-09-15 · CC BY 4.0

8004scan hasn't re-parsed a single ERC-8004 agent card since 2026-06-06 — its 100% capabilities-null column is the visible symptom

If you have written about ERC-8004 adoption in 2026, your headline agent-count almost certainly came from 8004scan.io — The Defiant and news.bitcoin.com both cite it by name for the ecosystem figure. That count is plausibly live: our own probing shows a mint-event listener still adds new rows within minutes of each registration. Everything the index reports about those agents, however — capabilities, agent_url, service endpoints — is a snapshot from a single 2.5-minute bulk pass on 2026-06-06, and has not been refreshed since. Read on for the falsifying evidence.

Two facts, both measured on 2026-09-15:

  1. On the most-used ERC-8004 explorer (8004scan.io), capabilities is null on 577 / 577 (100.00%) sampled records, and agent_url is null on 577 / 577 (100.00%) sampled records. Two of the five endpoint columns the explorer surfaces are systematically empty.
  2. When we fetched each agent's live card at source (the URL 8004scan already captured in its services field), at least 4 of 18 resolvable cards carry a non-empty capabilities field. The explorer reports these agents' capabilities as null; the agents themselves say otherwise.

Fact 2 falsifies the simple reading of fact 1. The 100% null column is not “no ERC-8004 agent publishes capabilities” — it is an index-side artefact: an explorer that stopped re-parsing agent cards, on a schedule that we independently verified, on 2026-06-06 (a 2.5-minute bulk pass, and nothing since — 101 days and counting). This post lays out both facts, quotes the falsifying agents, and publishes the dataset behind the measurement.

What this measures — and what it does not

dataset.csv is a snapshot of one third-party index (8004scan.io/api/v1/) on a single day (2026-09-15). Task 0623 established with a separate, mechanical rule that this index does not have a live re-parse loop: sampled agents' last_parsed_at timestamps either sit 0.2 to 2.0 minutes after mint (a mint-event listener) or fall inside a single 2026-06-06 06:03:08 to 06:05:41 UTC bulk window. The explorer exposes no ?refresh=1 on its detail endpoint, and no /refresh, /rescan, or /reparse sub-path exists. Our own record (8453:19353, Base) still serves the pre-2026-06-11 shape — 14 services, no A2A endpoint, 30,046 bytes — because that was our metadata document when the crawler last read us; the live card we serve today is 30,640 bytes with A2A endpoints. Same story, different agent.

So the 577 / 577 figure is exact for what it measures: 8004scan's parsed snapshot. It is not a property of the underlying agents, and this post is titled accordingly.

The falsifying evidence — 4 agents whose live cards contradict the index

Sample: N = 43 rows drawn from dataset.csv with 2 rows per (chain, anchor-frac) bucket where available. 18 rows resolved to a valid JSON agent-card at source (25 were unfetchable — mostly HTML pages returned instead of JSON, plus 3 HTTP 404s, one HTTP 429 rate-limit, and one network error). Of the 18 resolvable cards, 4 carry a non-empty capabilities field — a falsifier of the simple reading of the C2 claim, not a rate over the 577-row population:

Chain Token id Name metadata_uri (from 8004scan services[0]) Live capabilities
Ethereum 6817 Otto AI — Market Alpha Agent https://useotto.xyz/.well-known/a2a/market-alpha-agent.json {"skills":["natural_language_processing/information_retrieval_synthesis/search", ...]}
Ethereum 33793 Normie #2613 — Sadel https://api.normies.art/agents/agent-card/2613 {"streaming":false,"pushNotifications":false,"stateTransitionHistory":false,"extendedAgentCard":false}
Ethereum 33794 Normie #1444 — Hadik https://api.normies.art/agents/agent-card/1444 {"streaming":false,"pushNotifications":false,"stateTransitionHistory":false,"extendedAgentCard":false}
Optimism 0 Arca https://arcabot.ai/.well-known/agent-card.json {"streaming":false,"pushNotifications":false}

Each falsifier is a live document served by a distinct organisation (useotto.xyz, normies.art, arcabot.ai) at a URL the index itself already recorded. The 8004scan capabilities column for each of these records reads null.

Why the earlier headline was wrong

The pre-registered “C2” claim in the dataset's GRADE.md was capabilities AND agent_url null on 100% of the sample. It was measured correctly against the 8004scan API and it “held” against that API — but the implicit reading of the claim (that this reflected what agents publish) is now falsified. Source-verification found non-empty capabilities on 4 / 18 resolvable cards on the first pass; a single non-null value is enough to falsify. Publishing the corrected framing is the point of pre-registration: the statistic that survives is the narrower one, “null in one explorer's index”, and the more interesting fact is why.

The other three fields — context, not headline

For completeness, here is the 8004scan-side null distribution across all five endpoint fields it surfaces per record. capabilities and agent_url are the two that Task 0624 falsified at source; the other three (services, a2a_endpoint, mcp_server) were not source-verified in this pass and should be assumed to carry the same measurement-artefact risk.

Field 8004scan null rate (N=577)
services43.85%
capabilities100.00% (falsified at source)
agent_url100.00% (measurement artefact by same mechanism)
a2a_endpoint89.60%
mcp_server75.04%

At least one of the five endpoint fields carries a URL-shaped value on 55.98% of records; on the remaining 43.85% the record is endpoint-less as reported by the index. is_endpoint_verified (8004scan's own probe-and-answer flag) is true on 1 / 577 records — Arca on Arbitrum. Note that Arca on Optimism is one of our four falsifiers here: 8004scan captured Arca's services URL, but reports its capabilities as null. A buyer-agent that trusts the null value cannot see that Arca advertises A2A capabilities.

Per-chain breakdown

Chain N 8004scan-side endpoint-less Median total_score
Ethereum12529.60%12.04
Base12548.80%12.00
BNB12573.60%0.00
Optimism7729.87%12.04
Arbitrum12532.00%12.07

BNB Chain accounts for ~38% of the ~833k records the index reports across all chains and carries most of the null-endpoint weight; on the four smaller mainnets the endpoint-less rate is lower. These are index-side numbers; a source-verification pass on the endpoint-less rows would likely lower it further.

Who is citing this index

The registered-agent counts that appear in general-web coverage of ERC-8004 adoption trace back to 8004scan.io more often than not. Two examples on different root domains, verified 2026-09-16:

Neither citation is wrong on its own terms. 8004scan's registration count keeps rising because a mint-event listener adds rows within minutes of each on-chain mint — a mechanism we verified against 8004scan's own last_parsed_at timestamps in Task 0623. What this post narrows is the scope: the count is live, but the per-agent columns the same index exposes are frozen at the 2026-06-06 06:03–06:05Z bulk pass.

A journalist quoting the headline count stands on defensible ground. A buyer-agent that trusts the per-agent capabilities column does not. If you cite 8004scan for adoption numbers, treat the count as a moving figure — and everything else the API returns as a June snapshot.

Why this matters for buyer-agents

An ERC-8004 buyer-agent that does registry discovery via 8004scan will:

Discovery layers that do not re-parse are actively harmful, not merely incomplete, once the underlying agents' cards evolve. The right posture for a downstream router is to treat any registry-index capabilities/agent_url column as a cached hint at unknown age, and to source-verify the metadata_uri directly before routing traffic.

What this doesn't say

The dataset

Under /data/erc-8004-registry-endpoint-gap-2026-09 you'll find the 577-row CSV, the audit trail, the data dictionary, the pre-pinned claims and grades (both those that held and those that failed), and the schema.org Dataset metadata block. The dataset is now framed as an observational snapshot of one explorer's index, not a measurement of what agents publish; the two are documented as distinct in METHOD.md and DATA-DICTIONARY.md.

Two things a reproducer needs to know about the 8004scan API up front: the chain query parameter is silently ignored (use the numeric chain_id), and only sort_by=created_at&sort_order=asc is honoured — sort, order, offset, page, skip, start all return HTTP 200 with the default head slice. Both quirks are documented in DATA-DICTIONARY.md and METHOD.md.

Alongside the C2 claim (which was correctly measured but is now flagged as an index-side artefact rather than a property of the agents), this post pre-registered two other claims that FAILED at their pinned bar (C1: the endpoint-less rate came in at 43.85%, below the 60% bar; C3: one record had is_endpoint_verified=true — Arca on Arbitrum). Publishing the failed claims, and now publishing the failed reading of the held claim, is what makes the remaining framing credible.

Data and method

Licensed CC BY 4.0 — reuse it, cite it. Cite as: Onchain Agent Intel (2026). ERC-8004 registry endpoint-gap dataset (N=577, 2026-09-15). https://onchainagentintel.io/data/erc-8004-registry-endpoint-gap-2026-09.