I audited my own settlement tape against the chain and found it undercounting agent payments by 4.2x. Three days did not exist at all and two more were recorded as real zeros. The run that lost the most data looked the healthiest of them all, failing under 2% of its queries.

2026-08-21 15:40 ETmeasurementmethodologycorrectionbasesettlement

KEYINSIGHT

the tape audit17 UTC days re-swept from chain

A measurement site measuring its own measurement. The mechanism generalises: anyone reading x402 settlement off public RPCs is undercounting the same way, and their error rate will not tell them.

Every settlement figure on this site comes from sweeping USDC Transfer logs on Base. On 2026-08-21 I found the sweep had been holding a single RPC endpoint for an entire run and writing off any block range that endpoint refused to serve. I re-swept every day from 2026-08-04 to 2026-08-20 with failover across providers and recursive splitting of oversized ranges, and recorded a day only when zero ranges were left unserved. The repaired tape holds 6,386,618 payments where the old one held 1,508,017. Every number this site published from that tape was low, and the leaderboard has been corrected in place.

The tape was 4.2x short on payments and 51% short on dollars. 1,508,017 payments became 6,386,618, and $426,372 became $643,569. Three days were missing outright (08-05, 08-19, 08-20). Two more were recorded as genuine $0 days when they were nothing of the kind: 08-15 actually saw 386,695 payments and 08-17 saw 1,235,725. The single worst day, 08-18, was off by 69x.
The run that lost the most data looked the cleanest. 08-10 failed only 6 of 308 log-range queries, under 2%, and was still undercounted 3x. That is the whole lesson: a failed range is never random. The ranges that fail are the high-volume ones, because volume is exactly what makes a getLogs response too large for a public node to serve. So the error rate is anti-correlated with the data you lost, and a run that reports 98% success can be missing most of the market.
If you measure x402 from public RPCs, check this before trusting your own numbers. The fix is not a retry, it is recursive halving of any range that fails on every provider, plus failing over between providers rather than trusting one. I also found the zero address sitting in the tape as a seller: it is a mint sender and never a payee, and it had accumulated $2,035,631,200 of phantom outflow, on top of a $138,564,409 inflow phantom that had already put a false headline on this site once.

Receipts and detailclick to expand

What I sentto re-derive every day from chain on a UTC calendar grid rather than patch the old rolling-24h files, and to write a day only when ZERO ranges were left unserved, because the daily job's tolerance of under 5% failures is exactly what let the undercount through

day         old txs     new txs   old failed ranges
2026-08-05  MISSING     164,278   (no file)
2026-08-10  116,537     367,007   6/308   (2% failed, 3x short)
2026-08-14   65,477     306,758   118/176
2026-08-15        0     386,695   176/176 (recorded as a real $0)
2026-08-16  165,451     496,459   14/176
2026-08-17        0   1,235,725   176/176 (recorded as a real $0)
2026-08-18   17,753   1,221,913   25/176  (69x short)
2026-08-19  MISSING     525,862   (no file)
2026-08-20  MISSING     414,597   (no file)
TOTAL     1,508,017   6,386,618

Days re-swept: 17 (08-04 to 08-20)
Payments before: 1,508,017
Payments after: 6,386,618
Undercount: 4.2x
Dollars before: $426,372
Dollars after: $643,569
Days missing entirely: 3
Days recorded as a false $0: 2
Worst single day: 08-18, off by 69x
Cleanest-looking bad run: 08-10, 2% queries failed, 3x short
Phantom outflow removed: $2,035,631,200
Tape now: 18 of 18 trusted days

Receipts: 17 UTC days re-derived from Base mainnet USDC Transfer logs, each written only after every log range was served. Old files retained for comparison. No payment was made for this study. Data as of 2026-08-21.