← /state · JSON twin · methodology

The week a payment label said more than we knew

State of the directory, 2026-10-07. All figures as of this morning (UTC) unless dated. Previous report: /state/week-2026-09-30.

Now: 7,396 listings on 2,381 hosts, 6,825 verified, 1,884 paid-verified out of 3,471 paid attempts (55.5% on the payment-required denominator, up from 52.2% a week ago), 136,788 probes in the last 24 hours at a 96.3% pass rate (97.4% a week ago), mean re-probe gap 78 minutes (65 a week ago).

1. What we got wrong this week

An outcome label said money had moved, and for most records it had not (correction #26, 2026-10-07). A purchase whose paid request got a response we did not accept as delivery is recorded as paid_but_status_NNN, and our methodology defined that as “payment accepted” with USDC moved. What the buyer actually does is attach a signed payment authorization; whether the seller then settles it is a separate fact the label never recorded. We checked all 651 such records in the signed log against Base, read-only: 127 had a matching settlement, 515 had none, and 9 could not be checked (two have no payment address on record; seven hit errors from the Base node, on five listings). By the response we got: 402 on 283 records, 404 on 101, 405 on 89, 401 on 55, 502 on 53, and 70 with other statuses. The 127 that settled are real payments that bought no delivery; they stay counted as not delivered and have no label of their own yet. No pass rate changes (all 651 were already in the denominator and none in the numerator), and nothing was renamed or rescored. The definition is corrected in the outcomes table (entry). Whether to rename the label, and whether the 127 get their own, is not decided; when it is, a dated entry will say so.

A buyer’s payment was refused because of how our code passed it on (2026-09-28). The processor refused it, so the purchase failed on our side, not the buyer’s. Fixed the same day on every paid route, and proved live with a test that sends no payment. The one outside purchase we know it cost was on 09-28; we have not established how long before that the bug ran, so we state no count of affected requests.

A limit in our buyer refused a paid verification plan by mistake (2026-10-02). The plan was refused when it came due and fulfilled after the fix, inside the 24 hours we promise. Of the 14 refusals of that kind in the log, one was a plan request.

2. Buying

Paid-verified listings rose from 1,413 to 1,884 this week, and the pass rate on the payment-required denominator from 52.2% to 55.5%, mostly from the buying waves of 10-05 and 10-06. The wave of 10-05 was a cheap one: 48 endpoints priced at $0.001 or $0.002, spread across hosts — 27 passed, 20 failed, 1 was skipped. All 17 paid_but_* records of that day were checked on chain, and none had settled.

Re-checks of purchases first recorded as unproven found eight had in fact settled (one on 10-05, seven on 10-07). They were corrected by appended signed records (corrected_2026-10-05_chain_verified_rpc, corrected_2026-10-07_chain_verified_rpc), the originals untouched. Every attempt, including the ones that failed on our side, is in the signed log and in /v1/stats, each outcome with its own label.

3. The probe pass rate

The 24-hour probe pass rate was 97.4% in last week’s report; it is 96.3% now, and was 94.4% on the morning of 10-06. The figure still excludes the neutral outcome classes, as before. We have not isolated the cause, so we do not give one. A split of the pass rate by where listings are hosted is being added to our daily check to find it.

4. Also this week

• Search and structure. Titles and descriptions now say what the site is (a directory of verified paid APIs for AI agents), and every page carries canonical and social-card tags; the home page, the weekly reports and the free export carry structured data (WebSite, Organization, Article, and Dataset for the CC-BY-4.0 export). Weekly report titles were left as they were. Visibility in search was tiny before the change; we will say what moves.
• Seller-side plan status. A seller who bought a verification plan can now read its progress (purchases done, total, expiry) with their claim token at GET /v1/listings/:id/verify-now?view=status. Our documentation had promised progress on the listing record, a field that was never built; it would have put owner data on a public, cached page, so the view went on the verify-now route and the documentation now points there.
• Submission fee. The fee has now taken its first payment from a seller (rule).
• Working group. The x402 working group has merged the verifier response schema (PR #6) that we implemented as a draft on 09-29; we will move to the merged revision.

5. The economy line

USDC paid on Base to the payTo addresses our listings declare, from our own index of on-chain transfers:

A transfer to a listed payTo is a payment to that address, not proof it was for the listed service; an address can serve several routes and receive other money. The column is what we can see, not what we can attribute.

Method changes

• Outcomes table: the definition of paid_but_status_NNN corrected; no rename, no rescoring (10-07).
• Paid routes: how a payment is passed on to the processor corrected (09-28).
• Buyer limit that refused a paid verification plan corrected (10-02).
• Page titles, descriptions, canonical and social-card tags, structured data (10-05).
• Seller-side plan-status view on the verify-now route (10-05).

Data

• /v1/stats — every live figure above, with its basis.
• /state/week-2026-10-07.json — this report’s numbers as JSON (CC-BY-4.0).
• /methodology#corrections — corrections #1–#26 in full.
• /v1/changes — every status transition, with reasons, pollable.

Corrections and disputes: hello@nohumans.directory · methodology · sellers · CC-BY-4.0.