When a Valid Signature Is Not Enough
The x402 facilitator's hardest job is not recognizing a signature; it is preserving the meaning of a payment as it crosses interfaces. This chapter examines the binding between the resource server's requirements, the client's proof, and the transaction a facilitator sponsors. The result is a practical test for an x402 design: it must establish both authorization correctness—whether the right payer authorized the right payment—and execution safety—whether the facilitator can settle only that payment, at a bounded cost.
The proof must describe the payment the server requested
A payment payload can be authentic and still be wrong for a particular resource. The server may require 1,000 atomic units of a particular asset on a particular network, paid to a particular address within a particular time window. The client may return a correctly signed authorization for 900 units, a different token, another network, or another recipient. Cryptography can prove who signed those fields; it cannot by itself prove that the fields satisfy the server's request.
That is why the facilitator receives two descriptions at verification time. One is the client's payment payload, including the accepted requirements and the scheme-specific proof. The other is the resource server's paymentRequirements. The facilitator must compare the two rather than treating either as authoritative in isolation. Scheme, network, asset, recipient, amount, timeout, and any relevant extra data have to resolve to one payment. The signed fields must also carry the same meaning. For an exact EVM authorization, the to field must bind to the server's payTo, and the signed value must bind to the required amount. Similar relationships exist for the asset, network, validity window, and payer.
The comparison is easiest to see through a recipient substitution. Suppose a server says that payment goes to its own wallet, while the client presents a valid authorization whose recipient is an address controlled by someone else. If the facilitator checks only the signature, it can truthfully say that the client authorized the transfer and still authorize the wrong payment. The defect is not a failure of signature mathematics. It is a failure to preserve the server's intent across the interface.
The same problem appears when the amount is correct but the asset or network is not. A token address is meaningful only within the relevant network and contract model, and an amount in atomic units cannot be carried across assets by visual resemblance. A facilitator that normalizes fields too aggressively may make two different payments look interchangeable. A facilitator that compares only a client-selected object may fail to notice that the server advertised different terms. The safe decision is relational: the proof, the requirements, and the chosen network must agree before the payment is treated as authorized.
Time and replay fields belong to the same relationship. An authorization can be genuine and correctly addressed yet no longer usable because its validity window has expired or its nonce has already been consumed. The facilitator has to evaluate those fields under the intended signature and network model, not treat them as descriptive metadata. Otherwise it can approve a statement that was once valid but cannot be committed now, creating a gap between what the server believes it checked and what settlement can actually execute.
The binding is also why a server's requirements remain available at verification time. If the facilitator checked only the payload, it could establish that a client signed some authorization without establishing that the authorization satisfies this server's price, recipient, asset, network, and timeout. Conversely, if the server checked only its own fields and trusted the facilitator to fill in every relationship, it would be unable to tell whether the proof and the submitted transaction remained bound to its original request. The two descriptions are separate precisely so they can be compared.
The comparison is not a single yes-or-no operation in practice. The facilitator must parse the payload according to the selected scheme, determine which fields carry value, validate the payer's authorization, and ensure that the later settlement path will interpret the same fields in the same context. A design that checks only the outer JSON shape has not yet checked the payment. A design that verifies a signature but does not bind its recipient and amount has checked identity without checking intent.
One protocol, several proof semantics
The validation surface becomes larger because x402 does not use one universal payment representation. The USENIX study focuses on Base and Solana, the two dominant networks in its observation, and describes materially different proofs on each. The v2 specification also uses network identifiers and scheme-specific logic rather than pretending that one chain's account and signature model is universal.
On EVM-compatible networks, an exact payment commonly uses ERC-3009 transferWithAuthorization. The payer signs an authorization that names the source, destination, amount, validity window, and nonce; a facilitator can later submit the transfer on chain. An externally owned account generally uses an EIP-712 typed signature. A deployed contract wallet may instead define its own signature check through ERC-1271, and an undeployed or counterfactual wallet may use an ERC-6492 wrapper that includes information about how the wallet will be deployed or validated.
Those variants cannot be treated as cosmetic wrappers around the same check. An EOA signature can be validated with the intended typed-data rules. A contract wallet's validity is determined by the wallet's isValidSignature logic, which may depend on contract state or execution context. A counterfactual signature adds a deployment or factory path that can involve additional calls before the wallet exists on chain. If the facilitator simulates one context during verification and sponsors a different context during settlement, “the signature passed” no longer guarantees that the same authorization will survive execution.
This is a boundary between authentication and execution. With an ordinary signed message, the facilitator may imagine that its job ends when it recovers the expected payer. With a contract signature, verification can call code. With a counterfactual signature, settlement may also create or initialize code. The facilitator therefore has to decide not only whether the payer's authorization is acceptable, but which code paths, addresses, and state assumptions it is willing to sponsor. Supporting a more flexible wallet model expands what the facilitator can serve and expands what it must constrain.
Solana uses a different model. The payment payload carries a serialized transaction whose meaning depends on the message, account list, token mint, source and destination token accounts, owner, instructions, required signers, recent blockhash, and fee payer. A facilitator does not merely validate a signature over a destination address. It must ensure that the transaction invokes the permitted token program with the expected accounts and transfer semantics, and that the transaction remains fresh enough to settle. An unexpected instruction or extra signer can change both what the transaction does and what the facilitator pays to process it.
The account model makes the recipient relationship concrete. The server may name a wallet address, while the token transfer executes against a token account derived from that wallet and the asset. The facilitator has to check the derivation and the instruction's destination, not assume that any account supplied by the client represents the server. It also has to treat the fee payer and signer set as part of the execution context. A transaction can be signed by the expected client and still ask the facilitator to sponsor an account creation or instruction sequence outside the intended payment.
This is why the facilitator is a semantic boundary between networks, not a neutral adapter. The same high-level requirement—“pay the server this amount”—maps to different low-level conditions. On EVM, the effective recipient is tied to authorization fields and token-transfer behavior. On Solana, it is tied to the destination token account and the instruction set, including how the expected account is derived from the server's recipient. A rule that ignores those details can accept a proof that looks valid in one representation while authorizing a different action in another.
The correct abstraction is therefore an invariant, not a shared syntax. The server's intended recipient must be the recipient the proof authorizes and the transaction will pay. The intended asset and amount must survive parsing and execution. The payer must be authenticated under the signature model that actually governs the account. Time and replay constraints must be meaningful on the target network. The facilitator can hide wire-format differences from the server, but it cannot hide the obligations those differences create.
Authorization correctness versus execution safety
The USENIX paper organizes these obligations into two groups. Authorization correctness covers whether a request should be treated as paid: the proof must match the server's requirements, the payer's authorization must be authentic, freshness must be enforced, and a facilitator must not report success unless the corresponding payment condition is satisfied. Execution safety covers what the facilitator is allowed to do while trying to settle: it must reject non-settleable or economically meaningless payments, bound sponsor-paid cost, revalidate time and state before submission, and restrict on-chain behavior to explicit payment semantics.
The distinction matters because the two groups can fail independently. A facilitator might correctly recognize a payer's signature but accept an amount or recipient that does not match the server's request. It might correctly match the fields at verification but submit a transaction that contains unexpected instructions. It might identify a valid authorization that has too little remaining time to settle and still sponsor it. “Authentication succeeded” answers only one question in a chain of decisions.
Contract signatures make the distinction especially visible. With ERC-1271, the signature check is a call into contract-defined logic. With ERC-6492, validation can include counterfactual deployment information. If the facilitator treats client-provided deployment metadata as harmless data, it may fail to notice that settlement will execute additional logic. A safe implementation has to bind the validation context to the eventual transaction, allow only the expected contract or factory behavior, and reject semantics that exceed a simple, explicitly permitted payment. The point is not that contract wallets are inherently unsafe. The point is that supporting them turns proof validation into a controlled execution problem.
The paper's case study illustrates the consequence without requiring a general claim about every contract wallet. It describes a facilitator that trusted attacker-supplied counterfactual deployment metadata during settlement, allowing the settlement path to be repurposed as an arbitrary call funded and signed by the facilitator. That is an execution-semantics failure: the payment proof was allowed to carry more authority than the server's declared transfer required. The lesson is to constrain the settlement shape and its callable addresses, not to discard the distinction between ordinary and contract-based accounts.
Solana exposes a parallel issue through account and instruction structure. If the facilitator accepts an account list or instruction sequence that is broader than the intended transfer, a client-controlled payload may cause the sponsor to create accounts, invoke unexpected programs, or pay for extra signatures and computation. A transaction can still be signed by the expected payer and yet be unsafe for the facilitator to sponsor. The allowed transaction shape must therefore be part of the security decision, not an implementation detail delegated to the network.
Cost bounds belong in the same category because sponsorship changes the attack surface. Facilitators may pay gas, rent, or compute even when a token transfer is small, zero-valued, or destined to fail. A stale authorization, an insufficient balance, an expensive contract-signature check, an oversized account list, or an attacker-controlled fee parameter can consume sponsor resources before the intended payment is complete. Requiring a payment to be economically meaningful, limiting fee and compute parameters, enforcing idempotency, and rejecting proofs with too little remaining validity are all ways of limiting what a client can make the facilitator do.
A bound also needs an owner and an observable failure condition. A nominal maximum gas value is not useful if a facilitator ignores it when constructing the real transaction. A freshness threshold is not protective if it is applied at verification but not before submission. An idempotency rule is incomplete if concurrent requests can receive inconsistent outcomes. These are not additional categories beyond the paper's rules; they explain why the rules are operational conditions rather than labels on a checklist.
This is also why the paper distinguishes Gas Abuse from Service Denial. Gas Abuse is primarily an economic problem: the attacker turns a sponsor's budget into work chosen by the attacker. Service Denial emphasizes the resulting loss of availability or payment capacity. The same weak bound may contribute to both, but the owner of the loss and the control objective can differ. A facilitator that reimburses every failed transaction may experience direct financial loss; one that passes costs to servers may create liquidity pressure or make the service unusable. The security rule remains valuable even when the accounting model changes, but the impact assessment must state who pays.
A useful design test follows from the two groups. Ask first whether the facilitator can prove that the proof authorizes the server's declared payment. Then ask whether the facilitator can show that the settlement transaction is the only permitted value-moving action and that its fee, compute, and retry behavior are bounded. Passing the first test without passing the second creates a system that authenticates intent but may sponsor unsafe execution. Passing the second without the first can produce a well-bounded transaction that transfers the wrong asset or pays the wrong recipient.
Strict binding and allowlists do have a trade-off. They can narrow the range of wallets, networks, or schemes a facilitator supports, and they may require new validation work when a protocol adds a legitimate payment mechanism. That is a maintenance cost, not a reason to let arbitrary semantics through the boundary. The security question is whether the flexibility is explicit, testable, and priced into the sponsor's risk model. A facilitator that cannot state which proof formats it supports and which settlement shapes it will execute is asking the server to trust an interface whose real contract is unclear.
The next failure surface appears after both questions have been answered correctly at verification time. A proof may be properly bound to the server's intent and still become stale, underfunded, or contextually different before settlement. The next chapter follows that movement through time and asks when a correct check stops being a reliable commitment.