Four Ways a Shared Facilitator Can Fail

The x402 facilitator's boundary failures become easier to judge when they are named by consequence rather than by implementation detail. This chapter distinguishes Free Shopping, Asset Theft, Service Denial, and Gas Abuse, then examines what the USENIX black-box study and ecosystem measurements establish about their prevalence and reach. The reader's task is not to memorize a vulnerability list, but to separate unpaid service from misdirected value, availability loss from sponsor loss, and confirmed exploitation from evidence that a deployment is high risk.

Four consequences, one shared boundary

The four attack classes begin with different violated invariants, even when their paths overlap. A facilitator may accept a proof that should be rejected, report a commitment that did not occur, or sponsor an action that is broader or more expensive than the intended payment. The resulting harm depends on which participant receives an incorrect state and what they do next.

flowchart LR A["Broken authorization or execution invariant"] --> B["Free Shopping"] A --> C["Asset Theft"] A --> D["Service Denial"] A --> E["Gas Abuse"] B --> B1["Merchant releases resource unpaid"] C --> C1["Facilitator-held value or accounts exposed"] D --> D1["Payment or resource service loses availability"] E --> E1["Sponsor pays attacker-chosen work"] B1 --> H["High-risk evidence or confirmed bounded validation"] C1 --> H D1 --> H E1 --> H

Free Shopping: access before payment

Free Shopping is the clearest case of a payment boundary failing to protect the resource server. An attacker obtains the protected resource without a verifiably successful settlement. The name does not imply that a facilitator must be deliberately complicit. It can arise when a facilitator returns a false settlement success, when a proof passes verification but fails during settlement, or when the server releases the resource after verification and never compensates for a later failure.

The USENIX paper describes a concurrency path in which a stateless verification endpoint does not reserve a payment nonce and settlement is not atomically tied to one verification result. Repeated requests can therefore pass verification before the nonce is consumed. Even if only one payment eventually settles, a merchant that treats each verification as permission may execute its business logic and return the protected result multiple times. A short validity window creates a different version of the same outcome: a proof can be accepted while fresh and expire before the facilitator submits it.

Free Shopping is therefore partly a facilitator problem and partly a server acceptance problem. A facilitator that reports success for a reverted or unconfirmed transaction breaks the payment claim even if the server waits for settlement. A server that releases after verification creates the same impact even when the facilitator truthfully reports a later failure. The paper reported two end-to-end validated cases and ten additional high-risk cases among the evaluated deployments. The distinction matters: the authors avoided obtaining unpaid resources from third-party merchants, so some cases were established through controlled integrations and attack-path evidence rather than harmful live exploitation.

Asset Theft: when proof data becomes execution authority

Asset Theft has a different primary victim and a different root mechanism. Instead of receiving a resource without paying, an attacker steers sponsored settlement toward an unintended value movement or causes the facilitator to fund attacker-controlled accounts. The central failure is ambiguous execution semantics: the facilitator accepts client-controlled data that should have described a payment but can instead shape what the settlement transaction does.

The paper's representative case involved ERC-6492-related counterfactual signature handling.