How many registered ERC-8004 agents answered our probe?
The ERC-8004 registry counts and our probe results are unknown for now rather than zero; this page sets them side by side as each chain is read.
Ids issued
The registry's own counter, per chain. This leads because it is exact; it is the ceiling on agents, not a count of agents that answer.
Ids issued, one row per chain
The registry contract's own id counter on each chain we probe, read exactly. An id is minted by any registration call; it is not a count of agents that answer. One row per chain, never summed, because id 41 on one chain and id 41 on another are different agents on different contracts.
| Chain | Ids issued | Read on | How we read the agents |
|---|---|---|---|
| Base | unknown | unknown | unknown |
| Ethereum | unknown | unknown | unknown |
| BNB Chain | unknown | unknown | unknown |
| Arbitrum | unknown | unknown | unknown |
| Optimism | unknown | unknown | unknown |
| Gnosis | unknown | unknown | unknown |
| Monad | unknown | unknown | unknown |
| Celo | unknown | unknown | unknown |
| Robinhood Chain | unknown | unknown | unknown |
Answered our probe
A floor and a ceiling per chain, each with the number of agents behind it and how the chain was read.
Answered our probe, as a floor and a ceiling
Of the agents with a probe result, the floor is the share with a declared endpoint that answered our probe on the day shown; the ceiling adds agents whose probe was inconclusive (a timeout, a refusal, a host we cannot reach), which may be our runner. The last column leaves inconclusive agents out: answered over answered plus agents with no endpoint or a host-side failure.
| Chain | Floor | Ceiling | Agents with a result | Among determinate results | Probed on |
|---|---|---|---|---|---|
| Base | unknown | unknown | unknown | unknown | unknown |
| Ethereum | unknown | unknown | unknown | unknown | unknown |
| BNB Chain | unknown | unknown | unknown | unknown | unknown |
| Arbitrum | unknown | unknown | unknown | unknown | unknown |
| Optimism | unknown | unknown | unknown | unknown | unknown |
| Gnosis | unknown | unknown | unknown | unknown | unknown |
| Monad | unknown | unknown | unknown | unknown | unknown |
| Celo | unknown | unknown | unknown | unknown | unknown |
| Robinhood Chain | unknown | unknown | unknown | unknown | unknown |
Our reading
Read the ids issued as the most that could be agents on a chain, and the floor and ceiling as the range of agents that answered our probe on the day shown. A range that is wide says how many probes were inconclusive; it does not say those agents failed.
A chain read in full has every registered id behind its range. A chain read as a sample says how many segments of consecutive ids it covers, and the range is an estimate over that sample, never a count for the registry.
A figure with too few agents behind it, or a sample with too few segments, is shown as not enough readings yet instead of a number.
The ids issued per chain from the registry counter, with every other tracker's count beside it, are on the which-number page. Which ERC-8004 agent count is which? →
Why the numbers differ
- Definition: a registered id, a valid registration file, a declared endpoint and an endpoint that answered are four different things, and a tracker picks one.
- Probe: we send one request per distinct endpoint on one day. A different probe, header or day gives a different answer, and a timeout is not a failure.
- Design: a full read and a sample of segments do not carry the same weight; the design is shown beside every range.
- The arXiv study 2606.26028 reported that 3% (Ethereum), 4% (BSC) and 15% (Base) of registrations exposed a valid registration file with at least one live service endpoint, on its own definition, through 2026-05-13; our denominator is agents with a probe result, so the figures are compared, not merged.
ERC-8004 registry contracts (github.com/erc-8004/erc-8004-contracts)
Our own readings of public chain data and public endpoints, taken once a day. Never added across chains; “unknown” means we hold no reading, never zero, and “not enough readings yet” means the sample is too small to publish. Data CC-BY-4.0 — attribution: data by satohub.ai.
Reference
QuestionsWhat people ask about this pageShowHide
Questions this page answers
- How many ERC-8004 agents are functional?
- Not enough readings yet. The registry count is the ceiling on agents; the share that answered our probe appears per chain once enough agents have a probe result, and until then it is shown as not enough readings yet, never as zero.
- What does answered our probe mean?
- For each agent whose registration file declares an MCP, A2A or x402 endpoint, we send one request per distinct endpoint on the day shown. It answered if the reply was a protocol handshake, an agent card or an HTTP 402 with a payment payload. It describes one probe on one day, not the agent.
- Why a floor and a ceiling instead of one share?
- A timeout, a refusal or a host we cannot reach is neither an answer nor a failure of the agent, and it may be our runner. Counting those as not answering gives the floor; counting them as answering gives the ceiling. The truth lies between.
SourcesWhere the data comes fromShowHide
Sources — the standard and the study
Cite this pagePlain text, APA or BibTeXShowHide
Cite this
Nothing to cite yet: this page holds no dated reading. The citation appears with the first one, dated by the reading itself.
How this was measured
- Method
- Once a day per chain, the ERC-8004 Identity Registry's own agent-id counter (`_lastId`, one storage read at the chain head) gives the ids issued, and each registration file's declared MCP, A2A and x402 endpoints get one request per distinct endpoint; the share of agents with a result that answered is published as a floor (inconclusive probes count as not answering) and a ceiling (they count as answering), each with the number of agents behind it, the chain read in full or as a sample of segments, and withheld as not enough readings yet below the sample floor.
- Window
- The newest chain-day with an ids-issued reading, per chain; each probe is one day's.
- Data date
- no reading yet
- MCP call
onchain_agent_get_trend({"venue":"erc8004","chain":"Base","stage":"registered","grain":"weekly","points":1})on https://satohub.ai/api/mcp- URL
- https://satohub.ai/api/export/adoption.json?stage=registered&venue=erc8004
The MCP call and the export return the registry counter (ids issued) for one chain; pass another chain for its row. The probe floor and ceiling are the published form on this page.