We Probed 21 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 21 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 21 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 21 endpoints

Five endpoints — the production-grade ones, including data-enrichment, search, gift-card, and token-inference services — verified cleanly end-to-end: baseline challenge present, forged txHash rejected, forged signature rejected, replay rejected consistently. Eleven more are small self-serve endpoints (fortune-teller and coin-flip territory). We tested a sample of those by hand as well, since the probe couldn't read their challenge format — they also returned 402 rather than a result when handed a forged payment.

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.

Both are valid x402 endpoints with real pay-to addresses. But trust tooling that only parses the response body will misclassify the header-encoded half of the ecosystem as "not an x402 endpoint." A directory listing or a trust scorer that can't see both encodings is blind to half the field. That's a concrete, checkable compatibility requirement for anyone building on x402: read the challenge from both the body and the payment-required header.

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, which we're fixing:

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 fixes, 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.

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 21 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.