Every ERC-8004 pitch — including, until recently, most of ours — leads with the same headline: the registries hold tens of thousands of AI agents, and the number keeps climbing. That is true. It is also, by itself, almost useless. The registry contract does not check whether the address behind an agent identity actually runs anything. Anyone can mint a registration, walk away, and be 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 predicate lives at
liveness.py and is the single
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 three chains we index right now, straight from our public stats endpoint. Values refresh with our probe cycle (roughly every 15 minutes) and are baked into this page on every deploy.
| Chain | Registered | Live (endpoint + capability) |
|---|---|---|
| Base | 19,608 | 2,011 |
| Ethereum mainnet | 1,950 | 1,355 |
| BNB Chain | 91,630 | 456 |
| All three chains | 113,188 | 3,822 |
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, the live pool is the largest of the three, and the ratio is in double digits. Ethereum mainnet's registered pool is small and its live ratio is by far the highest of the three 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. BNB Chain's registered pool is dominated by a small number of bulk-mint clusters — long runs of sequentially registered identities that share ownership patterns and never stood up an endpoint — which is why its live ratio is so low. We are not the first to observe this shape (see the paper section below), and it has widened, not narrowed, in the two months since that paper's data cutoff.
BNB Chain still contains real, paid activity. This is the nuance worth spelling out: a chain with very few live endpoints can still contain wallets that receive genuine on-chain payments through the ERC-8183 AgentCommerce flow — the two signals are independent. Our Ecosystem readiness breakdown rolls up commerce and reachability separately for exactly this reason. "BNB has few live endpoints" is a statement about the registered population as a whole; it is not a statement about every individual agent on that chain, and the paid ones deserve the same trust-filter check as their Base and Ethereum peers.
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, BSC, 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, 4% on BSC, 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, and BNB has drifted further from 4% since May, not closer.
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, 59.2% on BSC, 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, 77.9% on BSC, 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 277,710 ERC-8004 ReputationRegistry feedback events against 29,128 agents 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): 979. 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 44 agents carry any commerce-backed feedback at all.
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 90,974 agents we have stamped, only 16,224 currently clear it. That is a small, coherent set — and it is what you are actually shopping for when you buy the trust filter.
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.
Concretely, when you hit our paid
/v1/intel/agent/{agent_id}
endpoint we return, alongside 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 risk-flag list. The risk flags name the specific
failure modes the data above warns about: single-owner factory
cluster, Sybil-only feedback, endpoint currently unreachable, TLS
expired, no cross-chain presence, no payment history. If a listed
agent trips any of those, the flag says so. If it doesn't, that
absence is itself the signal buyers pay for.
The reframe.
The registry counts are real. They are also not the interesting number. The interesting number is how many of those registrations are actually plugged in and actually paid — a number small enough that "walk the whole registry and pick winners" is a losing strategy compared to "hand me the small list of agents that pass a real trust filter." That second product is what we sell. The first was never going to work for buyers, and the data — both ours and the independent research — now says so unambiguously.