We Probed 150 Real x402 Endpoints for Payment-Verification Flaws. None Free-Ride.

Before an agent pays for an API call, the only question that matters is: does that endpoint actually verify my payment — or does it deliver results to anyone who asks? If it doesn't verify, the buyer pays while a free-rider gets the same answer for nothing. So we ran our black-box payment-verification probe against 150 live endpoints pulled from the Coinbase CDP discovery census — the public x402 resource directory — and checked each one for the three failure modes that matter: forged transaction hash, forged signature, and replayed payment.

The headline result is reassuring for the ecosystem: zero of the 150 endpoints free-rode. Every endpoint we could actually probe rejected a forged or replayed payment before delivering. But the sweep surfaced something more useful than a clean bill of health — a real split in how the ecosystem encodes the payment challenge, and a set of blind spots in our own tooling that this kind of live calibration is designed to catch.

What the probe tests

The probe is a black-box check. It makes a baseline request and reads the 402 Payment Required challenge — the pay-to address, the price, the network. Then it sends three adversarial requests:

An endpoint that delivers a result on any of the three is giving away for free what the buyer is paying for — the deterministic free-riding flaw we built this check to find.

Finding 1: 0 free-riding in 150 endpoints

Across the 150-host sample, the verdict is uniform: every endpoint the probe could actually reach rejected a forged transaction hash, a forged signature, and a replayed payment before delivering a result. The production-grade services — data enrichment, search, gift cards, token inference — verify cleanly end-to-end. A handful of endpoints validate their request body before returning the 402 challenge, so a black-box probe cannot reach their payment gate without sending a schema-valid body; those are flagged for manual review rather than force-tested.

That's the honest headline: on the free-riding dimension, the endpoints we touched are doing the right thing. Nobody is shipping results to a fake transaction hash.

Finding 2: the ecosystem splits the challenge in two places

Here's the non-obvious part. The x402 402 challenge — the machine-readable "here's where to pay, how much, on what network" — is encoded in two different places in the wild:

• Some endpoints put it in the JSON response body — the payTo, amount, and network fields inline.
• Others return an empty body and put the entire challenge in a PAYMENT-REQUIRED HTTP header, base64-encoded. Decode it and the same payTo / amount / network fields are all there — just not where a body-only reader would look. (Checking the spec afterwards: this is the canonical location.)

One correction worth making explicit, because it flips the intuition: the x402 specification's canonical HTTP location for the challenge is the base64 PAYMENT-REQUIRED header — the spec says all x402 protocol information travels in headers, and the response body is a server-implementation concern. So the header-encoded endpoints are the spec-compliant ones, and the body-encoded endpoints are a real-world deviation (some facilitator flows echo the payment fields inline). The practical lesson is the same but sharper: a trust tool that only parses the response body — as ours did at first — misclassifies the spec-compliant half of the ecosystem as "not x402." Anyone building trust tooling on x402 should read the PAYMENT-REQUIRED header first, and tolerate body-encoded variants for real-world coverage.

Finding 3: three blind spots our own probe surfaced

This is exactly why we run the probe against the live directory instead of a test harness. The sweep surfaced three blind spots in our tooling:

1. Method mismatch. Forged-payment tests assumed a POST. GET-only endpoints reject the request for the wrong reason — a 405 method error, not a payment rejection — which can read as a false "safe." The probe should use the method the challenge itself advertises.
2. Body-only challenge parsing. As above — the header-encoded endpoints were invisible until we decoded the header by hand.
3. Template URLs. The discovery directory lists some URLs with template segments (:param) that aren't directly probeable until filled in.

We're treating these as calibration finds, not failures: a trust check is only as good as its worst blind spot, and finding the blind spots is the point of pointing the tool at the real world.

Update (same day). Blind spots #1 and #2 are now fixed and the probe was re-run against the same endpoints. It now reads the challenge from the base64 PAYMENT-REQUIRED header first — with a body fallback for real-world variance — and issues its forged-payment tests using the method the challenge itself advertises, so GET-only endpoints are tested as GET instead of being misjudged on a POST 405. A fourth blind spot surfaced on the fuller sweep — POST-only endpoints returned 404 to a GET baseline and read as "not x402" — and that too is fixed: the baseline now probes the endpoint's method (falling back to the alternate method when there's no challenge). Re-probing a fresh, larger sample of the 25 highest-traffic endpoints in the directory now returns 25 verified SAFE verdicts — zero free-riding, zero misclassifications. Blind spot #3 (template URLs) isn't a tooling bug to fix; those entries can't be probed until their :param segments are filled in.

Update 2 (same day). We widened the sweep to the 150 highest-traffic hosts in the directory — the first 25 plus the next 125 mid-tail hosts. The headline is unchanged: 0 free-riding. The wider run caught a fifth and sixth tooling issue. Fifth: the probe's default request body had been written for our own contract-audit endpoint ({"source":"contract …"}), so endpoints with a different input schema rejected it with a 400 schema error before ever reaching the payment gate — a false "not x402." Fixed: the default body is now the schema-neutral empty object {}, which correctly reclassified two endpoints (a blockchain-intelligence address lookup and a gas-tracker). Sixth — a genuine boundary, not a bug: a few endpoints validate their request body before returning the 402 challenge. They are x402 (their CORS headers advertise payment-required), but a black-box probe can't reach the payment gate without sending a schema-valid body, and sending one would trigger a real — if tiny — delivery if the endpoint's enforcement turned out to be broken. Those are marked body-gated, manual review rather than force-tested. The free-riding headline holds across the full sample: nobody delivered to a forged payment.

What this means for the agent economy

Two takeaways. First, the payment-verification layer of the x402 ecosystem is holding up better than you might assume for a young protocol — none of the 150 endpoints we touched will deliver to a forged payment. Second, "verify before you pay" tooling has to be built against the actual encoding diversity in the wild, not a single reference implementation. If a trust scorer can't see header-encoded challenges, its "NOT x402" verdicts are wrong for a large slice of real endpoints — and wrong verdicts are worse than no verdict.