What we measure

In short

Every agent registered under ERC-8004 gets the same seven questions, called rungs, and every answer carries the evidence collected to reach it.
An answer is one of pass, fail, skipped, error, or — rung 5 only — unclaimed. A rung with no row at all was never reached, which this site shows as not checked: a different claim from any of the five.
Rung 6 (live) is not implemented. It shows as not checked for every agent, never as a failure — the question is not being asked of anyone yet.
There is no score, grade, tier, or ranking anywhere in this product, and no count of how many rungs an agent passed. Compressing seven independent questions into one number is the move this census exists to refuse.
Rungs measure conformance to a spec — not safety, intent, or quality. Passing everything is not an endorsement, and failing is not proof of bad intent.

Who is who

“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.

NFT ownerownerOf(agentId) — on-chain, block-dependentcensus reads this: Who holds the agent’s ERC-721 token at a given block. This is the only identity the census reads, and it is not stable: the token can be transferred, so “the owner” means “the owner at the pinned block” and nothing more. 42 of the 313 agents whose declared wallet has been paid have changed hands at least once.
Mintersender of the registration transaction — not storednot read: Who called register(). Often but not always the first owner, and frequently a platform registering on a customer’s behalf. The census does not currently store this; where a report names a minter it was pulled by hand from the mint transaction and says so. 8004scan displays it as CREATOR; capturing it is on the sweeper backlog.
Approved operatorERC-721 approve / setApprovalForAllnot read: An address the owner has authorised to act on the token. The spec bans feedback from operators as well as owners (line 217), but this census never reads approvals — so it cannot identify an operator, and no rung or report may claim otherwise.
agentWalletgetAgentWallet(agentId) — on-chain, signature-verifiedcensus reads this: The spec’s payment address: reserved registry metadata, changeable only by proving control of the new address (EIP-712, or ERC-1271 for contract wallets), and cleared automatically when the agent is transferred. Set for 40,473 agents on Base — but equal to the owner for 40,126 of them, which is the default and required no proof. Only 347 agents have verified a distinct address.
Declared wallet (convention)a services[] entry named "agentWallet" — off-chain, unverifiedcensus reads this: A community convention that appears nowhere in the spec. 920 documents use it. It carries no proof of control, no link to the on-chain identity, and is served over mutable HTTP — and for 409 agents it disagrees with the address the registry has verified. Never presented as conformance.
Payment-contract controllerowner() of a per-agent payment or vault contractnot read: Where an 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.
Agent-controlled keya TEE-held or agent-held signing key — nothing on-chain marks itnot read: An address the agent itself signs with, rather than a human. Nothing in ERC-8004 distinguishes it from any other EOA: a key in a TEE and a key on a founder’s laptop are the same 20 bytes on-chain. So the census cannot tell autonomous action from human action, and no rung or report may imply it can.
Service operatorwhoever runs the endpoints — in no registry at allnot read: The party actually answering the agent’s declared endpoints. Not recorded on-chain, not in the registration document, and not knowable from either. An agent’s owner, minter, wallet controller and service operator can all be four different parties, and nothing in ERC-8004 lets a reader tell.

AgentCount is a conformance census, not a rating agency. Every agent registered under ERC-8004 gets the same seven yes/no/skip/error questions, called rungs, 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 — compressing seven independent questions into one number is exactly the move every competitor makes, and exactly the one this census refuses to make. Reaching your own conclusion from the seven answers is the point.

The seven rungs

1 · registered: The agent id exists in the on-chain Identity Registry with anagentURIrecorded against it.
2 · resolvable: That URI can be fetched and returns a body — a strict 2xx over HTTP, or a successfully decoded data: URI. An HTTP 402 does not count as resolving.
3 · parseable: The fetched body parses as JSON.
4 · conformant: The parsed document contains every field the spec pinned below requires — see the exact list underneath.
5 · bound: The document’s own registration entry names the same agent id, registry, and chain that the on-chain lookup used to find it — the card and the registry entry agree about who this is. Since a registration entry is only recommended, not required (rung 4), a document can pass conformance while making no binding claim at all — that case is neither a pass nor a fail; it renders as unclaimed. See “What a status means” below.
6 · live: Whether the endpoints the card declares in services[]actually respond. Not yet implemented — every agent currently shows no row for this rung, rendered on this site as “not checked”, never as a guessed status.
7 · attested: Whether this agent has received at least one Reputation Registry feedback entry, from any client address at all. Runs for every agent that passes rung 1 — it does not depend on whether the document itself ever resolved, parsed, conformed, or bound. This rung does not, and cannot, check whether the feedback came from the agent’s own owner or an approved operator. The pinned spec (line 217) bans both: “The feedback submitter MUST NOT be the agent owner or an approved operator for agentId.” That is a contract-level invariant — such feedback cannot be submitted in the first place — so there is nothing here for this rung to detect. 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.

Rung 4’s fields, by severity

The spec invokes RFC 2119, so MUST, SHOULD and MAY are three different promises and rung 4 keeps them apart. Pinned against spec commit 68fc6765761a10fb26f0692df21c8a6f9d12b1be, checker version 0.6.0 (schema 7).

MUST — the only fields whose absence fails the rung

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

SHOULD — recorded as a gap, never a failure

type
name
description
image
services
registrations
services[].version

MAY — purely informational

x402Support
active
supportedTrust

What a status means

Each rung answers with one of a small fixed vocabulary, always in the checker’s own words: pass, fail, skipped(a rung this one depends on didn’t pass, so this question could not be meaningfully asked — for example, an agent that fails rung 2 cannot meaningfully be asked rung 3; dependencies run within a rung’s own track, not across every rung number in order — rung 7 depends only on rung 1, so a rung-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 rung 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.

Rung 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 rung 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.

What this does not tell you

A pass on every rung is not a safety guarantee, and a fail is not proof of bad intent — the rungs measure conformance to a spec, not intent or quality. Absence of an implemented rung 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.