CORTX has now run more than 4,500 checks against x402 endpoints, including 351 paid calls.
For paid checks, we don't just ping a server. We make a real x402 request and record what happens through payment terms, pricing, payment, settlement and delivery.
The point is simple: if we're going to tell you an endpoint is reliable, the evidence behind that claim has to be reliable too.
Last week, we audited our own evidence.
We found problems.
Some came from our code. Some came from x402 changing underneath us. And one thing we published in August was wrong.
So we fixed the checker, repaired the historical data and updated the reliability spec.
Here's what we learned.
1. Our monitor blamed builders for our own problems
To check a paid service, CORTX pays it from a small test wallet. When that wallet ran out of USDC, the payment step failed, and our monitor recorded that as the service failing. Two failures in a row opened an incident and alerted the builder. Their public status page and badge showed a broken service, when the only thing broken was our wallet.
What we changed: a check can now fail in two different ways. If the problem is on our side — empty wallet, spent budget, a payment method we can't make, our own crash — the check is marked as a CORTX-side error. It never counts toward a service's uptime, never opens an incident and never alerts the builder.
Going back through the history, we found 8 checks that had blamed a service for our wallet and 1 incident that should never have opened. Both are corrected, and the incident is closed as a false positive.
2. A labelling bug made our numbers look better than they were
On August 15 we shipped a change that quietly saved every paid check's results one step out of place. One step in our pipeline was counted twice, so each later result was stored under the name of the step before it.
The effect was quiet but real. What we published as “paid delivery %” was really measuring “the price was fine and we signed the payment”, and “schema validity %” was really measuring “the response was valid JSON”. Both looked better than the truth.
What we changed: the pipeline now refuses to run if it ever has more steps than names, and a test runs our real checker against a fake x402 service and checks every step name — it fails on the old code. Then we repaired the history: 389 paid checks now carry the right step names. Some historical percentages went down. The new numbers are the true ones.
If you're looking at reliability numbers from anyone, including us, ask how they're produced.
3. x402 V2 moved the payment terms
In x402 V1, a service that wants payment answers HTTP 402 with its payment terms in the response body, and the client pays with an X-PAYMENT header. In V2, the terms move into a PAYMENT-REQUIRED header as base64-encoded JSON, the client pays with a PAYMENT-SIGNATURE header, the price field is called amount instead of maxAmountRequired (both in the token's smallest unit), and networks are named in CAIP-2 format — eip155:8453 for Base rather than base.
Our checker was reading the V2 header as plain JSON, so every service that published its terms only in that header failed at the payment-terms step. It looked like a broken service. It was a checker that didn't speak the new version.
What we changed: CORTX now reads both versions and pays V2 services the V2 way. The Bankr services we monitor are paid with V2 payments ($0.001 each) and pass end to end.
If you build a checker, an agent or a wallet integration, test it against a V2 service, not only V1.
4. “Payment confirmed” has to mean the money moved
Our payment step used to say “confirmed” as soon as we had signed the payment. A signature proves nothing about what happened on-chain.
What we changed: after a paid call, CORTX reads the service's settlement receipt — PAYMENT-RESPONSE in V2, X-PAYMENT-RESPONSE in V1 — and records one of three things:
- confirmed — the receipt says the payment settled and names the transaction
- failed — the receipt says it didn't settle
- unconfirmed — the service sent no readable receipt
The transaction hash comes only from that receipt. We never guess it, and when it's there you get a Basescan link.
We read the receipt even when delivery fails. In x402's default flow a service settles only after it has done the work, but the protocol also allows settling first, and not every service gets the order right. The receipt is what lets us show the case that matters most to anyone paying for an API: the money moved, and nothing came back.
5. A correction to our August post on facilitators
On August 29 we wrote that x402 facilitators aren't universal. That part stands: a service chooses its own facilitator, and x402.org doesn't know about every service. Two things in that post are now wrong.
We said to fall back to x402.org when a service doesn't publish its facilitator. Don't. In x402 the facilitator is the server's business; guessing one makes a healthy service look “not ready”. If a service doesn't publish it, the honest answer is “we can't check this”, not “this is broken”.
We showed payment readiness working for 5 of 6 services. Since then, Bankr's facilitator has started requiring authentication (401 missing bearer token). We can't run that check against those services any more, so CORTX now reports it as unavailable — not as a failure — and relies on the real paid check instead.
The August post now carries a note pointing here.
6. We put all of this in the open standard
The x402 Reliability Spec is our open, Apache-2.0 description of how to check an x402 service. Version 0.3 covers everything above: both protocol versions, a separate category for checker-side errors that must never count against a service, settlement receipts as the only source of a transaction hash, and no default facilitator.
It also ships 8 test cases: fake x402 services, each with the exact result a correct checker must produce — a V2 service with its terms only in a header, a service that takes the payment and then fails, a checker whose own wallet is empty, and more.
CORTX runs all 8 through its real checker in its test suite, and passes all 8. Its public reliability API now returns each service's latest paid check in the spec's format. And CORTX itself is open source, under the MIT licence.
You don't have to take our word for any of this. You can run the same tests against our code — or against yours.
The monitor has to meet the same standard
Reliability monitoring only works if the monitor is held to the same standard as the services it monitors.
That's the biggest thing we learned from these changes.
A failed check doesn't automatically mean a failed service. A signed payment doesn't mean money moved. A 200 doesn't mean the buyer got what they paid for. And a metric isn't useful if you can't explain exactly how it was produced.
That's what we're trying to make CORTX better at measuring.
Check your own endpoint for free → The free checks run on any public x402 URL, and the paid part runs for services up to $0.01.