← /state · JSON twin · methodology

The week we refunded both outside buyers

State of the directory, 2026-09-30. All figures as of 06:55 UTC today unless dated. Previous report: /state/week-2026-09-23.

Now: 6,873 listings on 2,227 hosts, 6,344 verified, 1,413 paid-verified out of 2,784 paid attempts (52.2% on the payment-required denominator, up from 47.6% a week ago), 153,063 probes in the last 24 hours at a 97.4% pass rate, mean re-probe gap 65 minutes. Fewer probes than last week (285,728) by design: since 2026-09-23 a listing is checked as often as there is reason to doubt it, not on one clock for all (probe tiers).

1. What we got wrong this week

The paid demand feed said thirty days and read about half (correction #24, 2026-09-23). /v1/demand/clusters and /v1/demand/report grouped at most the 2,000 newest searches and labelled the result a 30-day window. The window has held more than 2,000 searches since 2026-08-31, so every sale read less than it said: purchases on 09-19 and 09-20 reached back to 09-05, about fourteen and a half of the thirty days. Fixed the same day, and every result now states the oldest search it read and whether the whole window fit. Both purchases by buyers other than us were refunded in full, on chain: 0x0d33729b…, 0xe3ad3416….

How many clean probes earn verified, stated two ways, each wrong for part of the catalogue (correction #23, 2026-09-23). Our agent documentation said about sixteen; the sellers’ FAQ said three. Both follow from one rule applied from different starting points: a listing whose first probe passes needs three (279 of the 291 new listings verified in the week to 09-23 took three or four); one climbing back after a payment-address change or a failure needs about sixteen. Both texts now state the rule, not one of its cases.

Descriptions of the free demand feed stated a delay and a floor it no longer had (correction #25, 2026-09-24). llms.txt, the MCP tool and the OpenAPI description still said a one-day delay and a floor of three searchers; the feed has run a week behind with a floor of one since 09-12, and always reported its real values. Correction #22 had said the machine-readable side was never wrong; it was. Every description now reads these values from the constants the feed runs on, and our daily check fails if one disagrees.

Two bugs in our own buyer. Some purchases in the wave of 09-24, and earlier ones, failed on our side, not the seller’s: the buyer sent GET to routes whose seller declared POST, and it did not carry the USDC signing domain some sellers require. Both are fixed. A re-check of purchases first recorded as unproven found most had in fact settled; they were corrected by appended signed records (outcome label corrected_2026-09-25_chain_verified_rpc, 26 on the current basis), the originals untouched.

Grouping the paid demand data: a stricter threshold, a duplicate-producing first run, and a wrong explanation (2026-09-28 to 09-29). A hand audit found 96 of 422 grouped phrasings in the wrong need, so the similarity threshold was raised from 0.72 to 0.78 and everything was regrouped (#regroup). The first run, at 22:15 UTC on 09-28, started some needs twice because a build grouped phrasings before the previous build’s needs could be found; paid copies built from 22:21 UTC until the rerun carried those duplicate rows. Fixed and rerun the same night. The next day we attributed the few remaining duplicates to the vector index’s approximate scores and published that; the cause was mostly elsewhere, in the embedding model returning slightly different vectors for the same text depending on its batch, plus a search that can miss a close match. The entry says so (#exact-scores); the fix is planned. Near the threshold, a phrasing’s group can still depend on that noise; counts are not affected, only how they are split.

2. Buying

Paid-verified listings rose from 1,239 to 1,413 this week, and the pass rate on the payment-required denominator from 47.6% to 52.2%, mostly from the waves of 09-24 (listings priced at $0.001 we had never paid) and 09-25 (the re-run after the buyer fixes in section 1). 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. Demand: what we took out, and why

Most raw searches in the demand feed are not buyers looking for something. Two rules now list them apart, with the same counts, instead of mixing them in (/state/demand):

• Lookups of a named listing (09-26): a search that contains one seller’s own name and comes almost only from clients that searched for nothing else — most likely a service checking it can be found (rule).
• Scripted rotation (09-28): a term searched from at least 50 addresses, at least 90% of which searched only once in the whole window — one script rotating across many addresses, not many buyers (rule). Four terms are listed apart under it today.

What remains is specific and unglamorous: funding-rate feeds, real-time stock quotes, geocoding, company and legal-entity enrichment, web pages as clean Markdown. At least one seller told us this week they built an endpoint after reading the feed. The demand data is now also built in the background every fifteen minutes (hourly for the free feed) instead of on each request (#demand-snapshots).

4. A shared answer to “should I pay this?”

The x402 Foundation’s discovery working group has been drafting a common response for verifiers like us (wg-domain-discovery PR #6): whether the claim about a seller’s payment terms holds (true, false or inconclusive), with a closed reason code, the evidence level reached, when it was obtained, and a signed attestation. Since 09-29 our paid verdict carries that object beside our own pay / caution / avoid, which stays as the recommendation that cites it; every attestation is a signed record anyone can check at /v1/attestations/:id against our published key (mapping). Implementing it surfaced gaps the draft then closed: a code for a route that answers without asking for payment, and the rule that “settled under terms” requires confirmed delivery. A verifier is not an independent check of routes its own operator runs, so a verdict on one of ours would be labelled and capped (#self-referential); none of our routes is listed today.

5. Also this week

• Probe cadence. The tiers of 09-23 were amended on 09-24: we never probe more than two of one host’s listings in a run, so a record now says probe_tier: host_limited when that, not the tier, sets its interval. Latency p50 is now a true seven-day median.
• Other payment protocols. Since 09-26 we read MPP offers (WWW-Authenticate: Payment) alongside x402; this morning 886 listings’ challenges carry one, all but one of them alongside x402 terms (#mpp-offers).
• Submission fee. The first five listings per registered domain are free; beyond that a new listing costs $0.25 USDC on Base, paid over x402 (it was $0.50 when introduced on 09-25). Paying proves the submitter’s x402 client works (rule).

6. 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

• Probe tiers: host_limited interval; the score of a listing whose first probes were neutral starts at its first counted probe (09-24).
• Demand: named lookups (09-26) and scripted rotation (09-28) listed apart; background builds (09-28); threshold 0.72 → 0.78 and a regroup (09-28); candidates near the threshold re-scored (09-29).
• Paid verdict: the working group’s draft verifier object and signed attestations; self-referential rule (09-29).
• Submission fee introduced (09-25) and lowered (09-28).

Data

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

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