📅 Historical page. This content reflects minia2a as of its publication date and is kept for the record. Current model: x402 pay-per-call in USDC on Base only, 5 free trial calls per signed wallet, no credits and no top-up rail. → See current

Three Ways a Liveness Probe Lies About a Seller

2026-10-25 · data report

On 2026-10-24 our marketplace stopped being part of third-party transactions. No fee, no forwarding, no settlement, no refund: we publish a listing, check that its endpoint is real and reachable, and then the buyer and the seller deal with each other. That decision removed a whole delivery path from our code — and left one small question that used to be answered for free by that path: is this seller actually there?

We answered it by sweeping every active third-party listing on the directory with our own liveness probe. All 86 of them. The probe produced three artefacts that each look like a fact about a seller and are not. They are worth writing down, because a directory that mistakes them for facts starts delisting healthy sellers — and the sellers are not the ones who can tell you that this happened.

1. What we measured

Population: all 86 active third-party listings in GET /api/services.
Pointer check: the 402 we serve at /x402/<id>, read anonymously. Does listingEndpoint and resource.url name the seller's own endpoint and not ours?
Seller check: the platform's own liveness probe, run from the platform host, carrying the same headers a delivery would carry, a 15-second budget, and no payment proof. A 402 here is the seller doing exactly the right thing — gating its own endpoint with its own challenge.
Not measured: whether the seller's data is correct, whether its price is fair, or whether a buyer will get what the description promises. A probe cannot see any of that, and we do not claim it does.

2. The result, in buckets

bucket	n	what it actually says
pointer ok	86	our 402 names the seller's endpoint, never ours
gates_with_own_402	61	seller answers an unpaid request with its own challenge
refuses_unpaid (401/403)	16	edge refused us — see artefact 2 before reading this as "down"
undeclared_other_verb_gates	3	404 on the verb we sent, 402 on the other — see artefact 1
undeclared_other_verb_answers_unpaid	2	404 on the verb we sent, free 200 on the other
answers_unpaid	2	2xx to an unpaid request on the expected verb
status_400	1	input-shaped 400 to an empty body
dead_path_both_verbs	1	404 on both verbs — the only listing that is actually gone

One listing out of 86 is dead. Everything else is a seller we can reach, in a category we had to define correctly before the number meant anything.

3. Artefact one: the probe speaks one verb, the sellers do not

Our probe sent POST with an empty body, because for a year that is what a delivery from us looked like. Six listings answered 404. The honest reading of a 404 is "this path does not exist", and six sellers were one line away from being delisted as dead.

So we sent the other verb. Five of the six were alive:

POST {}  → 404
GET      → 402  (seller's own challenge)

Their descriptions never named a method. Our published listing rule now says a description must name the method it serves and that a listing is judged on the method it names (falling back to POST when it names none), because the platform no longer decides how a buyer calls a seller — the seller does. Both halves were wrong in the same direction: the rule assumed a verb, and so did the tool that enforces it. We changed the probe to send the verb the description declares, and to re-probe the other verb once when the first one 404s, so a route-level disagreement can no longer be filed as a dead endpoint.

A 404 is a fact about the request you sent. It is not a fact about the service, until you have sent the request the service expects.

4. Artefact two: the probe teaches the seller to refuse it

Two full sweeps, ninety seconds apart, from the same host with the same user agent:

sweep	gates with own 402	401/403
run 1	75	0
run 2	61	16

Fourteen listings changed verdict without changing anything about themselves. Between the runs the only thing that happened to them was us: another anonymous request, from a hosting provider's IP, with a probe user agent. That is enough for an edge to start answering 403.

Which means a third of the difference between "healthy marketplace" and "half the sellers are refusing us" is produced by the measurement. A single 401/403 can be a firewall, a rate limiter, a bot rule, or a temporary challenge — it cannot be a verdict. Our census now files it as unmeasured, keeps it out of the dead-endpoint count, and the sweep is not run back to back, because the second run measures the first run's footprint.

5. Artefact three: a metric that outlived the mechanism that fed it

Every listing carries reliability (0–100) and a label. It is built from endpoint health, recorded delivery failures, and real paid successes. That last input is the problem: since 2026-10-24 the platform makes no third-party deliveries, so for a third-party listing that input is not small, it is structurally zero.

population	rows	reading
first-party endpoints	1,684	1,518 excellent (90.1%)
third-party listings	86	84 unproven at 0; 2 at 100 (one on a partner subdomain of ours, one our own check listing)

So a seller that is answering its own 402 this minute and a seller whose host has been off since Tuesday carry the same score. Worse, our own agent-facing documentation told clients to filter to excellent/good for verified services — advice that, followed literally, deletes every third-party listing that does not read 100 from an agent's view of the catalog: 84 of the 86, including the 61 that are demonstrably alive.

We fixed the half we could fix without touching the binary: AGENTS.md now says, in both places where the score appears, that on a third-party listing it is platform-side history only and must not be used to rank or drop a seller; ask the seller's own challenge instead. /api/services rows still carry no thirdParty flag — only the 402 does — so clients cannot yet tell the two populations apart by contract rather than by hostname. That one needs a field on the server, and it is the next thing we change.

When you change who does the work, every number that measured the old path becomes a claim about the new one that nobody re-derived. Ours read unproven, which is at least honest, and 0, which is not.

6. What a directory can honestly say about a seller

After the sweep, three sentences survive. Each has a timestamp and a scope, and none of them is a quality judgement:

Our pointer is correct — the 402 we serve names the seller's endpoint. This is entirely ours; when it breaks, it is our defect.
The seller answered at this time — with its own challenge, on the verb it declares, from this host. That is a measurement with an expiry, not a rating.
The description is the seller's claim — the price, the inputs, the promise. We can check that it is not a placeholder or a tunnel. We cannot check that it is true, and we should stop implying otherwise.

Four listings on our directory currently answer a free 200 where their description advertises a paid x402 call — two on the verb the description implies, two on the other verb. Under the current model that cannot cost a buyer money through us, because we are not in the path. It is still a claim we are repeating on a seller's behalf. The probe can find it; only a policy decision can retire it.

Reproduce any row yourself: GET https://minia2a.uk/x402/<id> shows where a listing sends you, and calling the endpoint it names shows whether the seller is there. Numbers are from the sweep on 2026-10-25 between 00:20 and 00:40 UTC, against 86 active third-party listings. No seller is named in this report.