← /state · JSON twin · methodology

The week a change on the record beat every other predictor

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

Now: 5,036 listings on 1,899 hosts, 4,653 verified, 1,177 paid-verified out of 2,552 paid attempts (47.7% on the payment-required denominator), 284,116 probes in the last 24 hours at a 96.2% pass rate, mean re-probe gap 26 minutes.

1. What we got wrong this week

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

Correction #19 — rate limiting counted as failure (2026-08-27 to 2026-09-13). Our prober treated HTTP 429 as a failed probe. Five consecutive failures mark a listing failing, and failing listings get scheduler priority — so a host that throttled us was probed harder and throttled more. In the seven days to 09-13 18:30 UTC, 35,302 of 2,002,591 probes drew a 429 (1.76%), and 620 transitions to failing across 7 hosts and 52 listings had nothing but 429s behind them. 505 of those were one host, whose 21 listings cycled in and out of failing about two dozen times each at 200 requests an hour from us, of which 92% were refused; a comparable host at 53 requests an hour returned none. A 429 is now warn:rate_limited — recorded, excluded from the published pass rate, neither a failure nor a pass for status — with a per-host cap and a backoff that drops a host to one request per tick after any 429. The first fix covered the GET only; a 429 on the POST retry was still filed as not_payment_gated until it was caught the next day. The worked example is a file rather than an assertion: /state/controls/osf-429neutral-v2.csv — per day, passes split into 402 and free-sample-200, probes, 429s, and the share under both the old and the corrected rule. Under the corrected rule, 18 of that host's 19 “mixed” days read 0.96–1.00 and one reads 0.363.

A verified badge on a burn address (2026-09-14). One listing held verified while its payment challenge named the zero address — an address that cannot receive funds. The record had warned about it since 09-05; the status did not agree. A rule now does: a challenge naming a sentinel address blocks promotion and demotes a verified listing with reason payto_sentinel in the changes feed. Probes continue and a real address earns the status back. The listing was demoted twenty minutes after the rule shipped.

Our own manifest described this directory as free (2026-09-05 to 2026-09-16). The well-known x402 file listed two of our four paid routes and said that nothing here charges — ten days after the first paid route shipped. A registry rendered exactly that back to us. The paid routes now live in one place in the code and every surface derives from it, the same fix we made for the tool list last week after six surfaces named three tools when four were served.

And one on this very page's companion. The outcome table published on 09-15 (below) had two labels reversed — it said money moved on a class where the seller usually refuses before settling. Corrected within hours, on the page.

2. Wave 10: a change on the record is the best predictor of non-delivery we have

On 2026-09-15 the scout attempted 168 endpoints in one wave. 110 delivered.

Tier 1 was 33 listings we had already bought from at least once, selected because something on the record changed afterwards: 4 rotated their payTo, 14 changed price, 15 moved away from verified. Eleven delivered.

The honest split: 13 of the 33 were already failing when selected, and none delivered — a corpse confirmed as a corpse is not news. The other 20 still looked healthy. Eleven delivered and nine did not. A change on a listing that otherwise looks fine is roughly a coin flip on whether it still works, which is the case for re-buying on change rather than on a schedule.

The fill pass was 135 endpoints that had refused payment for weeks because their 402 declared parameters our scout would not invent. Re-tried with a generic public value (a ticker, a city, a well-known address), 99 delivered. declared_params_unmet fell from 274 to 194. Nothing about those endpoints changed; our willingness to fill one field did.

What the fill pass cannot do yet. 19 endpoints took the filled value, answered the challenge, then rejected the request at validation — mostly parameters that want a URL of a specific kind (a Facebook profile, a LinkedIn company). A generic value passes the paywall and fails the handler. 18 of the 19 were not charged: the seller validated before settling. This deserves its own outcome label and a better fill source — the provider's own /.well-known/x402 example, which about 63% of listed hosts publish.

3. A 402 that validates is not a 402 that sells

Everything this directory publishes rests on one claim: a check that stops at the challenge is not enough, and only paying tells you whether a thing works. That applies to us, so our own paid routes are tested by buying them, on the deployed code, with a real wallet.

It found what no other check could. Two of our routes advertised a payment challenge that passed every structural test — well formed, header byte-identical to the body, price and payTo declared, canonical resource URL, the route template answering 402 rather than 404 — and could not complete a purchase. The cause was in a field nobody probes: the description inside the accepts entry. A paying client copies that entry verbatim into its payment payload, and the facilitator's schema rejects a description beyond roughly 512 characters. Ours, written to be helpful to registries, were too long. Every paid request failed at verification, before any money moved, with an error truncated before the reason.

A probe cannot see this. A conformance script cannot see this. It is the same lesson we publish about listed endpoints, learned at our own expense: the gap between “serves a valid challenge” and “delivers when paid” is where the failures live. All four routes now declare descriptions under a fixed limit, the limit is an automated invariant, and each route has since been bought and settled end to end.

A related finding, from watching an outside client rather than testing ourselves: our seller-facing route answered HTTP 429 when a plan was already running for a listing. 429 means “slow down” and invites a retry, so a discovery crawler retried eight times in nine seconds. It is now 409, a conflict — and the check that produces it no longer runs before the unpaid branch, because a plan in progress must not hide a published price from anyone reading terms.

4. Every paid-verification outcome now has a published definition

A reader asked in August what settlement_unproven meant in /v1/stats. It appeared in live statistics and was defined nowhere. It is now a table at /methodology#outcomes: every label, what the scout did to produce it, whether USDC left our wallet, and where it sits in the published pass-rate denominator.

Two worth restating. settlement_unproven_onchain means the endpoint served a correct response but we could not find the settlement on Base after checking every hash the response claimed and sweeping the payTo — recorded as not delivered, because we do not credit a delivery we cannot prove we paid for. And rejected_400_blind_request is a 400 on the paid request, usually not charged: the seller validates before settling, 9 of 128 in the audit had actually settled, and the row says which.

The denominator is stated: every attempt except endpoints that turned out not to charge at all. Refusals we chose, settlements we could not prove and our own client errors all count against the rate, which is why 47.7% is lower than a liveness figure would be. our_limit reports how many are ours, so a reader can subtract them.

5. What agents ask for, end to end

Over the last 30 days: 6,104 discovery calls from 493 distinct clients, of which 3,063 carried a search term. Applying the published exclusions — queries under five characters (catalogue enumeration; at one point the ten most common terms were the single letters a–j) and searches from clients that also edit listings here (sellers checking their own rank; one accounted for 376 asks) — leaves 1,912 queries containing 307 distinct texts, clustering into 16 topics that three or more independent clients asked for. A further 197 clusters fell below that floor: counted, not shown, because a term one client asked for is that client's business.

Distinct client counts are a ceiling on independent demand, never a count of buyers: one serverless caller has presented eight addresses in a second.

Why the free feed reads empty right now. /v1/demand publishes a complete window that ends seven days behind live — a deliberate lag introduced on 09-12, so the free tier is current enough to be useful and stale enough that it is not a live feed of what buyers are searching for this hour. It begins returning terms on 09-19. The clustering figures above are from the same data as of 2026-09-15.

6. A directory that can be read by anything

Three fixes this week came from watching what outside clients actually hit:

7. Two instruments, one month

A peer running one probe a day against four hosts we also watch laid his daily snapshots against our per-day file across 124 host-days. Where a day has a single answer, the two instruments agree completely: 56 of 56 all-402 days, 50 of 50 all-fail days. On the 18 mixed days his sample landed on a challenge 16 times against an expected 14.6 — noise at that sample size — and the two he missed were the two lowest-402-share days in the entire file, which is what an unbiased sample should miss.

Two controls were then cut on his criterion, and one produced a 3.3-sigma disagreement. It was ours: the 429 bug in section 1. He took it as his own error first, corrected his README, and shipped per-verb instrumentation the same day; the account above is what the data showed. He also found the same class of defect in his own series — a 429 filed as “not gated” on 39 host-days — corrected two published numbers by one each, and labelled rather than deleted the affected artifact.

Where the instruments still differ, stated plainly: his 429 verdict is RATE_LIMITED, counted as not assessed; ours is warn:rate_limited, a pass with a warning, excluded from the published rate. Same event, two treatments, his the more conservative. And the cause differs by rate: at 200 requests an hour a 429 is a fact about us; at one request a day, drawing 429s from a single host on 35 of 37 days, it is that host's policy toward anonymous callers. The label names neither party for that reason.

Still owed: a genuine flapper we also pay from, now that the control we chose turned out not to be one.

8. The landscape, and one thing we can check

Independent measurement of this ecosystem is getting better and more pointed. A weekly payability report published on 09-13 makes two findings worth repeating: of 47 declared networks, most of the multi-chain map is one host — a single operator declaring 583 endpoints accounts for 74–99% of the payable endpoints on eight networks — and a host that was 37% of a tracked slice went unreachable for a week with DNS still resolving, which the report notes no directory flagged.

We carry four paths on that host. All four moved to failing here at 14:36 UTC on 2026-09-06 — the day it went down, a week before the report — and each listing page carries the transition with its reason, as does /v1/changes. We index by listing rather than by crawl, so four of their 844 paths is all we can speak to.

The broader point is right and worth conceding: a listing tells you nothing about whether an agent can pay a counterparty. Our answer is not a live check either. It is a purchase, and the record says whether the endpoint delivered when paid, with the transaction. Two other projects now do something similar at smaller scale; we no longer describe ourselves as the only one, and the word came off every surface this week.

Method changes

Data

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