💻 computer science

Free-Riding in the AI Economy: Demystifying Logic Flaws in x402-Enabled Payment Systems

This paper presents the first comprehensive security analysis of the x402 protocol, revealing critical vulnerabilities such as signature design gaps and race conditions that enable free-riding and resource leakage in AI-driven payment systems, and proposes architectural mitigations to secure machine-to-machine transactions.

Original authors: Shengchen Ling, Yihang Huang, Yuan Chen, Yajin Zhou, Lei Wu, Cong Wang

Published 2026-06-01

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Shengchen Ling, Yihang Huang, Yuan Chen, Yajin Zhou, Lei Wu, Cong Wang

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a bustling digital marketplace where robots (AI agents) are buying and selling services from each other at lightning speed. They don't have cashiers or human managers; they just talk to each other and swap digital coins instantly. To make this work, a new system called x402 was invented. It's like a universal "Pay to Enter" sign that robots can read and obey automatically.

However, this paper is a security report that says: "The locks on this marketplace are broken."

The researchers found that because the system tries to be too fast and too flexible, it has created a "gap" between when a robot says it will pay and when the money actually arrives. This gap allows bad actors to trick the system into doing work for free.

Here is a breakdown of the four main ways this "Free-Riding" happens, using simple analogies:

1. The "Wrong Ticket" Problem (Cross-Resource Substitution)

The Analogy: Imagine you buy a ticket for a movie called The Matrix. The ticket says, "One entry, $10." But the theater's security guard only checks the price ($10) and not the movie title.
The Flaw: A hacker buys a ticket for the cheap movie (The Matrix) but walks up to the VIP lounge entrance for the expensive movie (Dune). The guard sees the $10 ticket, nods, and lets them in.
The Reality: In the x402 system, the digital "signature" a robot uses to pay doesn't strictly say which specific service it is paying for, only how much and to whom. A hacker can take a valid payment proof for a cheap API call and use it to unlock a premium, expensive AI service. The system accepts the money but delivers the wrong (and more valuable) product.

2. The "Double-Booking" Problem (Probabilistic Service Duplication)

The Analogy: Imagine a hotel with a very slow front desk. You walk up and say, "I have a reservation." The clerk checks the computer, sees your name is clear, and says, "Great, go to your room!"
While the clerk is still typing the check-in into the main ledger, you run back to the front desk with a friend and say, "I have a reservation too!" Because the clerk hasn't finished typing the first one yet, the computer still looks "clear" for the second person. Both of you get a room key, but the hotel only charged you once.
The Flaw: The x402 system checks if a payment is valid (the "check"), but it doesn't immediately lock the transaction so no one else can use it (the "lock"). A hacker can send the same payment request 20 times in a split second. The server, moving fast, says "Yes" to all 20 requests before the blockchain (the main ledger) has time to say, "Wait, that payment was already used!" The merchant delivers 20 services but only gets paid for one.

3. The "Blank Check" Problem (Allowance Overdrafts)

The Analogy: Imagine you give a waiter a credit card with a $100 limit and say, "Order whatever you want, just don't go over $100." The waiter starts ordering expensive steaks.
The problem is that the waiter orders 10 steaks before the bank has time to check if you actually have the money. By the time the bank tries to charge the card, you've already spent $500. The bank rejects the charge, but the waiter has already served the food. You get the food for free; the restaurant eats the cost.
The Flaw: In the AI world, the cost of a task isn't known until it's finished. Hackers set up a "spending limit" (allowance) that is just enough to pass a quick check. They then trigger massive, expensive AI tasks. The system starts the work immediately (because the check passed), but by the time the final bill is calculated, the hacker has spent more than their limit. The blockchain rejects the payment, but the AI has already done the work.

4. The "Traffic Jam" Problem (Denial of Settlement)

The Analogy: Imagine a toll booth that can only process 10 cars per minute. A hacker sends 50 cars through the gate at once. The gate opens for all 50 because the "entry" check is fast. But when the cars try to pay at the booth at the end, the booth is overwhelmed and can only process 10. The other 40 cars drive away without paying.
The Flaw: The system has a limit on how many payments it can process per second. Hackers flood the system with requests. The server delivers the service to all of them because the "entry" is fast, but the "payment" side gets clogged. The server ends up delivering free services because it can't process the payments fast enough to say "No."

The Big Picture: Why This Matters

The paper argues that the x402 system is trying to do two things that don't mix well:

Web Speed: Instant, "trust me" interactions (like HTTP requests).
Blockchain Safety: Slow, "verify everything first" safety (like blockchain finality).

By trying to bridge these two, the system created a "time gap." In that gap, bad actors can slip through.

The Proposed Fixes

The authors suggest a few ways to fix this, essentially telling the system to be more careful:

Tie the ticket to the specific seat: Make sure the digital signature says exactly which service is being bought, not just the price.
Put a "Do Not Disturb" sign on the ledger: When a payment is being checked, lock it immediately so no one else can use it until it's confirmed.
Don't serve the food until the check clears: For AI tasks, don't stream the results to the user until the payment is actually confirmed. If the payment fails, the user gets nothing.
Check the toll booth capacity: If the payment system is too busy to process a bill, don't let the car in at all.

In short: The paper reveals that the "economic rails" for AI agents are currently full of holes where people can steal services. To fix it, we need to stop being so optimistic about payments and start locking things down securely, even if it makes things slightly slower.

Technical Summary: Free-Riding in the AI Economy

1. Problem Statement

The emergence of the agent-to-agent (A2A) economy necessitates programmatic financial rails capable of handling high-frequency, autonomous transactions. The x402 protocol has emerged as the de facto standard for machine-to-machine payments, utilizing the HTTP 402 "Payment Required" status code to embed cryptographic payment instructions directly into application-layer requests.

However, the operationalization of x402 introduces a fundamental architectural dissonance: it attempts to bridge synchronous, ephemeral HTTP request-response cycles with asynchronous, probabilistic blockchain finality. This paper argues that current implementations of the x402 ecosystem fail to enforce critical security invariants due to this state synchronization gap. Specifically, the decoupling of verification (off-chain) and settlement (on-chain) creates race conditions and semantic ambiguities that allow attackers to "free-ride," forcing merchants to subsidize compute costs and exposing the system to systemic economic exploitation.

2. Methodology

The authors employ a rigorous security analysis framework combining formal modeling and empirical validation:

Formal System Modeling: The payment workflow is modeled as a state transition system involving four entities: Shopper ( $S$ ), Merchant ( $M$ ), Facilitator ( $F$ ), and Blockchain ( $B$ ).
Security Invariants: The authors define five fundamental Security Invariants that a secure implementation must uphold:
1. Payment Integrity (I1): Delivery implies confirmed on-chain settlement.
2. Value Consistency (I2): Transaction value must satisfy the resource pricing logic.
3. Context Binding (I3): Payment authorization must be cryptographically bound to the specific resource identifier.
4. Authorization Uniqueness (I4): A payment nonce must be consumed exactly once.
5. Execution Conservation (I5): Significant computational work must not be initiated unless payment is secured.
Vulnerability Analysis: The authors analyze the protocol specification and audit official SDKs (TypeScript, Python, Java, Go) and live middleware deployments (Thirdweb, Coinbase).
Empirical Validation: Controlled experiments were conducted on multiple testnets (Base Sepolia, Solana Devnet, Arbitrum Sepolia) and against official deployments to quantify the success rates of identified attacks.

3. Key Findings and Vulnerabilities

The analysis reveals that current implementations systematically violate the defined invariants, leading to three primary classes of vulnerabilities:

A. Cross-Resource Substitution (Violating I3)

Mechanism: The x402 protocol design relies on EIP-712 signatures that bind funds to a merchant address but are context-agnostic regarding the specific resource identifier ( $ID_r$ ).
Flaw: Official SDKs fail to cryptographically bind the signature to the HTTP request context (URI, method, body).
Exploit: An attacker can generate a valid payment signature for a low-value or unrestricted resource ( $r_A$ ) and substitute it to access a different, high-value, or restricted resource ( $r_B$ ) with the same price.
Result: In experiments, this led to a 100% success rate in resource swapping. In concurrent scenarios, it enabled "service duplication" where a single payment unlocked multiple resources.

B. Probabilistic Service Duplication (Violating I4)

Mechanism: A Time-of-Check to Time-of-Use (TOCTOU) race condition exists between the off-chain verification of a nonce and its on-chain settlement.
Flaw: The Facilitator's verification logic is stateless and read-only; it does not lock the nonce.
Exploit: An attacker broadcasts $N$ concurrent requests with the same signed payload. Multiple server threads verify the nonce as "unused" simultaneously before the first thread successfully updates the blockchain state.
Result: The merchant delivers the service $N$ times, but only one transaction settles on-chain. Experiments on the Base Sepolia testnet demonstrated a 6% success rate for service duplication, posing a scalable arbitrage risk for high-frequency AI agents.

C. AI-Specific State Drifts (Violating I2 and I5)

In the AI inference domain, the shift to dynamic pricing (using "upto" authorization schemes) exacerbates vulnerabilities:

Allowance Overdraft: Because the cost of LLM inference is unknown until completion, merchants must verify a spending cap ( $V_{max}$ $V_{ma x}$ ) rather than an exact amount. Attackers exploit the lack of atomic locking on the allowance. By launching $N$ $N$ concurrent requests where $\sum v_i \gg V_{max}$ $\sum v_{i} ≫ V_{ma x}$ , the attacker consumes resources for all requests. The blockchain reverts the excess transactions, but the merchant has already delivered the compute output.
- Impact: Experiments showed a leakage ratio ( $\rho$ ) of up to 97.76%, meaning attackers received nearly 100% of the compute resources while paying only a fraction of the cost.
Denial of Settlement: Attackers can flood the system with valid requests exceeding the Facilitator's settlement rate limits (e.g., 10 tx/s). The verification layer accepts the burst, and the merchant delivers the service, but the settlement API rejects the excess transactions.
- Impact: In extreme cases, this resulted in a 100% leakage ratio, where the merchant provided full service for zero payment.

4. Proposed Mitigations

The paper proposes four hierarchical defense strategies to restore security invariants:

Cryptographic Context Binding: Extend EIP-712 schemas to include a hash of the full HTTP request (Method, URI, Body) in the signature. This eliminates the semantic gap, making signatures invalid if replayed against different resources.
Stateful Nonce Linearization: Implement a "Check-and-Set" model at the Facilitator level using distributed locks (e.g., SETNX). This ensures that even if multiple threads verify a nonce, only the first to acquire the lock proceeds to settlement, eliminating race conditions.
Pessimistic Resource Delivery:
- Deferred Delivery: Buffer AI inference output until settlement is confirmed. This neutralizes the economic incentive for theft (the attacker gets no data if payment fails).
- Two-Phase Locking: For high-stakes scenarios, transfer the maximum cap to an escrow contract before execution to atomize the allowance check.
- Cryptoeconomic Anti-Griefing: Require agents to stake a "gas bond" to cover potential settlement reverts, slashing the stake if the agent attempts to grief the merchant.
Failure-Closed Design: Synchronize rate limiting and billing checks with the request ingress. If settlement capacity is exceeded, the request should be rejected immediately (429) rather than processed and delivered for free.

5. Significance and Claims

The paper claims to be the first comprehensive security analysis of the x402 ecosystem. Its significance lies in:

Identifying Systemic Risk: It demonstrates that the architectural dissonance between web protocols and blockchains is not merely an implementation bug but a structural flaw that undermines the economic trust model of the agentic web.
Formalizing Security Invariants: It establishes a formal framework (the five invariants) necessary for securing hybrid agentic systems, providing a baseline for future protocol design.
Exposing the "Free-Riding" Threat: It quantifies how current dynamic pricing models in AI can be weaponized to force merchants to subsidize compute costs at scale, threatening the viability of the AI economy.
Responsible Disclosure: All identified issues have been disclosed to Coinbase and Thirdweb, highlighting the immediate need for architectural shifts from "ergonomic looseness" to "rigorous cryptographic binding."

The authors conclude that without adopting state-aware middleware and pessimistic locking mechanisms, the AI economy risks building its financial foundation on rails prone to systemic free-riding.