If you're about to pay an x402 endpoint for a call, the first thing you want to know is whether that endpoint actually verifies payment — or whether it just trusts whatever headers you send and delivers anyway. The second thing you want to know is whether it will re-deliver the same work twice on a replayed payment. Both are "free-riding" failure modes, and both are checkable with a black-box test that doesn't cost you a cent.
We ran that test against 131 live endpoints and got a result worth reporting, because it's the opposite of what you'd expect if you've read about x402 security failures in the abstract.
We pulled the discovery index and ranked endpoints by real 30-day call volume — the ones people are actually paying to call — rather than the long tail of demos. For each endpoint we:
402 payment challenge (recipient address, price, network, method).X-Payment-Tx pointing at a transaction that doesn't exist on-chain).PAYMENT-SIGNATURE).An endpoint was flagged as vulnerable only if it returned 200 with a real payload despite the forged proof — i.e. it delivered the goods without a verifiable on-chain payment.
| Verdict | Count | Meaning |
|---|---|---|
| SAFE | 125 | Forged txHash, forged signature, and replay were all rejected. |
| NOT_X402 | 6 | No valid 402 challenge returned (not a live x402 resource, or unreachable). |
| RISK | 0 | Would have delivered without a real payment. |
The headline: 0 of 131 live endpoints accepted a forged payment. The simplest free-riding attack — send a fake txHash or a fake signature and hope the server trusts it — does not work against the endpoints that are actually transacting.
It proves that on-chain payment verification has become table stakes for live x402 resources. The protocol's basic promise — "the server checks the chain before it delivers" — is being kept by the endpoints doing real volume. If you've been worried that the whole ecosystem is naive about payment forgery, the empirical answer at the head of the demand curve is: no, the serious endpoints verify.
This is the more important half. A black-box test of "did it deliver without a real payment" only sees one failure class. It is blind to several others that don't show up as an obvious free delivery:
These need to see the source — they're white-box findings, not something you can reliably provoke with headers. That's the honest boundary of the method: black-box proves the endpoint rejects forged payments; it doesn't prove the endpoint's entire payment path is sound.
Before you pay a new x402 endpoint, the cheap black-box pass is:
402 challenge and confirm the payTo address and price are what you expect.X-Payment-Tx and a forged PAYMENT-SIGNATURE. If it returns 200 with a payload, stop — you can be charged for nothing.We've turned this exact method into a product — a buyer-side trust check that returns SAFE / RISK / NOT_X402 for a given endpoint, and a white-box source audit for the classes the black-box test can't see. Both are listed in the catalog under contract-audit.
This sample is biased toward the healthy end of the ecosystem: endpoints that are listed in a discovery index and doing call volume are the ones that survived onboarding and stayed alive. A freshly-minted or unlisted endpoint is not covered here, and a keyword-based "did it deliver" heuristic can mislabel a 200 that happens to echo an error string. Treat 0-of-131 as a property of the live demand curve, not a claim about every x402 endpoint in existence.
The reassuring finding and the honest boundary together point the same direction: verify before you pay, and match the depth of the check to what's at stake.