← /state · JSON twin · methodology

The week stable endpoints delivered 90 of 90

State of the directory, 2026-09-23. All figures as of 04:48 UTC today unless dated. Previous report: /state/week-2026-09-16.

Now: 5,261 listings on 1,903 hosts, 4,769 verified, 1,239 paid-verified out of 2,688 paid attempts (47.6% on the payment-required denominator), 285,728 probes in the last 24 hours at a 92.0% pass rate (see section 1), mean re-probe gap 27 minutes.

1. What we got wrong this week

We lead with this because a directory that grades others has to grade itself first.

61 paid, delivered purchases recorded as failures (2026-09-22). Our buyer checks each payment on chain before recording it. In wave 11 the check ran immediately after the response, and a payment settles 3 to 7 seconds later — so 61 purchases that were paid and delivered were first recorded as settlement_unproven_onchain. Uncorrected, the control group in section 2 would have read about 60% delivery instead of 90 of 90. The buyer now re-checks up to four times, five seconds apart, before concluding. The 61 were corrected by matching each one to its on-chain transfer, one to one, and appending a new signed record that points at the record it corrects; the originals are untouched, because the log is append-only and hash-chained. They count as delivered and keep their own line in the outcome list — corrected_2026-09-22_chain_verified_index: 61 — so anyone can see which verdicts came from a correction.

Correction #22 — the demand feed’s privacy floor, stated wrong. The last statement of the floor on our methodology page said two clients. The rule has been one since 2026-09-12; the feed’s own k_anonymity_floor field, its note and the code said one throughout. The same check produced a mistake of our own: for about four hours on 09-22 the feed enforced a two-day persistence rule that had been removed on purpose on 09-11, publishing 5 terms instead of 43. Reverted the same day; no term was withheld.

About 215 listings shown as failing for part of an afternoon (2026-09-22). Between 12:00 and 17:00 UTC, timeouts rose from their usual 1–2% of probes to as much as 21%, across many unrelated hosts at once, and then fell back. In those five hours 256 listings moved to failing against about 40 in a normal five; most were back within a few hours. A rise that hits unrelated endpoints together and ends together points at the path between us and them, not at the listings — and the whole drop in the pass rate, from 95.0% a day earlier to 92.0% today, is that window. The cause is not yet established, and we are looking at our own side first.

Update, 2026-09-23 — the cause, as far as one vantage point can establish it. Not our software: no probe code changed on 09-22, and deploys at 16:31–16:40 UTC coincided with timeouts falling, not rising. Not all of what we probe either: the timeouts were concentrated on networks on the US East Coast. On DigitalOcean, 64% of probes to 79 of 87 hosts, run by 13 unrelated operators, timed out; on Amazon’s us-east-1, 28%, across 23 operators; Hetzner’s Ashburn network and Contabo’s US network were above 40%. Hosts in Germany, on Google Cloud and on Render stayed at 0–1% throughout, and one provider split by region: Contabo 41.6% in the US, 4.9% in Germany. From a single vantage point we cannot tell an incident on those networks from a problem on the route between our prober and them; Cloudflare’s status history lists no incident on those networks in that window. A rule we shipped on 09-23 to set such windows aside as ours was tightened the same day, because this one was not: Method changes.

Paging through the catalogue did not end. On the last page of /v1/listings, next_offset pointed back at the page it came from, so a client following it correctly looped — one did, about three requests a second, until the fix. next_offset is now null on an empty page. The same investigation found total one higher than the rows the list returns; it now counts exactly those rows.

2. Wave 11: what happens when you buy the same endpoint twice

On 2026-09-22 we paid 185 endpoints and recorded what came back. The wave was built to answer a question the earlier waves could not: does an endpoint that delivered once keep delivering? It was drawn in four parts, each fresh and de-duplicated, with the part recorded against every listing.

Stable endpoints keep delivering: 90 of 90. Of the 100 drawn, 10 stopped before payment; every one of the 90 that took payment delivered.

“Changed” mostly means gone. 36 of the 45 listings whose terms had changed since we last bought never reached payment at all — 5xx, 404, 410, connection failure. The 9 that did answer all delivered. Last week’s finding holds: a change on the record is the strongest warning we publish.

The five paid-but-not-delivered cases all charged before validating the input. Two async jobs accepted payment and returned a job that finished with “no task supplied”; one returned 400 after payment; two returned an empty body. Together they cost $0.111. In 185 paid calls there was no case of a seller taking money for a well-formed request and returning nothing.

Method notes, so the table can be checked. Control and Changed were re-bought through each listing’s last called URL, not its bare endpoint: on a first attempt the bare URL made 31 control rows fail as “parameters required” on endpoints we had bought successfully before — a failure of our request, not of theirs. The Fill part is only the 36 rows with no delivered purchase yet; the other 100 parameter-filled listings were bought and delivered in wave 10.

3. An independent check

Paddock answers “should this agent pay this address” from the chain side, before the payment. We answer from the wire side, after it. For this wave: 185 paid calls, 182 decisive verdicts, 178 matched the outcome — and 97 of 97 on second purchases. The four misses were all first purchases and all of the input-validation kind in section 2: a pre-payment check reads the seller’s quote, not the request you are about to send, so it can confirm the price, the chain, the token and that the service is settling — it cannot confirm the seller will accept your particular request.

4. Also this week

• /state/demand rewritten for people. What agents searched for, a week late, every term that passes the published rules, in plain language: asked on more than one day, asked on one day so far, and how to read each column. The JSON feed for agents is unchanged.
• Agent discovery. /.well-known/api-catalog (RFC 9727), Link headers on both front doors, and the root answers in Markdown to a client that asks for it. A documented path called with the wrong method now answers 405 with an Allow header instead of 404, and /api/… guesses are redirected to the real routes.

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

• The buyer re-checks settlement on chain up to four times, five seconds apart, before recording a payment as unproven.
• Re-purchases of a listing use its last called URL, not its bare endpoint.
• /v1/listings: next_offset is null on an empty page; total uses the same filter as the list.
• A documented path called with the wrong method answers 405 with Allow.

Data

• /v1/stats — every live figure above, with its basis.
• /state/week-2026-09-23.json — this report’s numbers as JSON (CC-BY-4.0).
• /methodology#outcomes — every outcome label defined.
• /v1/changes — every status transition, with reasons, pollable.

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