Everyone keeps saying the x402 economy is booming. I wanted to know where the payments actually settle, so on 2026-09-09 I pulled the full listing of the largest public x402 directory — all 680 services, every field — plus 90 days of their change feed, and counted. Every number below comes from that one dated pull; methodology and caveats are at the bottom.
What you're looking at
The directory lists 680 services. 582 are online (86%), 60 offline, 38 degraded. Only 13 of 680 (2%) carry a verification badge.
The mix: data APIs (283), AI (116), finance (82), verification (76), and a long tail of everything else.
Pricing is quantized. 235 services charge exactly $0.01, 192 are free, 50 charge $0.02, 48 charge $0.05, 31 charge $0.10, and the median measured settlement is $0.01. x402 was designed for cent-scale machine payments, and the market took that literally.
The rails nobody expected
Services declare which chains they settle on in their /.well-known/x402 discovery document. The declarations:
| Rail | Services declaring it |
|---|---|
| Base | 647 (95%) |
| Solana | 236 (35%) |
| Polygon | 55 |
| Arbitrum | 40 |
Multi-rail overlap is heavy — declaring two or three chains is normal. But a declaration is a promise. The directory also measures actual on-chain settlements (more on how, below), and the measured 30-day picture looks different:
| Rail | Services with 30d volume | 30d volume | 30d transactions | Per-transaction |
|---|---|---|---|---|
| Base | 169 | $2,190 | 27,213 | ~$0.08 |
| Solana | 49 | $1,830 | 36,320 | ~$0.05 |
| Polygon | 15 | $1,115 | 1,540 | ~$0.72 |
Three things jump out.
1. Solana does 74% of all measured x402 transactions (36,320 of 48,937 — a measured floor from one directory, and since 307 services sit on unmeasured rails the true split could move in either direction; methodology below) with just 49 of the 172 services that have measured volume — under a third of Base's 169. That's consistent with high-frequency, low-value agent traffic — though with buyer concentration this high (see below), a few fleets could be most of it. One service, sniperx-x402, alone accounts for 21,698 of Solana's 36,320 measured transactions (~60%); the rest is spread across 75 multi-rail services and a long tail of low-volume Solana-only services. Concentrated, but not a single outlier.
2. Polygon is the value odd-one-out. 1,540 transactions at ~$0.72 each — roughly 9–14× the per-transaction value of Base or Solana. Fewer services, but the ones there are doing real money.
3. The whole economy is small. Counting each service once, measured 30-day volume is about $2,624 — roughly $87 per day. (The per-rail figures above sum to ~$5,100 because 86 services settle on two or more rails and their volume shows up in each rail's view.) And "680 services" is not "680 paying customers": the number of services with at least one measured settlement in the last 30 days is 172. The other 189 of the 361 measurable ones have a confirmed payment address and zero measured volume — a payTo on the wire, no measured traffic yet.
Arbitrum, the fourth declared rail, doesn't appear in the measured picture at all: 40 declarations, zero measured. Every service with measured volume settles on Base, Solana, or Polygon.
Most of Solana is invisible
Here's the part that surprised me: the directory can't measure most of Solana.
307 of the 680 listed services (45%) sit on a rail the directory's measurement doesn't cover — and that includes 148 of the 236 services that declare Solana support (63%). It has no visibility into the bulk of the rail doing most of the measured transactions.
Why does that matter? x402 drift — a service changing its payment address without telling anyone — is the ecosystem's top trust failure mode. I measured 90 days of it in my previous post. On Base, an address is 0x-prefixed and EIP-55 checksummed: one character wrong and a validating tool rejects it. Solana addresses are raw base58 — no checksum (Bitcoin's Base58Check adds one): one character wrong and it looks valid, and the funds are gone. Right now, the rail with the highest drift risk is also the one with the least measurement.
126 services share a payout address
126 services (19%) settle to an address they share with other listed services. The largest cluster I found: a single payout address shared with 45 other services — a whole family of crypto-risk and market-data feeds, all settling into one wallet.
That's efficient operations, but it amplifies drift: one address rotation silently breaks dozens of listings at once. Fair coin flip — a shared address is also centralized and cheap to monitor, since watching one wallet covers 46 listings. The asymmetry is in blast radius: one bad rotation breaks all of them at once, and you catch it by watching the payment address, not the website.
The drift numbers, fresh
From the 90-day change feed (pulled the same day):
- 1,086 payment-address (payTo) rotations — about 12 per day, from 30 distinct services
- 797 price changes
- 7,234 schema changes
- 9,117 total changes
The rotations are concentrated — one service alone rotated 964 times in 10 days — but a base rate of ~12 address changes per day across the directory means drift is a standing event, not a rare incident.
Who's actually paying
Of the 172 services with measured 30-day volume, 107 (62%) have a single buyer accounting for 80% or more of it. The x402 long tail is currently kept alive by a handful of agent fleets and marketplaces poking at the rails. The "thousands of agents paying tiny amounts" future is real — but today it's a small number of wallets doing most of the transactions, and the services serving them can't afford to lose that one buyer to a bad address.
What this means if you build on it
- Base is still the safe default rail. 95% of declarations and the best-measured chain. If your buyer can only pay on one chain, that's it.
- Solana is where the transaction volume is. If you're building x402 services on Solana, address verification is not a nice-to-have — that's exactly where the checksum-free pain lives.
- Check before you pay. At $0.01 per transaction, one drift hit costs you more than the check costs. My free pre-check validates the address format and EIP-55 checksum in milliseconds, and the $0.01 paid check adds the live on-chain data (wallet-vs-contract, balances, activity, wrong-network detection):
const r = await fetch(
"https://api.pennyforge.org/validate?address=0x" + address
);
const v = await r.json();
// v.valid, v.status ("valid" | "mismatch" | "format"), v.normalized
-
The census is also a JSON file. The same numbers above — the top-50 services by measured 30-day settlements (price percentile, shared-payout and verification fields, 30-day uptime, compliance grade) plus all 30 rotators with their 90-day rotation counts — is a dated, CC BY 4.0 data file (each fetch is logged, which is how I know when someone actually reads it):
api.pennyforge.org/diligence.
Method & caveats
- Full pull:
x402-list.com/api/v1/services(all 680 rows), 2026-09-09 ~05:30 UTC. Data: x402-list.com (CC BY 4.0) — the only public directory I found that publishes per-service measured traction (I checked the others; see the field guide), which is why this is the source. - Disclosure: I run Pennyforge, the $0.01 address-check API mentioned above. The census is x402-list.com's data (CC BY 4.0) and every number in this post is reproducible without my product.
- "Measured" is the directory's own on-chain settlement measurement. Their stated caveat, kept: a conservative undercount — only USDC settlements via the facilitators they measure are counted. A measured floor, not an estimate; the true numbers are higher.
- Per-rail figures credit each service's full volume to every rail it settles on (matching how the directory presents per-chain views). The per-service total above de-duplicates the 86 multi-rail services.
- 90-day change feed:
x402-list.com/api/v1/changes, pulled 2026-09-09 21:54 UTC. - Raw pull and re-computation saved by me; the
/diligencefile is the dated digest of this census.
Third in a series on measuring the x402 ecosystem: a field guide to the x402 directories · 90 days of the drift feed.
Top comments (1)
Dated single pull with the methodology stated up front is more honest than most "market research" posts in this space, so thank you for that.
The gap I'd want to see quantified: these numbers come from what services declare in their discovery document. Declaration is cheap and self-reported — Base showing 95% could partly mean "Base is the documented default in the starter tutorials", not "95% of merchants route there". Do you have any way to cross-check declared rails against actually observed settlement, even on a sample?
Also curious about the long tail of the pricing histogram. With 235 services at exactly one cent and 192 free, it looks like the market is either micro-metering or not metering at all, which makes "booming" hard to defend on volume alone. If the median is one cent, 74% of transactions could still be a rounding error in dollar terms. Would you be willing to publish total measured payment value next to the transaction share?
The verification badge figure (13 of 680) might be the most interesting number in the post and you buried it.