What is x402? The HTTP status code that waited 28 years for a job

When the web was young, its designers left a door open and never built the room behind it. HTTP 402 Payment Required has been reserved in the specification since the 1990s, a status code with a name, a number, and no agreed meaning. For most of three decades it sat unused: there was no standard way for a server to say "pay me" and no standard way for a client to answer. Browsers had cookies and logins and, eventually, checkout pages, but the protocol itself never learned to charge for a request. 402 was a placeholder waiting for a use case that hadn't arrived yet.

x402 is what finally gave that status code a job. It is a machine-payment protocol built directly on HTTP 402. The flow is deliberately small: a caller requests a paid endpoint, the server responds with 402 and a set of payment terms, the caller pays, and then retries the same request with proof of that payment attached. On the second try the server sees the proof and returns the actual content. No account to create, no invoice to reconcile, no human clicking approve. The request and the payment travel in the same protocol that already moves everything else on the web.

The mechanics underneath are worth naming, because "pay on-chain and re-send" glosses over the part that makes it fast. The payment terms arrive with the 402 as an accepts array. In x402 v2 they sit inside a base64 PAYMENT-REQUIRED header (v1 put them in the response body). Each entry is a concrete option: a scheme, a network, an amount, a recipient. The retry does not make a second, separate blockchain round trip. It carries the payment in a PAYMENT-SIGNATURE header (v1 called it X-PAYMENT), and for the common scheme that payload is an EIP-3009 transferWithAuthorization the payer signs off-chain, so settlement needs no gas from them and no prior token approval. A facilitator service verifies that authorization and submits it on-chain on the server's behalf, which is why an API provider can accept x402 without running a node or holding a wallet in the request path.

That is a strange thing to want until you picture who is doing the calling. The caller x402 was built for is usually not a person. It is an AI agent hitting an API on its own, dozens or thousands of times, faster than any manual approval flow could keep up with. Card rails assume a human on one side: a billing relationship set up in advance, a statement reviewed later, a chargeback available if something goes wrong. Agent-to-agent commerce has none of that patience. An agent needs to discover a price and settle it inside a single round trip, the same way it would follow a redirect. x402 makes payment a property of the request rather than a relationship negotiated around it.

This is no longer a thought experiment. As of 2026-08-12, agenteconomy.to reports roughly $41.28M in cumulative x402 settlement, with organic daily volume around $28K. The traffic is also volatile in a way worth noticing: transaction counts have swung from a peak near 3.8 million in a day down to 7,320 on 2026-08-12. Trackers also disagree on the total: the Visa and Artemis analysis cited below puts raw x402 activity at $135.7M as of 2026-04-21, more than three times the agenteconomy.to cumulative figure, and the two count different transactions over different periods, so a headline total says as much about what a tracker includes as about the market. So the protocol is real and in use, but the shape of that use is still forming, which is exactly the moment to be precise about what x402 does and does not carry.

Here is the part that gets glossed over. x402 gives a server proof of payment. It says nothing about proof of delivery, and it says nothing about who the wallet on the other side actually is. A brand-new address with zero history looks identical, at the protocol level, to an address that has cleanly settled thousands of legitimate calls. For a human-run service that ambiguity is usually survivable, because reputation and chargebacks act as a backstop. Under x402's exact scheme, settlement removes that backstop: a settled payment is final and there is no chargeback to file. The auth-capture scheme adds refunds, but only when the seller supports it. And because the payment happens before the content is returned, the party who eats the loss when a deal goes wrong is the buyer, the agent that already paid. Speed and finality are the whole selling point, but they also mean the usual safety net has to come from somewhere else.

Two data points show why "the wallet paid" is a weaker signal than it sounds. As of 2026-04-21, the Visa and Artemis PDF reports raw x402 activity of $135.7M across 178.3M transactions, and the article reports wash-and-test-adjusted totals of $15.0M across 109.6M transactions. The gap between those two published totals is 38.5% of transactions and 88.9% of volume. Separately, on the identity side, a 2026 study (arXiv:2606.26028) of the ERC-8004 agent-identity standard found roughly 173,000 registered agents, of which 3%, 4% and 15% (on Ethereum, BNB Smart Chain and Base) exposed a valid registration file with at least one live service endpoint. On the feedback side, 98.7% of the feedback records on Ethereum carried neither a proof of payment nor a link to a task, a share of feedback records, not of agents. Registration is cheap; a track record is not. Being registered, and even having paid before, is not the same as being worth paying.

So, does x402 matter to you? If you run an API and want machines to be able to buy from it without a signup funnel, x402 is the mechanism that makes that possible today. If you are building an agent that needs to pay its own way through the tools it uses, x402 is how it will settle those bills. And if you are doing either of those things at machine speed, the gap above becomes your problem: you are auto-accepting or auto-sending final payments to counterparties you have never met, with no way to claw one back.

That gap is the reason vet402 exists. vet402 buys from x402 endpoints with its own funds, re-reads each settlement on-chain, checks whether the paid request answered with a non-empty 2xx, and publishes the results, settled or not, with their evidence on its observatory. The same records back a decision API: before an agent pays, GET /api/v1/resources/{resourceId}/decision returns the measured facts about that seller with an ALLOW, WARN or BLOCK recommendation and the reason codes behind it, and the @vet402/sdk spend guard applies it in the request path, passing only an ALLOW by default. It does not make x402 slower or add a human back into the loop. A recommendation is a signal, not a guarantee, but at machine speed, knowing what happened when someone last paid that endpoint is the difference between a default you can defend and a coin flip.

For the protocol in reference form, with the payment schemes and live numbers from vet402's purchases, see vet402.com/x402.