Most ERC-8004 coverage leads with the same headline: the registries hold tens of thousands of AI agents, and the number keeps climbing. That is true, but a registration count alone says little. The registry contract does not check whether the address behind an agent identity actually runs anything. Anyone can register an identity and walk away, and it is counted forever. So the count of registrations tells you what happens when it costs nothing to appear; it does not tell you what a buyer would actually find if they tried to send a job.
To answer the second question, we probe every registered agent
continuously — resolve its tokenURI,
follow the pointer to its metadata, and hit the advertised endpoint
to see whether anything answers. We call an agent
live when its declared endpoint returns 2xx and
exposes at least one machine-readable capability surface (an MCP
tool list, an OpenAPI spec, or a well-known agent card with skills
or capabilities). That one predicate is the definition used by our chain-quality audit, this blog post, the
Ecosystem Stats page, the paid
dashboard, and the public
/v1/public/stats endpoint — so
none of them can disagree on the number.
Registered vs. live, chain by chain.
Here is the state of the two chains we index. Base has the larger live pool; Ethereum mainnet has the higher live share. Values are refreshed daily and baked into this page on every deploy.
| Chain | Registered | Live (endpoint + capability) |
|---|---|---|
| Base | 23,705 | 1,408 |
| Ethereum mainnet | 3,273 | 1,129 |
| Both chains | 26,978 | 2,537 |
Numbers on this row are the most recently probed values from
/v1/public/stats. Registered counts
move only when a new agent is minted; live counts move continuously
as endpoints go up, go down, or change their advertised capabilities.
Three things about that table are worth naming out loud.
The aggregate is small. The pile has grown into the tens of thousands, and the live subset has not kept pace. The gap between the two columns is where "the ERC-8004 agent economy" as a marketing category diverges from "the set of ERC-8004 agents you could send a job to today." A buyer walking the whole registry expecting a hit rate close to 100% is not going to like what they find.
The chains are not the same product. Base is the chain where most of the interesting agents actually live — the registered pool is medium-sized and the live pool is the larger of the two. Ethereum mainnet's registered pool is small and its live ratio is by far the higher of the two chains — but this is a feature of the population, not evidence that Ethereum agents are better shepherded: the ETH registrations are heavily skewed toward ERC-4337 smart-account wallets that trivially pass a naive readiness heuristic without necessarily running a real service on top. We are not the first to observe this shape (see the paper section below).
Reachability and payment activity should be checked per agent.
What "live" is doing here — and what it isn't.
The live predicate is strict on purpose. It does not care whether
an agent has received a payment; it does not care whether the
underlying smart account exists; it does not care whether the
tokenURI resolves. It cares
about exactly one thing: is there a running service at the
endpoint the agent's own metadata points at, and does that
service expose a machine-readable description a client could act
on. If yes, the agent counts as live. If the endpoint 404s, TLS
has expired, the DNS record was let go, the well-known card is
malformed, or the server responds with an empty capability set,
the agent does not count. This is deliberately narrower than
"has ever done anything on-chain," and it is what buyers of a
trust-filter product are actually asking for — an agent they
can call, not an agent that once existed.
We publish that raw predicate: fetch
/v1/public/stats and you will
find live_by_chain,
live_agents_total,
chains_breakdown, and the
rate view live_rate_by_chain.
No key required, no rate-limit surprise — this is the ground
truth every other page on the site derives from.
Independent research says the same.
In Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem (arXiv:2606.26028, Xiong, Li, Wei, Wang, Knottenbelt & Wang, June 2026), researchers from Imperial College London and CSIRO Data61 crawled the ERC-8004 registries on Ethereum and Base through 13 May 2026 and checked, for every registration, whether the metadata resolved to a valid registration file with at least one live service endpoint. Their headline figure: only 3% on Ethereum and 15% on Base passed. That is an independent, academic read from authors with nothing to sell in this space, and it lands within a few percentage points of what we measure ourselves — the paper's Base figure of 15% brackets our current Base rate closely.
We are citing the paper as corroboration, not authority. Its data cutoff is two months old, and the composition of the registries moves; the numbers in our table above are the current values from our own probes. But the shape is the same across two independent measurements, and that matters — it means the registered-vs-live gap is a property of the ecosystem, not a quirk of one methodology.
Reputation as currently deployed is not a trust signal.
The paper's second finding is on reputation: 73.5% of reviewers on Ethereum and 90.6% on Base exhibit coordinated Sybil behavior — grouped wallets posting feedback in patterns that indicate a single actor behind them. After stripping the Sybil-flagged feedback, 15.8% of rated agents on Ethereum and 86.8% on Base are left with no valid feedback at all. The authors' conclusion is blunt: the Reputation Registry as currently deployed "cannot function as a trust signal … reputation can be manipulated at minimal cost" (abstract).
Our own reputation index shows the same shape and gives us the raw material to filter it. We currently index 710,900 ERC-8004 ReputationRegistry feedback events against 155,767 ERC-8004 agent IDs, across the full registry (including registrations outside our index), that have received any feedback. Number of those events that come from a wallet that has actually paid the agent for a completed job (via the ERC-8183 AgentCommerce hooks — see below): 1,003. The rest are feedback rows written by wallets with no on-chain payment relationship to the agent being reviewed, which is the signature of the pattern the paper describes. Only 51 agents carry any commerce-backed feedback at all — see the downloadable dataset for the per-agent rows, and the canonical reputation-trust answer page for the parallel Imperial College measurement (arXiv:2606.26028).
What a real trust signal looks like.
If most registrations are paper and most feedback is Sybil, then a useful trust signal has to be one a bulk-mint farm cannot cheaply produce. Two things clear that bar.
The first is a working endpoint, probed continuously. The Transact-ready readiness bucket on our leaderboard requires exactly this: the endpoint must be up, freshly probed, AND stamped with either received on-chain payments or a working x402 discovery response — a strictly narrower gate than raw liveness. Of the 18,264 agents we have stamped, only 62 currently clear it (for scale, 282 agents advertise x402 at all). That is a small, coherent set — and it is what you are actually shopping for when you buy the trust filter. The same “is anyone actually paying this endpoint” cut applied to the wider paid-agent internet lives on our live x402 Bazaar market map, which buckets Coinbase’s public CDP catalog by unique-payer thresholds over the last 30 days — the strong-filter cohort is a small minority there too.
The second is commerce-backed reputation. ERC-8183 (the AgentCommerce extension) defines the atomic-job flow between two ERC-8004 agents, and after a job settles it writes a feedback record into the ReputationRegistry keyed to the completed payment. That row is grounded in a real, on-chain USDC or ETH settlement between the two agents. A farm of wallets that never paid the agent cannot mint one. We surface commerce-backed feedback as a separate axis in the AI Verdict on every paid agent profile — the Sybil-adjusted reputation score is one input; whether the feedback is commerce-backed is another, harder-to-fake one.
The paid
/v1/intel/agent/{agent_id}
endpoint returns identity and capability data, the readiness
bucket, a Sybil-adjusted reputation score with unique client
counts, a commerce-backed feedback count and a plain-English list
of risk flags.
What this means.
The registry counts are real, but they are not the number that matters when you are choosing a counterparty. The number that matters is how many of those registrations are reachable and have a record of real use. A short list built on a trust filter will serve a buyer better than walking the whole registry.