The Gap Between Checking and Paying

The x402 facilitator's most consequential failure can occur after it has made a correct decision. A proof may match the server's requirements and pass verification, yet become unusable or unsafe before settlement. This chapter follows that proof through time and state, then adds the resource server's own side effects to the picture. The practical judgment is whether a deployment binds verification to the eventual commitment closely enough that a request cannot receive value merely because an earlier check looked good.

A verified proof is still waiting for a state transition

In the default authorization flow, /verify observes payment state before the resource runs, while /settle commits payment afterward. That separation gives the server a chance to reject bad requests before doing work, but it also creates a window in which the conditions can change. The proof is not a frozen fact simply because the facilitator returned a positive response.

Consider a nonce-bound authorization sent twice at nearly the same time. Both verification calls may inspect the same unused nonce before either settlement consumes it. If the facilitator does not reserve the nonce or bind the verification result to one request, both calls can appear eligible. At most one transfer may ultimately consume the nonce, but two server requests may already have crossed the verification boundary and started business logic. The payment system and the resource system then disagree about how many times the client paid.

Time windows create a similar mismatch without concurrency. An authorization can be valid when the server asks for verification but expire while the server prepares its response, runs business logic, and waits for the facilitator to construct, broadcast, and confirm a transaction. A short remaining window is not just a client inconvenience. It is a condition that can make a proof reliably pass the first check and fail at the second. If the facilitator sponsors the doomed transaction, it may burn fees; if the server releases the resource after verification, it may deliver value without a completed payment.

Solana adds a network-specific version of the same transition. A recent blockhash can become stale between verification and submission, even though the transaction and signature were acceptable when examined. On either network, the payer's balance can change between the checks. A competing transaction can consume a nonce or reduce available funds. These events do not require a malicious facilitator. They arise because a read-only observation and a later state-changing operation are separated in time.

Simulation can introduce another difference between what was checked and what will execute. A contract wallet's signature logic may depend on state or execution context. An off-chain call can return a successful validation result under conditions that do not hold when the facilitator submits the real transaction. In that case, the failure is not simply “the network was slow.” The verification context was not equivalent to the settlement context, so the facilitator treated a conditional observation as if it were a durable authorization.