What each of the seven checks asks, in the same vocabulary the API, the checker and this page’s own changelog use — so a claim never has two definitions to drift apart.
Checks this census runs
7_
Hundreds of thousands of AI agents are registered on public blockchains under ERC-8004, and those registration counts get cited as evidence that an autonomous agent economy exists. Nobody was checking what stands behind the counts.
AgentCount reads every registered agent on the chains it sweeps at a pinned block and asks seven checkable questions: does the registration point at a document, does the document work, does the document say which agent it belongs to, does anyone attest to the agent. Every answer is published with the evidence to recompute it, and none of them is combined into a score.
What the checks show so far: three-quarters of registration documents declare no way to reach an agent, and most reputation is written by a few automated clients. The registry is real. What it is being taken as proof of is not, and counting is the honest way to say so.
“The agent” is seven different parties wearing one word. They are frequently the same address and just as frequently not, so every claim on this site names which one it means — and says whether the census reads it at all.
register(). Often but not always the first owner, and frequently a platform registering on a customer’s behalf, which makes it the one role that separates the party that created an identity from the party that holds it. The census records it from schema 6 onward; a run swept under an earlier schema carries no minter, so a figure covering those runs was pulled by hand from the mint transaction and says so. 8004scan displays the same address as CREATOR.AgentCount is a conformance census, not a rating agency. Every agent registered under ERC-8004 on the chains this census sweeps (BNB Chain, Base, Ethereum mainnet, Billions, MegaETH, X Layer, Celo, Gnosis, Arbitrum, Polygon, and OP Mainnet) gets the same seven yes/no/skip/error questions, called checks, and every answer carries the evidence the checker collected to reach it. There is deliberately no score, grade, tier, or ranking anywhere in this product. Reaching your own conclusion from the seven answers is the point.
Each check has a short machine name. The API, the evidence keys and the downloaded archives call these rung1–7 and use the names in the second column, so anyone re-deriving a figure from an archive meets those words rather than these.
| check | machine name | shown as | what a pass establishes |
|---|---|---|---|
| 1 | registered | Registered? | The agent exists in the on-chain registry, with an owner and a document URL. |
| 2 | resolvable | Reachable? | The document URL it declared actually answers when fetched. |
| 3 | parseable | Readable? | What came back is valid JSON that a machine can read. |
| 4 | conformant | Follows the spec? | The document meets what ERC-8004 requires of it. |
| 5 | bound | Claims its identity? | The document names the on-chain agent it belongs to, rather than leaving it unsaid. |
The spec invokes RFC 2119, so MUST, SHOULD and MAY are three different promises and check 4 keeps them apart. Pinned against spec commit 68fc6765761a10fb26f0692df21c8a6f9d12b1be, checker version 0.7.0 (schema 8). ERC-8004 is a Draft: the standard can still change, which is why every result pins the exact spec text it was judged against and the pin is re-checked for drift rather than assumed current.
One requirement, and conditional — a document carrying no registrations array has nothing it must do.
| Field | Condition |
|---|---|
| registrations[].agentId | required within each entry, only when `registrations` is present |
| registrations[].agentRegistry | required within each entry, only when `registrations` is present |
Each check answers with one of a small fixed vocabulary, always in the checker’s own words: pass, fail, skipped(a check this one depends on didn’t pass, so this question could not be meaningfully asked — for example, an agent that fails check 2 cannot meaningfully be asked check 3; dependencies run within a check’s own track, not across every check number in order — check 7 depends only on check 1, so a check-2 failure never skips it), or error(the check itself could not complete — a timeout, a malformed response — which is a different claim from a clean fail). A check with no row at all was never reached this run, which this site renders as “not checked” — distinct from skipped, since “not checked” and “we couldn’t ask” are different claims.
Check 5 alone can also answer unclaimed, added 2026-07-29: the document made no binding claim (no registration entry, or an empty one) for this check to check. That is neither a pass (nothing was verified) nor a fail (a merely-recommended field, not a broken one) — it is its own, honest word for “there was nothing here to check”. Any status word this site does not recognise renders with neutral styling and the verbatim text the API sent, never guessed at as one of the words above.
A pass on every check is not a safety guarantee, and a fail is not proof of bad intent — the checks measure conformance to a spec, not intent or quality. Absence of an implemented check 6 today does not mean an agent’s endpoints work; it means that question is not yet being asked of anyone. Every claim here is scoped to exactly what the evidence attached to it shows.
agentWallet is a contract rather than an EOA, whoever that contract answers to. Appears in no registry and in none of the other roles. It is the address that actually controls the money: for the largest registrant in the dataset, 148 agents held by one owner paid into contracts controlled by 126 different addresses, none of them the owner. Ignoring this role produced a published claim that was wrong about who had been paid.| 6 | live | Answers? | A declared endpoint responds to a probe. Not implemented yet, so nobody passes or fails it. |
| 7 | attested | Has feedback? | At least one on-chain feedback entry names this agent. |
agentURIrecorded against it.data: URI. An HTTP 402 does not count as resolving.services[] actually respond. Not yet implemented — every agent currently shows no row for this check, rendered on this site as “not checked”, never as a guessed status.giveFeedback at 0x8004baa1…9b63, Blockscout-verified on Base) reverts for the owner, any approved-for-all operator, and the per-token approved address, and an eth_call simulation from the owner of a live agent reverts with “Self-feedback not allowed”. One honest limit: the registry is an upgradeable proxy, so the invariant is as permanent as its current implementation — and it binds addresses, not people; an owner submitting from a second wallet is not detectable by anyone. Note the scope of what we read: the census reads ownerOfonly, and never ERC-721 approvals, so it could not identify an approved operator even if the ban did not exist. It answers only “did anyone at all vouch for this agent”, not “was it independent” — renamed from independent on 2026-07-29 for exactly that reason.