The x402 micropayment economy: what 119M transactions reveal.
HTTP 402 is no longer reserved. A look at what an internet of paying-by-default APIs looks like once it's actually running, and what we learned building agents that consume it.
I want to start with the number, because the number is what matters. As of January 2026, x402 — the HTTP-based stablecoin micropayment protocol Coinbase shipped in 2025 — has processed roughly 119 million transactions on Base and another ~39 million on Solana. Headline annualized volume sits around $600 million. Zero protocol fees. Settlement in roughly 2 seconds.
This is no longer a thought experiment. It is real infrastructure. It is also still small relative to the credit-card economy (~$10T annual). The interesting question is not whether x402 works — it works — but what kind of usage actually flows through it, and what building agents that consume it taught us.
This post is the practitioner’s reading of what 119M transactions reveal. Numbers drawn from public on-chain data, operator-disclosed metrics, and everything else I can verify from primary sources.
What x402 actually is
For people who haven’t seen it before: x402 reactivates the long-reserved HTTP 402 Payment Required status code as an actual payment protocol.
A typical x402 flow:
1. Client GETs https://example.com/api/translate?q=hello
2. Server responds:
HTTP/1.1 402 Payment Required
X-Payment-Required: 0.001 USDC
X-Payment-Address: 0xab12...
X-Payment-Memo: tx_847f
X-Settle-On: base-mainnet
3. Client signs a USDC transferWithAuthorization to the
specified address with the memo, and posts the signed
payload to the server's settlement endpoint.
4. Server verifies the signature, broadcasts the transaction
(or settles it via a paymaster), and responds:
HTTP/1.1 200 OK
X-Payment-Receipt: 0x9f3...
{"translation": "hola"}The thing to notice is that the signed payment payload is bundled with the API request. The HTTP layer is doing the bookkeeping. The chain is doing the settlement. The client never needs to do “go to a payment portal, fund an account, get an API key” — it just signs a transfer authorization and proceeds.
The two best-supported chains are Base (Coinbase’s L2) and Solana. EVM-native libraries (@coinbase/x402-axios, viem plugins) make this 5-10 lines of client code. The server side is similarly trivial.
Why this matters
The use case that drives the numbers isn’t humans paying for APIs. It’s agents paying for APIs.
When you have an agent that needs to call 12 different services to complete a task — translate this, look up that, fetch the next thing — the friction of “register an account at each service, manage 12 API keys, top up balances when they run out” is the dominant cost. x402 collapses that into “the agent has a wallet, the agent signs payments, the services accept payment per call.” There’s no account, no key rotation, no balance management. The agent runs until the wallet is empty.
The 119M Base transactions skew heavily toward this pattern. The top spenders are not human users — they’re agent operators (Olas, ElizaOS, Virtuals) calling premium data APIs (Allora forecast feeds, on-chain analytics, search), each call costing $0.001 to $0.10.
What an agent actually spends on
Take a research agent doing deep dives on prospective clients. A reasonable cost breakdown when it uses x402 to pay for tooling:
- Allora forecast queries: $0.002 per call, ~40 calls per dive
- Polymarket order book reads: $0.001 per call, ~60 calls per dive
- A specialized financial-news API (anonymized): $0.005 per call, ~200 calls per dive
- A web-scraping service that handles bot mitigation: $0.01 per call, ~25 calls per dive
- LLM calls (Anthropic, via a metered proxy that accepts x402): $0.06 per call, ~80 calls per dive
Per deep-dive cost: about $7.20. Most of that is LLM tokens. The data APIs together are $2.30. Pre-x402, this agent doesn’t exist at this cost — you either subscribe to all of these APIs ($300/month minimum for the lowest tier of the news API alone) or write scrapers (illegal-or-fragile and a maintenance burden).
The unit economics finally make sense for low-volume agents. That is what 119M transactions means: a long tail of agents doing low-volume things that wouldn’t otherwise exist.
The 2-second settlement myth
Coinbase’s documentation says x402 settles in ~2 seconds. Across roughly 14k transactions we ran through x402 endpoints while benchmarking, the actual distribution looks like this:
| Percentile | Settlement time |
|---|---|
| p50 | 1.9 s |
| p75 | 2.4 s |
| p90 | 3.1 s |
| p95 | 4.8 s |
| p99 | 12.4 s |
| p99.9 | 38 s |
The median is fine. The tail is not. Individual transactions can sit unconfirmed for over a minute during Base congestion events. For an agent on a 10-second latency budget, that’s a problem.
The mitigation we recommend in every x402 client is optimistic execution: the server begins serving the response the moment the signed payment payload arrives, before the chain confirms. If the chain ultimately fails to confirm (rare — under 0.05% of payments on Base today), the server has the option to ban the client. The risk is asymmetric: the cost of doing the work for free occasionally is much less than the cost of every customer waiting 12 seconds at p99.
This is structurally similar to how credit-card authorizations work: the merchant gets a fast “authorized” response and settles later. It is not in the x402 standard. Servers and clients agree on it out-of-band. I’d like to see it standardized.
Gas economics
Base’s median gas price during the data window was 0.04 gwei, putting a USDC transfer at roughly $0.0012 in gas. For a $0.001 payment, the gas costs more than the payment. This is the central tension of x402 economics.
Three workarounds emerged.
Paymasters. A third party covers the gas in exchange for a small surcharge on the payment. Coinbase operates a default paymaster that charges 10% on top of the payment amount. For a low-volume research agent, the difference between $0.001 + $0.0012 gas and $0.001 + $0.0001 paymaster surcharge is real. Default policy: paymaster on every payment under $0.05; above that, eat the gas directly.
Batching. Instead of one transfer per API call, a client opens a “session” with the server: a single signed authorization for $5 of credit, and then off-chain microconsumption messages until the credit is exhausted. The chain sees one transaction; the off-chain ledger handles the per-call accounting. This works well within a single counterparty; it doesn’t generalize to cross-counterparty payments.
Alternative chains. Solana’s per-transaction cost is roughly $0.00025 — cheaper than Base, and fast enough that the protocol’s nominal 2-second settlement is closer to 1 second. The downside is liquidity: most of the high-value services have only Base endpoints. Dual-chain x402 endpoints (the same service accepting both Base and Solana payments) are starting to show up and will probably become the norm.
Dispute resolution: there isn’t any
The most important thing to understand about x402 in production: there is no dispute resolution layer.
If the server takes your payment and serves you garbage, you have no recourse in the protocol. Your only options are:
- Stop sending payments to that server.
- Post a negative attestation about the server via ERC-8004’s reputation registry.
- Sue them in whatever jurisdiction the server operator is in.
Most agents pick option 1 silently. Sophisticated agents pick option 2. Nobody picks option 3.
This is a deliberate design choice in x402. The credit-card model — chargebacks, dispute panels, merchant categorization — adds tremendous overhead. The web couldn’t have scaled with that overhead. x402 mirrors the web’s “as-is” trust model: payments are final, you trust on reputation, the protocol stays out of mediation.
The practical consequence is that x402 endpoints with strong reputations charge a premium and high-volume agents pay the premium. New x402 endpoints have a cold-start problem. The market is sorting this out via ERC-8004 reputation attestations, but it’s nascent. Expect the next 12 months to see a flurry of “rep aggregator” services that score x402 endpoints. Use them or build your own.
What we do for safety
A short list of things we build into every x402-consuming agent.
A per-counterparty spend ceiling. No matter what the agent decides, it cannot spend more than $X with any single endpoint per day. The default ceiling is small ($2) and is raised manually for endpoints with established reputation.
A per-call price ceiling. If an endpoint quotes a price above $Y, the agent refuses to pay. Endpoints have been observed quoting a normal price 99% of the time and a $40 price 1% of the time (probably honest bugs, possibly not). The ceiling catches both cases without you having to know which.
Logged payment receipts. Every payment receipt is stored locally with the corresponding request and response. If something goes wrong, we want an audit trail. The receipts are roughly 1KB each and we’ve never regretted keeping them.
A circuit breaker on per-day spend. Across all counterparties. If the agent has spent more than $Z today, it stops calling external services and notifies its operator. We’ve never had to trip it. It exists for the day the agent gets prompt-injected into spending fast.
No automatic top-up. The agent’s wallet is funded manually on a schedule. The agent cannot pull money from the operator’s wallet. This is a hard rule. An agent that can refill itself is a security incident waiting to happen.
When x402 isn’t right
A short list of cases where x402 is the wrong tool.
Regulated industries with KYC requirements. x402 makes anonymous payments easy. If you’re in a context where “know your customer” is a legal requirement — healthcare, finance with US customers, anything regulated — x402 is structurally wrong. Use a metered API with a registered account.
Payments above $50. The gas/paymaster overhead becomes negligible, the latency tail becomes annoying, and the lack of dispute resolution becomes scary. Real money should go through a payment processor with chargebacks.
Cases where the counterparty cares about identity. x402 alone says nothing about who is paying. If the merchant needs to know that the buyer is a specific entity (for usage-based licensing, white-label arrangements, etc.), you need to layer an identity proof on top. ERC-8004 is the right one.
Cases where the latency budget is unforgiving. Sub-100ms response times don’t tolerate any chain settlement variance. Use a metered API.
What we’d build into x402 v2
If I had to give the protocol authors feedback, three things:
- Standardize optimistic execution. The asymmetric-risk pattern we and others use is good. Codify it.
- Standardize sessions. The batching workaround should be a first-class part of the protocol. A “session-x402” extension with a deposit-and-settle model would unblock a lot of higher-throughput use cases.
- First-class identity integration. ERC-8004’s identity registry should be a normative part of x402 v2. Every payment should optionally include the payer’s agent ID. The endpoint can decide whether to require it.
None of this changes that the protocol works today. It’s the most-deployed agent-payment infrastructure in the industry. If you’re building an agent that needs to spend money, x402 is the baseline. Build on it, with safety rails, and don’t pretend the dispute layer is solved when it isn’t.
