The x402 protocol explained: the request, the 402, the payment, the retry

The status code was reserved, not invented

RFC 9110, the current HTTP specification, defines 402 Payment Required and then steps back. Its own words are that the code is "reserved for future use". That sentence is the whole of the standard's guidance: no body schema, no payment method, no rule about who verifies anything.

x402 is the convention that fills that space. It lives in the specs/ directory of the Coinbase x402 repository, which also carries the PaymentPayload and PaymentRequirements objects, the facilitator role, and reference SDKs and middleware for TypeScript, Python and Go. According to x402.org, the protocol is blockchain-agnostic and supports EVM chains and Solana, and it charges no fee of its own: payers cover network fees only.

Four steps, then: the request, the 402, the payment, the retry. The objects have names, and the names matter if you are about to implement this.

Step 1: an ordinary request

The client asks for the resource with no payment attached. There is no handshake beforehand and no negotiation in a side channel. The server treats this as a normal request until it decides the resource costs money. Because the first request is unpaid by default, an agent that cannot yet pay can still discover the price. A login wall cannot do that.

Step 2: the server answers with PaymentRequirements

The 402 response body carries a PaymentRequirements object: the amount, the scheme, the network, the asset, and the address that gets paid. The repository names the exact scheme as the one that transfers a specific amount, and that is the scheme you will meet first. Read it as a machine-readable quote. The response is a bill in JSON, not a paywall page with a subscribe button. If the vocabulary around this is new to you, the glossary is the shortest way in.

Step 3: the client builds a PaymentPayload

The client constructs a PaymentPayload and puts it in the retry. On EVM chains the payload carries a signed authorisation built with EIP-3009's transferWithAuthorization, and the signature itself is typed structured data hashed and signed under EIP-712. This is the part people get wrong when they skim. The client signs an authorisation to move a specific amount, with a nonce and an expiry, to a named recipient. It does not sign a transaction, and it does not broadcast one.

Step 4: the retry, and the facilitator

The client repeats the original request with the payload attached. Settlement happens out of band. A facilitator verifies the signature and settles the transfer, and the resource is returned. Coinbase's seller-facing documentation states that the CDP facilitator verifies and settles payments on Base and Solana, and states that CDP has processed more than 100 million x402 payments.

What the client signs, and why it never broadcasts

A signed authorisation is a message. It is not a transaction. It costs nothing to produce, it can be produced by a client holding no gas, and until somebody submits it nothing has happened on chain. The nonce handling that makes replay impossible is defined by EIP-3009, which is why the same signature cannot be spent twice.

The practical consequence is that the party who pays is not necessarily the party who submits. An agent can sign, hand the payload to a facilitator, and let the facilitator do the on-chain work. Whether that facilitator charges, sponsors gas or batches submissions is a commercial decision, and the protocol does not make it for them.

What the spec leaves to the facilitator

Quite a lot. The repository defines the facilitator role and stops there: verification and settlement are its job. The Coinbase seller documentation says the CDP facilitator verifies and settles, but does not state who pays gas on submission or what a facilitator charges. Those are open questions rather than documented answers, which is why nobody can tell you from the available data what a given facilitator costs you.

Beyond gas and fees, the protocol does not define dispute handling, refunds, retry policy, how long a signature stays valid in practice, or what happens when the facilitator is unreachable. If your service depends on any of those, you are writing the policy yourself. What is an x402 facilitator, and do you need one? works through that choice.

The volume is real, and smaller than the headlines

According to TRM Labs, the network recorded 198.9 million settlements worth $52.7 million across Base, Solana and Polygon since May 2025. Of that, $25.62 million screens as genuine commerce, and 0.6% to 7.5% of the screened figure looks plausibly agentic. 99.6% of value settled in USDC.

Chainalysis counts well over 100 million cumulative x402 transactions on Base through Q1 2026, and reports that payments of $1 or more rose from 49% of value in early 2025 to 95% by early 2026.

Against that, CoinDesk cites Artemis for around $28,000 of real daily x402 volume and an average payment of about $0.20, against roughly 131,000 daily transactions. BlockEden.xyz reports that daily x402 transactions fell from about 731,000 in December 2025 to about 57,000 in February 2026, a decline of over 92%.

Those figures describe different things and should not be added together. Settlement count is not commerce, transaction count is not revenue, and an average payment of twenty cents tells you the median is lower still. The methodology explains how the corpus handles that gap, and the published dataset lets you check the arithmetic yourself.

What to build against

Implement the four steps as the spec names them. Return PaymentRequirements on the 402. Expect PaymentPayload on the retry. Keep the client's signing path entirely separate from anything that costs gas, because the whole design depends on that separation holding. Test against the exact scheme first, since that is what the reference SDKs exercise.

Then size the opportunity honestly. The protocol works. The implementation surface is small. The demand, measured in dollars of real commerce rather than transactions, is still thin, and no amount of good engineering on your side changes that number.