Fifty requests ran, four settled. x402 has appropriation rules and no monitor.

The rail your agent will pay market data with has now been audited, and it does not hold. On 29 May, revised 22 June, Ling, Huang, Du, Chen, Zhou, Wu and Wang published Free-Riding the Agentic Web: A Systematic Security Analysis of x402 Payments, since accepted to ACM SIGOPS ATC '26. Their framing of the subject matters as much as their findings: x402 has "crossed from prototype to infrastructure for the agentic web," 130 million all-time transactions, embedded in Google Cloud, Cloudflare and Stripe. This is not a research toy. It is the metering layer a lot of financial-services agents are about to buy their inputs through — research feeds, inference, verification calls, per-query market data.

The headline number is a leakage ratio. Against a live Thirdweb deployment on Arbitrum, a fifty-request burst against a 10,000-wei allowance had every request verify and execute — 47,277 tokens of service delivered — and four settle, for 1,057 wei. Forty-six reverted on overdraft. Leakage: 97.76%. In the streaming variant, a rate limit that blocks every settlement gets fifty requests served and zero settled: 11,101 wei of inference at no cost, leakage 100%.

The rules are fine

Start where the paper starts, because it is the unusual and correct move. Before testing anything the authors write down five invariants any x402 deployment must hold: resource delivery accompanied by a confirmed transaction to the intended merchant; transaction value covering the negotiated price; payment authorization cryptographically bound to the specific resource; each authorization nonce consumed exactly once regardless of concurrency; and server-side execution beginning only after payment is confirmed or locked.

Those are appropriation rules for a common-pool resource, stated with more precision than most fisheries ever managed. They are not vague, they are not contested, and no vendor disputes them. Every finding in the paper is a violation of one of them.

So the interesting question is not what is the rule. It is who checks.

Four ways to take the service and leave

Cross-resource substitution. The payment signature commits to a value and a payee but not to the resource. That makes it a floating authorization: buy A, spend the signature on an equal-priced B. In the lab a signature minted for one resource accessed an equal-priced sibling in all 100 rounds. In the wild, 38% of hosts — 331 of 868 — expose same-price sibling clusters for it to float across. The authors trace the same omission through four official SDKs by different routes: the TypeScript and Python implementations leave the resource identifier out of the matching predicate, Java validates against unsigned metadata, and Go hands the decision to a stateless facilitator that has no local resource context to check against. Four languages, four mechanisms, one missing binding.

Duplicate-settlement race. x402 separates verification from on-chain settlement, by design, because HTTP is synchronous and finality is not. That gap is exploitable: concurrent requests can all clear verification before any consumes the nonce. Fifty rounds of twenty concurrent requests produced duplicate delivery in 6% of rounds — two distinct HTTP 200 responses with different payloads against one confirmed settlement. This one has independent corroboration in the wild: an upstream issue reporting five concurrent requests where four received the same merchant settlement proof. The Flask adapter has a sharper version, where a 302 redirect — the ordinary way anyone serves from a CDN or object store — goes out without settling at all.

Allowance overdraft. Under the upto dynamic-pricing scheme the merchant reads an allowance snapshot but cannot lock against it, and there is no per-deduction nonce. Concurrency drains it, which is the Arbitrum result above. The serial version needs no concurrency at all: replay one authorization across many calls, and a $1.00 authorization priced at $0.01 per call yields up to 99 unauthorized ones. Exposure here is currently narrow — 39 declared resources, 0.79% of de-duplicated resources — which is worth saying plainly, because dynamic pricing is exactly what per-token agent services drift toward.

Denial of settlement. The purest form, and my favourite, because nothing is broken. The merchant verifies faster than it settles. Flood it at 50 req/s against a 10 tx/s settlement limit and all fifty stream while five settle: 14,761 wei delivered at 1,926 wei of cost, leakage 86.95%. There is no bug. There is a rate-limit asymmetry between two subsystems that were each configured sensibly on their own. The authors put a loose upper bound of 35% of de-duplicated resources — 1,748 of 4,933 — in the exposed class.

Ostrom's fourth principle

Run the list. Clearly defined boundaries: x402 has them. Congruence between rules and local conditions: arguably yes. Collective-choice arrangements: an open standard with SDKs and an issue tracker, so yes. Then the fourth principle, monitoring, and the fifth, graduated sanctions — and the protocol has neither, at any layer that anyone owns.

This is the specific failure mode Ostrom spent a career documenting, and it never looks like lawlessness. It looks like a well-drafted rulebook and nobody counting. Long-lived commons institutions are not the ones with the best rules; they are the ones where monitors are accountable to the appropriators and small violations get small, escalating consequences. Systems that skip monitoring on the theory that the rule is obvious are the ones that collapse, and they collapse quietly — not through defection by bad actors but through ordinary appropriators discovering, one at a time, that nothing happens.

Notice how the paper's layer attribution falls out. Cross-resource substitution and allowance overdraft sit at the protocol layer. The duplicate-settlement race is SDK and deployment. Denial of settlement is pure deployment configuration. As you move down the stack, responsibility diffuses — and monitoring is at the bottom, which is to say it belongs to whoever deployed last and read least. The commons is governed by the least-attentive operator on it.

The part that cannot be monitored

One finding is not a governance gap and no amount of monitoring closes it. The authors prove that no output-only pricing scheme can be simultaneously fair to honest users and bounded against inflation of hidden "thinking" tokens; the best achievable manipulation gap is √(1+Θ), where Θ is the hidden-to-visible token ratio. Measured across ten production models, that ratio spans 35× to 3,213×, with visible-only inflation observed at 226× on live traffic.

Sit with that range. It means the quantity you are billed on and the quantity you consume are related by a factor that varies by two orders of magnitude across the models you might route to. Any pricing rule written against visible output is not a slightly imperfect meter; it is a meter measuring a different thing. That is a resource-definition problem, upstream of governance, and Ostrom's answer to those was always the same: you cannot govern what you have not agreed how to count.

The fix is the design principles in code

The authors' remedy is three composable deployment-layer defenses, and they map cleanly. Cryptographic rate limiting — per-session nonces, per-session token caps, minimum per-token prices — is boundary definition and graduated sanction, bounding per-call leverage rather than trying to prevent every abuse. Adaptive billing weights each hidden-compute token by its own cost-to-revenue ratio, which is congruence between the appropriation rule and local conditions; it cuts reasoning-query cost 47%, from $0.00872 to $0.00462. Bounded-loss streaming settles at checkpoints every Δ tokens, capping worst-case interruption loss — monitoring, at a frequency the resource can afford.

Composed: no successful attack across 500 adversarial trials. Cost: 28 ms of latency, 2.8% of a 1,000 ms mean inference; 8.3% throughput reduction, 16.8 to 15.4 req/s; 29.5% more settlement gas. Attacker leverage inverts from 8.7× to 0.9× — below one, which is the number that matters, because it makes the attack unprofitable rather than merely harder.

That is the real result: monitoring cost about 3% and it was never the reason nobody did it. Nobody did it because the loss lands on the merchant and the saving lands on the deployer, and those are different parties.

What this binds you to

Assume you have already free-ridden. You have almost certainly not attacked anything. But if you have retried a timed-out call, run parallel requests against one authorization, or dropped a stream mid-generation, you have exercised the duplicate-settlement, overdraft and denial-of-settlement paths by accident. The paper's attacks are ordinary client behaviour with intent attached. Your innocence is not a control.

Reconcile calls against settlements, not against responses. An HTTP 200 is not a receipt. Where the two diverge you have consumed a service with no settlement record — and if you operate inside a regulated adviser, an input you cannot evidence paying for is a books-and-records defect before it is anything else. Log the settlement hash or log the gap.

Treat a cheap input as an unfinished measurement. If your effective cost per call is materially under the posted price, that is not efficiency. It is leakage you will be re-priced for the moment the merchant instruments it, and any cost model or fee estimate built on the current number is wrong in a direction that gets discovered.

Scope every authorization to a resource, and never reuse one. Cheap on your side, and it removes you from the 38% of hosts where a floating signature has somewhere to float.

If you are the merchant, check your two rate limits against each other. Verification ingress above settlement throughput is a standing offer of free service. Nothing else has to go wrong.

What to watch

All findings were disclosed, so the near-term question is whether fixes land in the SDKs or stay in the papers. Watch the resource-binding predicate specifically — that one is a protocol-layer change and the hardest to ship, because it invalidates the floating authorization that some integrations have quietly come to rely on.

The longer question is who ends up owning monitoring on a rail nobody owns. Three plausible answers: the facilitators, who have the position but not the incentive; the large embedders — Google Cloud, Cloudflare, Stripe — who have both and would turn an open standard into three private ones; or an appropriator-accountable monitor of the kind Ostrom kept finding in the systems that lasted, which does not exist here and which nobody is currently building. The first two are what usually happens. The third is what usually works.