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-08-03.
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-09-13 16:05:11 |
| agentic_market | live | 2026-09-13 16:05:17 |
| mcp_registry | live | 2026-09-13 11:00:02 |
| price_probe | live | 2026-09-13 16:05:19 |
| x402_bazaar | live | 2026-09-13 16:00:01 |
| x402_list | live | 2026-09-13 16:05:16 |
| 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 reconstructs pre-July settlement directly from chain history and is reported separately, never blended into the forward series. Base finished on 2026-07-26. The remaining chains (Polygon, Arbitrum, Ethereum, Solana) are NOT backfilled and that work is currently paused rather than running, so any pre-July figure should be read as Base-only.
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.
Three of that day's four collection cycles never ran. Not failed, never started: our run log shows 11 runs on 2026-07-18 against 44 on every neighbouring day, with the last write before the hole at 22:12:08 UTC on 07-17 and the next at 22:00:02 UTC on 07-18. The gap is visible independently in the wallet history table and in the integrity chain, which sealed once that day instead of the usual four times. Every source is affected, not one chain. We have not determined what stopped the scheduler, and we would rather say that than invent a cause. This is distinct from, and not explained by, the Base outage covering the same week. Nothing alerted at the time, which is the real finding: the watchdog that covers our other services had never been pointed at this pipeline. It was registered on 2026-08-02, and it now checks that a cycle actually WROTE something rather than merely that it finished, so a run that completes having done nothing also alerts.
The per-transaction table holds nothing between 2026-05-20 and 2026-07-24 — the whole of June is absent. This is the same freeze already disclosed for our upstream sources: four scrapers existed but were in no schedule, so they stopped and the site kept serving their last values until we found it on 2026-07-25. The daily settlement curve does NOT come from this table (it is scanned directly from chain history, forward-only) and is unaffected. What IS affected is the recent-transactions list and any address-level view derived from it, which is built from this table and therefore inherits the hole. Separately, ongoing capture from that source is a bounded sample of roughly 400 transactions a day, not a census, so this table should never be read as a complete record of activity in any period.
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.
Until 2026-08-03 the Reality-check card on /economy read 'Endpoints that respond: 0.3% -- 169 of 55,718 listed endpoints are live'. That is the exact division the liveness_not_measured entry above already said we would not stand behind, and it ran on the front page for three weeks while the warning sat on /integrity. The mechanism was a column default: price_history.reachable is DEFAULT 0, the aggregator-listed snapshot never set it, and the liveness job read that 0 as an observation, so 55,759 services were recorded unreachable having never been contacted, against 12 that genuinely failed a probe. Of the 205 services ever probed, 198 respond. The card now divides by endpoints actually tested and states its coverage on its face; a day with no tested count withholds the figure rather than falling back to the old denominator. Listed rows now store NULL, because 'we did not look' needed its own value instead of borrowing the one for 'it failed'. Affected rows were backed up before repair and two entries were written to data_corrections. Published here rather than quietly fixed because the wrong figure had already been served.
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.