Blog · arXiv Analysis · Last reviewed June 25, 2026

The Paid Request Becomes the Settlement Gap

The arXiv paper Free-Riding the Agentic Web: A Systematic Security Analysis of x402 Payments, submitted May 29, 2026 and last revised June 22, 2026, by Shengchen Ling, Yihang Huang, Yuefeng Du, Yuan Chen, Yajin Zhou, Lei Wu, and Cong Wang, studies a practical question for the agentic web: when a machine-readable HTTP request says payment is required, what proves that the right resource was paid for, settled, and delivered only once?

The settlement gap is the governance space between a payment-looking artifact and a defensible fulfillment decision: the resource, price, authorization, settlement state, retry history, delivery event, and agent mandate must all refer to the same transaction.

The Web Payment Shortcut

x402 is attractive because it makes payment look like part of ordinary web plumbing. The official x402 HTTP 402 documentation describes a resource server that can answer with 402 Payment Required and send a machine-readable payment requirement. In version 2, the docs describe three headers: PAYMENT-REQUIRED from server to client, PAYMENT-SIGNATURE from client to server, and PAYMENT-RESPONSE back from the server after settlement is attempted.

That is exactly why this paper matters. A paid resource request is not one event. It is a sequence: declare the resource and price, accept a client authorization, verify it, perform the work, settle the payment, and return the resource or an error. The sequence must remain coherent even though HTTP is fast and blockchain confirmation can be asynchronous. The security problem is not only whether money can move. It is whether payment evidence, resource identity, allowance, settlement state, and delivery state remain bound together.

The shortcut is also institutional. A server can treat payment as a middleware decision, an agent can treat payment as a retry path, and a facilitator can treat payment as a verification and settlement service. But a user, merchant, auditor, or incident responder needs the whole chain. Otherwise the paid request becomes a thin technical success hiding a disputed commercial fact.

Current Context

As of the June 25, 2026 review for this page, x402 sat inside a broader agent-commerce push rather than a standalone micropayment curiosity. Cloudflare's September 2025 launch post said it was partnering with Coinbase on an x402 Foundation, supporting x402 in Agents SDK and MCP integrations, and proposing a deferred-payment scheme for agent and crawler use cases. The x402 repository describes schemes including exact, upto, and batch-settlement, and its technical goals include trading off response speed against payment guarantees.

The current documentation has also moved toward the risks the paper names. The client/server docs now warn about Solana duplicate settlement when servers settle directly, and say standard SVM facilitator packages include a short-lived SettlementCache. The Payment-Identifier extension describes idempotency for retries by using a logical payment ID and response cache. The Signed Offers & Receipts extension describes signing offers on 402 responses and receipts on 200 responses so clients can preserve proof-of-interaction for auditing or dispute resolution.

Those features do not make every deployment safe. They show the shape of the answer: paid agent requests need explicit idempotency, signed terms, delivery evidence, spend authority, and failure records. Without those, the protocol can clear one layer while leaving another layer unable to prove what happened.

What the Paper Tests

The arXiv record lists Free-Riding the Agentic Web as arXiv:2605.30998 in Cryptography and Security, submitted May 29, 2026 and last revised June 22, 2026. The abstract says the authors organize their security analysis around five invariants derived from specifications, literature, and vendor expectations, then resolve violations to the responsible layer of the stack: HTTP semantics, chain-specific payment schemes, SDK choices, or deployment practice.

This framing is useful because x402 is not a single monolith. It is a protocol idea, a set of headers, payment schemes, facilitators, SDKs, and application decisions. The official facilitator documentation says a facilitator can verify payment payloads, settle payments onchain for servers, and return verification or settlement results. It also says servers can verify locally or send payloads to a facilitator, then decide whether to fulfill the request. The paper asks what breaks when those responsibilities are present but not tightly coupled.

The paper's scope should be kept precise. It is a security analysis of x402 payment flows and tested implementations, not a consumer-protection survey, a stablecoin policy paper, or a claim that every paid API should avoid x402. Its value is that it treats the paid request as a state machine with cross-layer obligations rather than as a single "payment accepted" moment.

Four Ways to Ride for Free

The paper's abstract identifies four flaw classes: cross-resource substitution, duplicate-settlement race, allowance overdraft, and denial of settlement. Those names are enough to show the governance shape of the problem. A payment proof that is valid for one resource may not be valid for another. A settlement response can be replayed or raced against confirmation. An allowance can be consumed in ways the server or client did not intend. A request can appear paid or authorized while the settlement path fails elsewhere.

The x402 docs now describe a concrete duplicate-settlement issue on Solana: if the same payment transaction is submitted to a facilitator's /settle endpoint multiple times before the first submission is confirmed onchain, duplicate successful-looking responses can let a malicious client access multiple resources while paying once. The documentation also describes a short-lived SettlementCache mitigation for the standard SVM facilitator packages. That is a useful sign: the issue is not merely theoretical protocol anxiety; it has operational shape in implementation guidance.

The paper also reports resource-leakage ratios up to 100 percent against official SDKs and a production deployment, and it discusses mitigations and a defense triple. Those numerical results should be read as research findings in the authors' tested settings, not as a universal claim about every x402 service. The broader lesson is simpler: paid agent requests need invariants that survive concurrency, retries, chain delays, SDK defaults, and deployment shortcuts.

The Invariants

For governance, the paper's invariant framing translates into five practical tests.

First, resource binding. A payment artifact should be bound to the exact endpoint, method, resource identifier, price, scheme, network, destination, and expiration that the server offered. If one valid-looking payload can unlock another resource, the receipt is too weak.

Second, settlement uniqueness. A logical request should settle once and fulfill once. Retries need idempotency keys, settlement caches, or equivalent replay controls so network delay does not become a free-resource channel.

Third, allowance discipline. A client or agent may have a spend ceiling, token allowance, or upto authorization. The server and facilitator need evidence that the actual charge stayed inside that authorization and did not create a hidden overdraft path.

Fourth, failure integrity. A failed settlement, disputed confirmation, chain error, facilitator timeout, or denial-of-settlement case must not be collapsed into success. The error path is part of the security protocol because it decides whether the resource is released or withheld.

Fifth, delivery evidence. Payment and delivery should be linked. A client may need proof that the server committed to terms and delivered the resource; a server may need proof that it only fulfilled after a valid authorization. Signed offers and receipts are one documented way to turn that relation into an inspectable artifact.

The Settlement Gap

The settlement gap is the space between "the client presented something that looks payable" and "the merchant or resource server has a settled, non-ambiguous reason to release this exact resource." In ordinary human checkout, that gap is hidden by payment processors, fraud systems, merchant policies, and post-purchase dispute channels. In agentic web payments, the gap can become visible because agents may generate many small paid requests, retry automatically, switch resources, or act without a user watching every response.

This is why the topic belongs beside The Payment Agent Becomes the Cashier and The Product Fact Becomes the Microtransaction Market. Agent payments are not only a convenience layer. They are a new class of authorization records. If the record only says "payment signature accepted," it may be too thin. A reviewer needs to know which resource, which price, which chain or scheme, which verifier, which settlement attempt, which fulfillment event, and which response header were bound to the same request.

Receipt Discipline

The governance standard is a paid-request receipt. For every x402-style agent payment, the system should preserve the resource identifier, payment requirements, client authorization payload, verifier result, settlement attempt, confirmation or failure result, delivery decision, retry count, and cache or idempotency key. It should also record the agent principal: who delegated authority, what spend limit applied, and what policy allowed the request.

That receipt does not require treating the agent as a legal person. It treats the agent as an operator of delegated authority inside agentic commerce. The audit trail should make clear whether a failure belongs to the user's mandate, the agent's decision, the merchant's resource mapping, the facilitator, the chain-specific scheme, or the application code. Without that separation, a "paid" response can become an argument rather than evidence.

The practical rule is conservative: do not release scarce, expensive, regulated, or privacy-sensitive resources on a payment artifact unless the artifact is bound to the exact resource and the settlement state is unambiguous enough for the risk. Low-value content may tolerate weaker finality. Credentialed data, cloud actions, procurement, financial services, or API calls that trigger downstream obligations need stronger gates and clearer AI audit trails.

Governance Standard

First, bind the offer. The 402 response should commit to the resource, method, amount, currency or token, network, destination, expiration, terms, and accepted scheme. If the server later serves a different resource or changes the price, the receipt should show that change.

Second, separate verification from fulfillment. A valid payment payload is not the same thing as settled value or safe delivery. The application should define which resources can be fulfilled after verification, which require confirmed settlement, and which require human or policy review.

Third, make retries idempotent. Agents and HTTP clients will retry. The logical request needs a stable payment identifier or equivalent cache key so a retry does not become a second fulfillment or a second charge.

Fourth, preserve the agent mandate. A paid request should say which principal authorized the agent, which wallet or account was used, what budget and resource limits applied, and whether the user confirmed the spend or allowed automatic payment.

Fifth, log failures as evidence. Denied settlement, paid-but-denied delivery, duplicate settlement attempts, facilitator errors, chain timeouts, and resource mismatches should produce incident-ready records, not only generic HTTP errors.

Sixth, minimize payment metadata. Paid agent requests can expose resource URLs, task descriptions, wallet identifiers, and reason strings. Receipts should preserve accountability while avoiding unnecessary personal, commercial, or sensitive prompt data.

Seventh, define recourse before scale. Low-value machine payments still need refund, dispute, support, and abuse paths. A micropayment stream can become material through volume, retry loops, or automated misuse.

Limits

This page does not claim that x402 is unusable or that every implementation is vulnerable. The paper is a security analysis of particular invariants, flaw classes, SDKs, and deployments, and the official documentation already includes mitigation language for at least one duplicate-settlement pattern. The right conclusion is not panic. It is discipline.

It also does not claim that stronger receipts solve all commerce problems. A receipt can prove that a resource was requested, paid for, and delivered under particular terms. It cannot prove that the agent should have bought the resource, that the price was fair, that the seller was trustworthy, or that downstream consumer, procurement, tax, sanctions, privacy, and refund duties were satisfied.

A protocol for machine-readable payment should be judged by whether it can keep the commercial story intact under automated speed: request, authority, resource, settlement, fulfillment, and evidence. The agentic web does not need mystical payment language. It needs boring receipts that survive retries.

Source Discipline

Current claims were checked for this June 25, 2026 review against arXiv, x402 documentation, the x402 repository, Cloudflare's x402 launch post, and RFC 9110. The paper is treated as a June 2026 security preprint and implementation analysis, not as a regulator finding or a proof that every deployment has the same leakage ratio.

x402 documentation is treated as evidence of the current documented flow, extension surface, and recommended mitigations, not proof that every server, facilitator, SDK, or merchant uses those controls correctly. Cloudflare's announcement is evidence of product support, foundation framing, and deferred-payment proposals; it does not prove safe adoption or interoperable governance across the whole web.

For payment systems, source roles matter. A standards RFC can say what HTTP defines. A protocol repository can say what a project intends. A facilitator doc can describe a service role. A security paper can identify attack classes. A production receipt, incident report, audit, dispute record, or exploit reproduction remains stronger evidence for a specific deployment.

Sources

Return to Blog