x402¶

Its own endpoint, POST /{chain}/v1/x402, REST only: x402 v2 over HTTP, exact on EVM by EIP-3009. The 402 is the quote and the signed authorization the acceptance: there's no quote or submission step apart from them.

The relay is the facilitator, atomically. The authorization is spent by the runner, in the transaction that makes the call (runner), so it's spent only if the call succeeds and is included; nothing is settled apart from the call. The payment is still a balance difference: the transfer is how it arrives.

The challenge: an exact requirement in each token with eip3009, its amount the quote for the call in the body (its gas, its length, its authority), maxTimeoutSeconds the longest its request is held. Without a body, or with one that doesn't parse, it's a reference call's price (one authorization from an existing account, 150,000 gas, 512 bytes): discovery's probes reach the 402. The latest block is read at most once a slot for it, however many ask.

A paid request is held until it settles. x402's 200 means settled, with the transaction's hash, and its HTTP transport has no answer for "taken, not yet settled": 202 isn't in it. A submission's transaction is signed afresh each block until one lands, so there's no hash before it's included. The request is answered 200 once it is, or 402 once the submission is rejected or expires. Waiting reads nothing: it ends with the settlement the relay runs each block anyway. The hold is bounded by x402_deadline_blocks (10 by default, two minutes on Ethereum), which maxTimeoutSeconds tells clients: their HTTP timeout must be at least that. Meanwhile its status URL (Location) shows its stage. A connection lost (a deploy restarting the relay) leaves the status URL, or the same payment sent again.

A paid submission is an ordinary one from there: queued, ranked, evicted, simulated each block. Its deadline is the last block expected before validBefore, at most x402_deadline_blocks ahead; its id has the authorization in place of the deadline, so the same payment sent again is the same submission, held with it, or answered as it stands: its transaction once it has landed, a 402 once it's been rejected or has expired. One paid call at a time per payer: a payment for the same call (token, call, gas, authorizations) by the same payer while one is pending, as from a client that timed out and signed again, is held for that one, and its authorization never used: the client pays once. Refusals are 402s with x402's codes: an amount under today's charge, or under what would get into a full queue, comes with a fresh PAYMENT-REQUIRED at what's needed.

Conformance, checked against x402's normative text at commit 0e6e8c5 (the v2 core, its HTTP transport, exact, exact on EVM, and bazaar), and judged by its own SDK in the tests:

• The flow is authorization's guarantee, in one transaction. Verification (a simulation of the whole transaction), the resource (the call) and settlement (the transfer) can't be ordered apart: the transfer is made in the call's own transaction, and is spent only if the call succeeds. Funds move only if the resource completes, which is what authorization promises, so no paymentFlow is advertised; any other offered flow or transfer method is refused.
• Settlement is the runner's call to transferWithAuthorization, not a facilitator account's: EIP-3009 takes it from any caller, and the facilitator can't change the amount or destination either way.
• Exact: the authorization's value must be the amount accepted, and that amount must cover today's charge. Above the quote is a tip: a client accepts more than it was asked, signs for exactly that, and is ranked by it in a full queue.
• Verification is the simulation (the EVM binding's step 5). The signature and balance checks (steps 1 and 2) are read only once it fails, to name why: a key's signature recovered, a contract payer's put to its own ERC-1271 isValidSignature; a payment that succeeds reads nothing more.
• Contract payers, as x402's reference facilitator takes them. The exact EVM binding's text calls the signature "the 65-byte signature" and has it recover to from; x402's own facilitator (python/x402/mechanisms/evm/exact) takes ECDSA, ERC-1271 and ERC-6492 alike, a 65-byte signature through the (v, r, s) overload and any other through the bytes one. Bruno does as the reference does: smart accounts (Coinbase's, AgentKit's) pay, deployed or not. A contract's signature check is its own code, of any cost, so its transaction is estimated as it will run (gas): a payment short of that is answered 402 at what it needs. Under exact, x402's clients pay once at the 402's price, so a body that declares payer and deployment is priced for them from the first 402.
• ERC-6492, as written. A wrapped signature's factory is called first if the wallet has no code. If the wallet has code and the transfer fails without the factory call, the relay estimates again with it (the standard's prepare case), and the runner makes it. The standard doesn't say what happens when the factory call fails; its reference implementation reverts, and so does the runner.
• settlement_pending is never returned: the request is held until the transaction is included, or the submission fails.
• As a facilitator-submitted method: the fee is sponsored by the relay and recovered from the amount; the replay primitive is EIP-3009's nonce, exclusive to the payment; the window is bounded by validBefore and x402_deadline_blocks; a resubmitted payload is the same submission, deduplicated in the one process (or Durable Object) serving the chain, and answered with the same transaction. A payment delivers at most once: the call runs only in the transaction that uses the authorization.

The authorization doesn't bind the call. x402 gives no field that could: anyone who sees it (the relay, the builders) could attach it to another call, or settle it directly to the payee. That exposure is x402's; the relay tracks no nonces beyond the simulation, which refuses a used one.

Discovery: the 402 carries the bazaar extension (the body's schema and an example) and the resource's description; /.well-known/x402 lists each chain's endpoint; OpenAPI describes it with x-payment-info. The catalogs list only Base (and Solana) today: CDP's from settlements through its own facilitator, x402scan by probing.