Paid verification statistics

Probing proves an endpoint answers. It cannot prove that paying it returns anything. So we buy — unprompted, at our own cost, across the population rather than on request — and publish every outcome, including the ones caused by our own client.

6,152 endpoints purchased from · 3,745 delivered

Latest purchase attempt: 2026-10-20. Every figure on this page is computed live from the database on request.

The pass rate, and what it excludes

Of the endpoints where payment was actually required, 61.7% delivered (3,745 of 6,071). The remainder of the attempted set turned out not to require payment at all: there was nothing to buy, so they are excluded from the denominator rather than counted as either a pass or a failure.

Some failures are ours, not the seller's — an unsupported protocol version, a per-call budget refusal, a listing we declined to attempt. They are named individually in the table below and subtracted from nothing. Naming the instrument's own limits is what makes the rest of the figures worth anything.

Basis

Each endpoint's latest attempt, never every attempt row. Many endpoints were retried after a fix on one side or the other; counting rows would double-count them. Dry runs are excluded.

WITH last AS (
  SELECT listing_id, failure_reason, ok,
         ROW_NUMBER() OVER (PARTITION BY listing_id
                            ORDER BY attempted_at DESC) rn
    FROM paid_verifications WHERE dry_run = 0)
SELECT ok, failure_reason, COUNT(*) FROM last WHERE rn = 1 GROUP BY 1, 2;

Every outcome

Outcome	Endpoints
`delivered`	3,557
`paid_but_status_402`	440
`rejected_400_blind_request`	349
`paid_but_status_404`	155
`declared_params_unmet`	150
`pre_flight_status_404`	116
`price_drift`	96
`stale_data`	84
`no_payment_required`	81
`paid_but_status_502`	79
`pre_flight_status_405`	76
`corrected_2026-10-19_chain_verified_rpc`	71
`timeout`	61
`corrected_2026-09-22_chain_verified_index`	61
`quote_above_per_call_cap`	58
`paid_but_status_405`	53
`paid_but_status_422`	49
`pre_flight_status_400`	48
`invalid_json`	41
`error_Failed to create payment payload: No network/scheme registered for x402 version:`	38
`paid_but_status_503`	35
`requires_params_skipped`	32
`params_unknowable`	31
`paid_but_status_401`	29
`pre_flight_status_429`	28
`error_fetch failed`	27
`corrected_2026-09-25_chain_verified_rpc`	26
`paid_but_status_500`	25
`unparseable_402_quote`	24
`settlement_unproven_onchain`	23
`error_payload`	22
`empty_body`	20
`paid_but_status_202`	17
`pre_flight_status_410`	13
`paid_but_status_400`	12
`params_fillable`	10
`paid_but_status_403`	9
`pre_flight_status_503`	9
`corrected_2026-08-21_chain_verified_body_claim`	9
`paid_but_status_201`	8
`settlement_unproven_onchain:local-skip`	8
`error_Failed to parse payment requirements: Invalid payment required response`	7
`corrected_2026-10-07_chain_verified_rpc`	7
`corrected_2026-10-15_chain_verified_rpc`	6
`pre_flight_status_530`	5
`upto_not_enabled`	5
`paid_but_status_409`	4
`error_Failed to create payment payload: All payment requirements were filtered out by`	3
`pre_flight_status_204`	3
`pre_flight_status_501`	3
`pre_flight_status_502`	3
`corrected_2026-10-11_chain_verified_rpc`	3
`corrected_2026-10-20_chain_verified_rpc`	3
`paid_but_status_424`	2
`paid_but_status_429`	2
`schema_mismatch`	2
`error_Failed to create payment payload: EIP-712 domain parameters (name, version) are`	1
`error_Failed to create payment payload: No client registered for x402 version: undefin`	1
`paid_but_status_307`	1
`paid_but_status_415`	1
`paid_but_status_431`	1
`paid_but_status_504`	1
`pre_flight_status_401`	1
`pre_flight_status_500`	1
`pre_flight_status_521`	1
`settlement_unproven`	1
`settlement_unproven_onchain:corrected_2026-10-20`	1
`settlement_unproven_onchain:first-can`	1
`corrected_2026-09-15_chain_verified_index`	1
`corrected_2026-10-05_chain_verified_rpc`	1

What we have got wrong

An early draft of our seller page claimed a pass rate near 94%. It was computed by subtracting a batch of failures caused by a bug in our own purchasing client — but most of those endpoints had since been retried and passed, so subtracting them all double-counted. Caught before deploy.

A separate figure, a percentage of endpoints that accepted payment without settling on-chain, was withdrawn because its denominator could not be reconstructed from our own records. Raw counts with a stated sample are published instead. A rate whose basis cannot be produced on request should not be published at all.

Nine endpoints listed here as delivered were originally graded as failures and corrected on 2026-08-21 after on-chain confirmation. The correction is visible in the table rather than folded silently into the totals.

What this does not establish

A delivered paid call proves that one call, at one moment, returned something. It does not prove the content was correct, useful, or matched what the seller declared it would return. Checking a paid response against the seller's own schema is a dimension we do not yet measure, and we would rather say so than let a checkmark imply it.

Nor does any of this establish who operates an endpoint. Everything here verifies behaviour at a URL. See methodology for that boundary in full.

Machine-readable

Every number above, as JSON: https://nohumans.directory/v1/stats · field reference

Questions: hello@nohumans.directory · methodology · for sellers