HTTP 402 Payment Required into a machine-payment rail. The server quotes payment requirements; the agent attaches a signed USDC authorization (typically gasless EIP-3009 on Base); a facilitator verifies and settles; the server returns the resource. Median tickets are cents; settlement is ~99% USDC.
The flow, in five steps
1. Agent GETs a resource
2. Server → 402 + payment requirements (amount, asset, network, pay-to, scheme)
3. Agent signs payment payload (EIP-3009 gasless USDC) and retries
4. Facilitator verifies and settles on-chain
5. Server returns the resourceOpen source at x402-foundation/x402 with TypeScript, Python, Go and Java implementations (the repository's folders, checked 13 October 2026) and adapters for Express, Hono, Next, and MCP. Stewardship sits with the Linux Foundation; the member list spans AWS, Google, Visa, Mastercard, Stripe, Circle, Cloudflare, Shopify, and the Solana Foundation. The multi-rail competitor is Stripe/Tempo’s MPP — cards, crypto, and Lightning in one HTTP flow. We track both; the graph is neutral about rails.
The measured numbers
| Signal | Value | Window | Source |
|---|---|---|---|
| Agent payments settled | $73M · 176M txs | May 2025 – Apr 2026 | Keyrock + Coinbase + Tempo |
| Median ticket | $0.01–0.10 | same window | Keyrock “Who Pays the Agent” |
| Below the $0.30 card-fee floor | 76% | same window | Keyrock |
| USDC share of settlement | 98.6–99% | 2025–2026 | Keyrock; x402 flow data |
| Cumulative x402 reports | 165M+ payments · ~$50M | earlier 2026 | ecosystem reports |
| x402scan live window | ~26M txs · $1.45M · 21.2k buyers | 30d, observed 2026-09 | x402scan |
| Typical payment size | $0.01–$0.10 | distribution | multiple explorers |
Explorers and reports will not match each other — they measure different objects over different windows. That is why every number above carries its window and source, and why our own tiles are timestamped. Publishing rules →
The vanity-volume problem
Volume is real and polluted: Coinbase estimated 25–30% of some 30-day windows may be leaderboard farming. Before x402 volume means anything, you must separate economic transactions from vanity loops:
- Require repeat counterparties — a buyer that pays one seller once, for dust, is a ping, not demand.
- Drop self-payments and circular flows between wallets with a common funding parent.
- Design around micropayment histograms, not mean volume — averages are pulled by outliers.
We have no one-click economic/vanity switch. What we do instead: every payment figure we publish is read from receipts, with routing hops and payments from before the registration existed left out; money that stayed in the payer's own control (its own vault position, its own address, a bridge back to itself) is published apart; and our top rank counts only counterparties that an agent outside the payer's operator set also pays, or contracts that are not bot-like routers (rank.l9.v4). For the whole x402 rail, the third-party indexer's normalised volume sits beside its raw volume on the live page.
What we can classify, and how little that is
Everything above is an argument for separating real demand from vanity loops. Here is our own attempt, with the uncomfortable number first.
x402 payers — our slice, not the rail
As of 2026-10-16 09:38 UTC. Full document, with every caveat attached, at /api/partners.
Read the third row before the rest. We can only classify payers we have already bound to an identity, and that is a fraction of one percent of the rail. These classes describe our slice. Publishing a class breakdown without the coverage beside it would invite you to read it as a picture of x402, and it is not one.
One rule inside the classification is worth stating, because it is the difference between a measurement and a tautology: a ticket may not be the evidence that promotes its own payer. An address counts as labelled only on a verified payment made before its first x402 ticket, or to a counterparty that is not an x402 recipient. Without that rule, every wallet that pays once becomes a labelled live agent, and the farms qualify first because they pay most often.
Payers and tickets are both shown for the same reason. Farms retry, so a share measured in tickets always looks worse than the same share measured in distinct payers — and quoting only one of the two is how a rail gets described as healthier or sicker than it is. How the rail itself came to exist →
Why the USDC monoculture is a tile, not a trophy
~99% single-issuer settlement is operational convenience today and a single point of failure tomorrow. The graph tracks USDT, FDUSD, PYUSD, and EURC share weekly — multi-stablecoin routing is one of the clearest product gaps in the sector. The stablecoin mix lives on the data panels as a risk widget.