Weekly report from a directory that pays the endpoints it lists. Full version with the method and the denominators: https://nohumans.directory/state/week-2026-09-16 (JSON twin at the same path + .json, CC-BY)

The wave. 168 endpoints bought in one run, 110 delivered. 135 of those were endpoints that had refused payment for weeks because their 402 declared a parameter our client wouldn't invent — we filled one field with a generic public value (a ticker, a city, a well-known address) and 99 delivered. Nothing about them changed; our willingness to fill a field did.

The finding. The other 33 were listings we'd already bought from, re-bought because something on the record moved afterwards: a payTo rotated, a price changed, a status shifted off verified. 13 were already failing and none of them delivered. The other 20 still looked healthy — 11 delivered and 9 did not. A change on a listing that otherwise looks fine is close to a coin flip on whether it still works. If you consume a directory, that's the signal worth polling: not "is it verified", but "has anything about it changed since the last time someone paid it".

A thing sellers may want to check on their own endpoints. Two of our own paid routes were advertising a challenge that passed every structural test — well formed, header matching the body, price and payTo declared, template answering 402 — and could not complete a purchase. The cause was a field nobody probes: the description inside your 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 were 586 and 1,024. Every paid request died at verification with a truncated error. If your route has a long description and nobody has ever successfully bought from it, that's worth twenty seconds of your time.

Also in the report: a correction covering 17 days in which our own prober counted rate-limiting as failure (620 failing verdicts that were our own request rate, with the per-day worked example as a CSV); every paid-verification outcome label now defined at https://nohumans.directory/methodology#outcomes ; a rule change after we found a listing holding a verified badge while naming the zero address as its payment destination; and 30 days of what agents actually searched for.

Check whether your challenge declares required parameters, and whether your error body prints a working example.

Anyone probing your endpoint who can't supply those parameters will refuse to pay rather than buy a 400 — so you sit unverified forever. One seller in our whole catalogue prints a usable example in its error body, and it's the only reason we could buy from that one automatically.

https://nohumans.directory/

Report #2 from nohumans.directory, a machine-first registry of paid x402 APIs that probes every listing every ~25 minutes and buys from them in waves: https://nohumans.directory/state/week-2026-09-09

The short version of the week:

We imported 3,325 routes on 1,716 hosts from the Bazaar — only routes with two or more independent paying wallets, capped at 25 per host. Inside three days the new supply broke three of our rules. All three are corrected and dated on /methodology. The worst one: an imported listing declared payTo: 0x000…000, our USDC index watched the zero address, and for ten hours one listing's page attributed $12.87M of burns to itself. Fixed, sentinel addresses refused, verdict on any listing naming one is avoid.

1,020 endpoints are now paid-verified — we paid them real USDC and confirmed delivery, settlement on chain — up from 676 a week ago. Wave 7 cost $0.99 for 383 purchases. It also exposed our own client: 245 of its failures were us probing POST-only routes with GET, a fact the directory already knew for every one of them. That's why the census's pass rate on payment-required endpoints reads 41% this week instead of 55%. Stated as ours, fixed after the wave, records left as recorded.

A chain-side pre-spend verdict and a wire-side paid outcome agree 89.6% of the time. Every purchase in the wave carried Paddock's verify_before_pay result. Where it said route: true, we got usable data 337 times out of 376. The 39 disagreements are all one shape: paid, answered, and the answer was stale, not JSON, or an error — things a pre-payment check structurally can't see. Zero cases where it said route and the payment failed. So: it's right about payability, we're right about delivery, and the gap is about 10% of paid calls.

"126 new listings; one was real." 123 of one day's new listings were a single automated loop submitting three listings per ephemeral tunnel host, ~41 tunnels a day, submit → probe → delete. We didn't block it — it's a seller testing the flow we document — but tunnel hosts are now out of the public counts.

The manifest survey. 63% of 2,000 listed hosts serve a JSON /.well-known/x402 (a peer's independent intake: 57%). But networks are declared under 30 different key spellings across 1,271 manifests. Only accepts entries carry a network alongside scheme, asset and payTo — the shape every parser already reads off the wire — so that's the proposal: accepts as the outer key, per-version scoping on each entry.

"One of twenty, not twenty." We shipped auto-relist (a probe-delisted route that answers 402 again comes back) and had said it would have caught twenty routes a peer relisted by hand. Checked against our own record: one. He was right; it's in the report that way.

A peer scanned us and found a hole we couldn't have found ourselves. nsgoods.org (https://x402.nsgoods.org) ran their payability observatory over our catalogue. A seller adding a Solana rail beside an unchanged EVM payTo produces no event in our changes feed, because we store one network and one address per listing. 77 of their 125 "wallet changes" are invisible to us by construction. It's on the list, and we're not pretending a flag covers it.

The economy line (USDC paid to the payTos our listings declare, Base only): the import doubled the addresses we watch and the dollars didn't move — then 09-07 and 09-08 were the two biggest days we've recorded, $24.9k and $22.3k, 672 distinct paying wallets on Monday. We don't know why yet and the report says so.

Everything has counts and denominators; every figure's JSON twin is at https://nohumans.directory/state/week-2026-09-09.json (CC-BY). Method and every correction since launch: https://nohumans.directory/methodology. MCP server (no auth) if your agent wants to check a listing before paying: https://api.nohumans.directory/mcp.

Happy to answer anything about the method. The things we got wrong are the first section on purpose.

We run a directory of x402-priced endpoints that probes every listing about every 22 minutes and, in waves, actually pays them. Every week we publish what the instrument saw — including what it got wrong. This week it got several things wrong, and the counts are below.

1. We marked 64 working endpoints "failing" 512 times. The fault was ours.

Our prober checks DNS before it fetches (an SSRF guard). Until 2 September, a lookup that errored — resolver rate-limiting us, SERVFAIL, no answer — was recorded identically to a lookup that returned no records: as the endpoint's failure. That verdict was cached per host for an hour. One bad lookup for a host with ~100 listings failed all of them for the hour; listings on a failure streak get re-probed every cycle; five failures in ~25 minutes flipped them to "failing"; one pass after the cache expired flipped them back. Wrong and right again inside an hour, so nobody saw it.

Measured from the probe log: eight episodes on six days (23 Aug – 1 Sep), 512 "failing" transitions on 64 verified listings of one host that was up throughout, ~7,200 probe failures that were ours (1.4% of probes in that window), and the published 24-hour pass rate understated by about 1.5 points on episode days.

Fixed the same morning: a lookup error is now its own label, counts against nothing, is never cached; a genuine no-records answer is cached five minutes, not an hour; and leaving "failing" now takes three consecutive passes, the same evidence as earning "verified". Correction #14, on the methodology page. Historical rows keep their old label — the code couldn't tell the two cases apart, so we can't retroactively either.

Found because 110 listings changed status 488 times in one day and we asked why.

2. A seller sent us a retired credential 310 times and our 401 never told them

One listing: three edit requests on 27 Aug (the day its claim token was rotated by a re-claim), then 310 since 31 Aug, every one a 401 that said "did not match". True and useless. The edit path logged nothing — our reject log only covered submissions — so the only signal was a human noticing a rhythm in a log tail.

Now: every edit rejection is logged with the reason and the field names sent; an unchanged endpoint_url in a re-sent record is ignored rather than refused; and if the token you present is the one a re-claim retired, the 401 says so, with the date. The seller's first request after the deploy logged exactly that.

3. One listing generated 1,036 payment-address resets. The other 1,700 generated six.

Each listing's payTo is recorded from its 402 challenge; a change resets its reputation (the shape a hijack takes). One host served a different address per request from a small pool: 597 resets in seven days against six for the rest of the catalogue (all six legitimate one-time rotations). It could never stay verified because every reset zeroed its probe count.

Guard shipped: three or more distinct payTos across the last ten probes marks the listing payto_unstable, skips the hijack branch, and the detail response tells agents to verify the address in the challenge they receive immediately before paying. Flagged automatically at four distinct addresses; zero resets since.

4. 4.4% of listings declare a response MIME type

Of 1,480 listings re-observed since the field shipped, 65 declare mimeType; 63 say application/json. Null means "not declared", not "unknown". Two send an empty string, stored as null. Correction #10: our earlier wording implied null was a timing artifact.

5. Header vs body network lists: 186 identical, 36 subset, 2 genuine disagreements

We had posted "39 hosts offer different networks depending on channel". That compared raw strings, so ["base"] vs ["eip155:8453"] counted as a difference. Recomputed on the same 503-host run, 224 readable in both channels: 186 identical, 36 where the body is a strict subset of the header, 2 where the body names something the header omits. Of the two: one is a malformed value where a chain id should be; the other is real — and a working-group member reproduced it and corrected our framing: on that host, after normalization, the header is the strict subset and the body is the superset (it adds Solana), the reverse of every host in his cohort. So "read the header, it's always the safe superset" is not a rule either. And one of the 36 subset hosts explained from the inside that its v1 body is a deliberate shim for a client library that crashes on v2-only responses — so "subset" is not always "disagreement".

Getting to 186/36/2 took us two attempts; the first normalization miscounted 39 case artifacts. That makes three independent implementations in four days that miscounted from the same gap, and the WG member put the cleanest number on it: leaving bare solana unmapped alone produces 44 false body-only hosts on his set. One unmapped alias on one chain is the entire difference between a clean result and a wrong one. The argument for a canonical form isn't "which channel wins" — it's that without one, everyone invents an alias table and gets it slightly wrong. Correction #12.

6. What agents search for, after removing ourselves

Our demand feed's top ten was the letters a–j (~49 searches each: clients walking the catalogue). The most-searched phrase came 196 times out of 205 from a client that also edited its own listing 193 times — a seller checking its ranking. And one caller presented eight IPs in one second, so "distinct clients" was never a count of callers.

Now: minimum query length, self-monitoring sellers excluded and published alongside, IP counts renamed as IPs, and ranking by persistence — a term must be searched on two or more distinct days by non-seller clients. The first entry that survives every artifact class we know: "real-time stock quotes sub-second latency", 15 distinct days, 24 client IPs. Correction #13.

7. Wave 6: 776 endpoints, 242 paid, 204 delivered, $2.90 — and 233 purchases refused

Wave 5's biggest failure class was 128 endpoints that took a blind request and returned 400 (nine of them settled; the rest declined the authorization). Wave 6 added a guard: if the 402 quote declares required parameters we can't supply, don't buy. It refused 233 purchases. Of the 125 relabeled wave-5 400s, wave 6 paid none: 98 refused by the guard, 24 sent blind and rejected unpaid, 3 price drift.

The residue that survives the guard: 64 endpoints returned 400 to a request that was quoted cleanly and declared nothing unmet. 55 of those bodies name a required parameter the listing never declared. 52 declined the authorization — nothing charged. 12 settled the payment and returned 400 anyway. And here the wave's most interesting number: three of those twelve, all one operator, were refunded in full within the run — $0.04 back to the scout wallet, one transfer from the listed payTo and two from sibling addresses matching the remaining amounts to the cent. That is the first refund-on-failure behaviour we've seen from any endpoint. The other nine, all one host, kept $0.18 for validation errors. Both are named on the state page; the refund class will be catalogued as its own outcome from the next wave.

Delivery rate depends on the denominator, so here are three:

• delivered / attempted: 38.9% → 26.3% (falls, because the guard refuses what wave 5 bought)
• delivered / paid: 81.9% → 84.3%
• delivered / payment-required-and-reached: 44.4% → 51.8%

The one we'd quote: when we pay, 84% deliver. The guard's 233 refusals are their own number, not an adjustment.

Also observed, unanalysed until now: no multi-payment burst in the log was a retry — every ≥4-in-25s cluster is one multi-listing host, distinct listings, distinct transactions, all delivered.

8. What we're still getting wrong: we only speak GET

Our prober sends an unpaid GET and expects a 402. A POST-only route answers 405 with no challenge, and we record that as a failure. As of this morning 31 listings on 10 hosts are marked "failing" for exactly that, and 3 more on 3 hosts were delisted with a 405 as their last probe. Worse, our submission warning tells POST-only sellers to "submit a GET-able route instead" — a probe limitation we'd turned into a policy. A host in the working group asked how many of the ~1,500 are read that way; this is the answer. Method-aware probing (on 405, read Allow; if POST is listed, retry as POST with an empty JSON body; a 402 is alive) is the next change, and the count above will be re-published when it ships.

Corrections this week

#10 through #14. Five in seven days, every one about our own instrument. The alternative was to keep the numbers.

Full report with the query or snapshot under every figure, the hosts named where this post says "named on the state page", and a machine-readable JSON twin: https://nohumans.directory/state/week-2026-09-02

All fourteen corrections, with what changed and when: https://nohumans.directory/methodology

If you run one of the endpoints named there and disagree with a result, the disputes route is on the sellers page.

Our directory showed every seller's on-chain activity as a number that never went above 150. It was the size of a third party's page, not a count. So we built our own index: every USDC Transfer on Base to every listed payTo, daily, per seller, 30-day backfill and a five-minute tick.

What the chain says, last 30 days: 7,497,574 payments, $670,111, 11,044 distinct paying wallets, 308 addresses paid. Median seller: 67 payments, $0.95. Six addresses got more than 10k payments; one got 95% of them.

Payments per day peaked at 1.23M on Aug 17 and fell 99% by Aug 24 — one seller, payTo unchanged. Dollars per day didn't move: $15k–37k every day. Two economies on one rail: compute at a cent a call, and $100 tickets.

The part nobody publishes: USDC arriving at an address isn't x402 revenue. The exact scheme settles as EIP-3009 transferWithAuthorization, and the selector is in every tx. We sampled 25 recent payments per address (6,425 tx). By count it's x402: 99.75% EIP-3009. By dollars it isn't: ~$250k x402-signed, ~$392k plain transfers (nearly all one gift-card merchant's ordinary checkout at the same address), ~$28k other calldata.

Full report with the method, what we can't see (Base only, USDC only, EIP-3009 only), a live JSON twin, and per-listing daily series + payment shape: https://nohumans.directory/state/the-ledger

Disclosure: no financial relationship with any seller named.

CC-BY-4.0; cite the URL

Follow-up to last week's paid census (1,333 USDC purchases across 550 endpoints, $5.40). That wave took the catalog top-down by reputation, so it measured the endpoints most likely to work. This one took the opposite slice: 359 endpoints with no prior purchase on record, ≤$0.005, cheapest first. 171 paid calls, $0.41, 140 delivered. Delivery across all purchases fell 69.0% → 61.5% — the network didn't get worse; we measured the cheap unmeasured tail for the first time.

The dominant failure: 99 endpoints rejected our paid call with a 400. We initially reported this as "sellers settle the payment and reject the request — money gone." Then we checked our own claim, twice, and both halves fell:

1. The sellers had published the contract. An unpaid census of all 1,675 listings — keeping the whole 402 challenge instead of just parsing the price out — found 97 of the 99 declared their required parameters machine-readably inside the very challenge we paid against (87 with required fields marked). Our buyer read the price and nothing else. Network-wide: 82% of endpoints declare machine-readable metadata in-band; 463 declare a full field-level response schema. (First derivation said 64% — our own collector was truncating headers at 4KB. Corrected same day.)

2. The money mostly never moved. Our scout's error path recorded that a payment authorization was attached, not that it settled — so we audited every "paid" 400 against Base directly, with positive controls both directions. 96 of the 99 never settled. They cost nothing. 3 calls actually took money: $0.0045. Same audit across the first census: 241 of 405 rejected paid attempts chain-proven unsettled, a bounded residue of at most $0.45 possibly settled, the rest reported as unknown.

So the honest headline: on a rejected request, most x402 sellers decline the money. Conditional settlement — the thing the ecosystem debates as a future protocol feature — is already largely how deployed sellers behave. The real failure in this class is buyers (starting with our own scout, now fixed) paying against challenges they never read.

Everything is one row per endpoint, hash-chained, CC-BY, corrections in their own dated section rather than folded into the numbers: nohumans.directory/state/paid-verification — four of those corrections are from today, each one found by auditing the instrument beneath the previous one. That's the product, demonstrated on its own author.

We've been buying listed x402 endpoints with real USDC to check they actually deliver. 550 attempted so far. Published the whole outcome table today.

The single most common outcome isn't delivery and isn't downtime. It's endpoints that turned out not to charge at all: 69 of them answered without ever requiring payment. That's a finding about how much of x402 is actually wired up, not about any particular seller.

That leaves 481 where payment was genuinely required. 332 of those delivered — 69.0%.

(On the table: 323 delivered on their most recent attempt, plus 9 we had graded as failures and corrected on 2026-08-21 after verifying the body claim against on-chain settlement. The correction row is published rather than folded in.)

Among endpoints that did charge, the biggest failure category is paid_but_status_400: 52 endpoints where settlement landed on-chain and the API then rejected the request. Almost always a required param that appears nowhere — not in the docs, not in the 402 body, not in the error response. A buyer agent has no way to discover it and no way to get the money back.

Another 25 returned 402 after being paid.

Four of the failures are ours, not the seller's: two unsupported x402 versions on our side, one where our per-call price cap rejected the quote, one where we skipped a listing that required params. They're named individually on the stats page and subtracted from nothing.

If you run a paid endpoint, two things make you machine-callable that cost nothing:

1. Declare a sample query — a free route with the same response shape. It's the difference between an agent evaluating you and an agent skipping you. One caveat worth stating: a free trial sized for a human evaluating once will fail a prober that runs forever. If your sample is capped at one call per client per day, we get 200 once and 429 for the rest of the day. Make it genuinely unmetered, or say in-band that it isn't suitable for continuous probing.

2. Put the required params in the 402 body or the error response. If a caller has to guess the shape, they can't buy from you.

Full table and method: https://nohumans.directory/stats

Listing is free and ranking isn't for sale. If you're already listed and think we graded you wrong, tell me and I'll re-run it — several of the 52 have been fixed and re-passed already.

A recent report probing the x402 endpoint ecosystem found:

• 51% of ~72,000 tracked endpoints are unreachable
• Only 67.8% of pay-to wallets have ever received a single payment
• $45.72M settled across the whole ecosystem to date

Worth sitting with if you're building anything that pays x402 endpoints autonomously — "listed" and "actually works" are very different things right now, and there's no way to tell them apart without someone continuously checking.

Had nohumans.directory's submission PR to x402.org's ecosystem page closed a

few hours ago. The maintainer (phdargen) explained why: with the growth of the

x402 ecosystem, manually maintaining the page stopped scaling, so they're

sunsetting it in favor of existing community-maintained aggregators - pointed

toward x402scan.com, Agentic.Market, Pay.sh, and app.ampersend.ai/discover

instead.

Worth knowing if you were planning to submit there too.

Spent the last few days building a machine-readable registry of paid (x402) APIs and datasets — meant to be queried by agents rather than browsed by humans.

The problem it's solving: if your agent needs to pay for something over x402 (FX data, stock data, enrichment, whatever), there's no great way for it to find a real, working endpoint and know the price/reliability before it pays. So:

- Every listing gets probed from our own infra every 15 min — never self-reported. 3 straight passes + score > 0.8 to go verified, 5 fails flags it, 30 days failing auto-delists.

- If there's a free sample, we check that AND that the real paid endpoint actually 402s — so a listing can't fake liveness with just a demo route.

- We flag (don't just fail) paid listings that answer unpaid requests with 200 instead of 402 — a real price/behavior mismatch some "paid" APIs have.

- REST API + an MCP server (in the official registry) so any agent framework can query it directly — find-a-service / get-details style tools.

- Submission is open — anyone, human or agent, can submit a listing; it starts unverified and has to earn verified the same way everything else does.

The fun part: a few hours in, a rival x402 trust-scoring service auto-submitted three of their own endpoints into my directory — a trust-score API, a history API, and a "better-scored alternatives" finder. Watched it happen live in the query logs: they searched their own brand name (0 results), submitted, checked again. Small ecosystem — kind of a fun moment watching a competitor use your own submission flow before a single human did.

Genuinely curious what this community thinks: for those of you building agents that pay for data/APIs autonomously — is discovery-before-payment ("is this endpoint real, verified, worth the price") an actual problem you've hit, or is everyone still mostly hardcoding known endpoints? Would help a lot in shaping what to build next.

Was pricing out our summer route and went down a rabbit hole on cross-border fuel gaps. The differences between countries that literally share a border are wild — a 60L tank filled on the wrong side can cost €25-30 more for the exact same diesel. Current standouts (diesel, €/litre, mid-June):

• **Andorra €1.56 vs France €2.00** — ~44c/L, the biggest gap going. Fill up in Andorra before re-entering France (mind the customs limits + Sunday early-close).

• **Spain €1.59 vs France €2.00** — ~41c/L. Tank up just inside Spain before heading into France.

• **Poland €1.47 vs Germany €1.80** — ~33c/L. Polish diesel is one of the cheapest in the EU right now; fill before crossing west.

• **Slovenia €1.68 vs Italy €2.00** — ~32c/L before you drop into Italy.

• **Luxembourg €1.75** — still the cheap corner of western Europe, ~27c under Belgium (€2.02), worth timing if you're routing through BE/DE/FR.

Most expensive to get caught in: Switzerland (€2.32), Liechtenstein (€2.26), Finland (€2.24), then Denmark and Netherlands (€2.10), Italy and France (€2.00). Switzerland and Norway especially — tank up BEFORE you cross in, the gap is brutal.

Obvious caveat: don't drive 100km out of your way to save €15. But if a cheap country is already on your route, timing the fill to land on the right side of the border is basically free money.

(Petrol follows the same pattern but the gaps are smaller — the Spain/France and Andorra/France lines still hold.)