Most measurement projects tell you what they cover. The harder and more useful thing is telling you what they don’t. Every gap below is verified rather than assumed, and every one of them makes our headline numbers a floor rather than a ceiling.
Coverage statement as of 2026-07-26.
Derived from actual run history after every pipeline cycle, not hand-maintained, so it cannot quietly drift out of date the way a written list does.
| Source | Status | Last successful pull |
|---|---|---|
| a2a_registry | live | 2026-07-30 10:03:35 |
| agentic_market | live | 2026-07-30 10:03:38 |
| price_probe | live | 2026-07-30 10:03:38 |
| x402_bazaar | live | 2026-07-30 10:00:01 |
| x402_list | live | 2026-07-30 10:03:37 |
| mcp_registry | stale | 2026-07-27 09:00:01 |
| agenteconomy_io | retired | 2026-05-20 14:01:18 |
The forward-only daily time-series begins the day we started scanning. Anything before that is not in the daily curve. A separate all-time backfill is reconstructing pre-July settlement directly from chain history; it is partially complete and its results are reported separately from the forward series, never blended into it.
We measure Base, Optimism, Polygon, Arbitrum, Ethereum and Solana. Optimism was added on 2026-07-26 after verifying its endpoints serve our actual query and that the USDC contract exists on-chain. BNB Chain is listed publicly as an x402 chain and we do NOT cover it: its public nodes refuse the log queries our scanner depends on outright, at any range and with any filter, so no batching strategy works around it. Covering BNB requires paid RPC access. We would rather report a known hole than add a chain that looks configured and silently records nothing.
api.binance.com returns 451 Unavailable For Legal Reasons from our infrastructure and www.binance.com returns 403. Measuring that surface would require egress from a permitted region, which is an unresolved cost and terms question. We have zero coverage of it and do not estimate around it.
Solana is scanned by signature history rather than block ranges. On a wallet's first appearance we fetch a bounded number of recent signatures, so any activity older than that window is not captured unless later scans reach it. Solana totals should be read as incomplete for wallets discovered recently.
Until 2026-07-26 a payer's full USDC balance decrease was attributed to us even when a single transaction also moved money elsewhere (swaps, batched payouts, fees). Pay $100 through a swap where we receive $30 and we recorded it as $100. That overstated payer attribution by $10,906.46 across 21 of 234 Solana sellers, with the worst case showing $10,741 against $37.69 actually received. The scanner is fixed so attribution can no longer exceed receipts, and the historical rows were scaled proportionally to what each seller actually received. Proportional scaling preserves the largest-payer ratio the wash rule tests, so the number of flagged wallets was unchanged by the repair. The correction is logged rather than applied silently, and the reconciliation gap it closed is now published as a per-chain metric so the same drift cannot recur unnoticed.
A scan checkpoint was corrupted to zero by a misbehaving RPC endpoint, after which every run attempted to rescan the chain from genesis and recorded nothing. Base is the largest chain in our dataset. The gap was found, root-caused and fully recovered, and the recovered volume was redistributed to the days it actually occurred using on-chain block timestamps rather than being dumped on the recovery date. Guards now reject an implausible chain tip and refuse a full-chain rescan.
Only a few hundred of the services we catalogue have ever been HTTP-probed. The remainder are untested, NOT confirmed dead. Any 'share of the agent economy that is dead' figure derived by dividing our reachable count by our catalogue count is unsupported by our data and we will not stand behind it. Real deadness exists; we do not yet know its rate and will not imply one until we measure it properly.
The endpoint resolves but refuses connections, and its own reported data never advanced past 2026-03-24. It is recorded as retired with that reason rather than being quietly removed or retried forever. Source liveness is recomputed from run history after every pipeline cycle.
A single counterparty accounts for roughly three quarters of all settlement we measure. Any headline volume figure quoted without that context is misleading even when it is arithmetically correct, which is why the economy page leads with the concentration rather than burying it.
Publishing precise cutoffs would tell anyone gaming the numbers exactly how to structure payments to stay under them, which degrades the measurement this project exists to provide. Instead every integrity seal carries wash_params_sha256, a hash of the COMPLETE live parameter set -- including the clustering thresholds, which became part of the wash methodology in v3 and so had to come inside the commitment. The values can be disclosed to an auditor and verified against seals written months earlier, so they are provable without being an evasion manual. The rule version is published in the clear, so a change in methodology is always visible even while the parameters are not.
Our clustering previously over-merged: a single shared payer was enough to fuse two sellers, and transitive linking pulled hundreds of unrelated sellers into one group including a legitimate merchant. Links now require several distinct narrow payers and any group above a size ceiling is recorded as oversized rather than treated as an operator. As of wash-rule v3 the trusted clusters DO count toward the wash figure, which added 34 flagged wallets. Oversized groups remain excluded on purpose: a large blob is a graph artefact, and treating one as an operator is exactly the kind of error this project exists to catch. Rings inside those excluded groups are therefore still under-counted, so the wash figure remains a floor.
We probed every configured endpoint on every chain with the exact query our scanner issues, not a simplified health check, because an endpoint that answers a cheap call in 100ms can still refuse or silently stall on a real one. That is precisely what cost us eight days of Base. Result: Ethereum has one usable endpoint, and no free replacement exists that we could find (one blocks log queries, one caps ranges far below what we need, one is down, and one returned an invalid chain tip that would have corrupted a scan checkpoint). Several chains also lean on the same vendor, so one provider degrading would affect more than one chain at once. Redundancy here is a budget question, and until it is resolved this is a live single point of failure we would rather state than discover again.
Because a gap someone else finds is a scandal, and a gap we publish is a specification. Anyone checking our work would surface most of the above within an hour; writing it down first is cheaper than being corrected in public, and it is the only version of this project worth running.
The corresponding claims are hash-sealed as they are published, so this page cannot be quietly revised after the fact either. See the integrity chain for how to verify that yourself, and methodology for how the numbers are made.