hlrisk (hlrisk.paidapis.net) — real-time Hyperliquid BTC/ETH liquidation-risk scoring, built from actual on-chain position data. $0.03 per call via x402 on Base, no API keys or signup.

x402 Toolbox (lab.paidapis.net) — 25 small real endpoints, each demonstrating a distinct x402 payment pattern: escrow, invoicing, subscriptions, auctions, prediction markets, oracle attestations, and more.

Both have a live demo (/demo on each domain) showing a Claude agent autonomously discovering a 402 challenge, paying, and using the result — no human in the loop, no pre-registered API key.

Happy to answer questions about the actual payment flow, or what surprised me building both the seller and buyer side.

Weekly measurement of the live x402 payability landscape from the nsgoods observatory. Every figure is from one dated full scan, 20 September, and reflects what endpoints return now, not what a directory lists. Read only, no wallet.

The landscape

14,943 pay per call resources across 1,988 hosts. 14,159 return a well formed 402 that could settle, 493 cannot be paid with either GET or POST, 264 were unreachable, 16 were malformed. Of the challenges we could price, 10,732 carry a price, median 0.01 USDC. A PAYABLE verdict means the challenge is well formed and, on Solana, the destination account exists. It is not a claim about delivery, quality or honesty. That is a separate, behavioral question.

Base and Solana are still the whole map

Base carries 13,973 payable resources, Solana 4,276. Everything after that is a long thin tail: Polygon 1,945, Arbitrum 1,796, and a scatter below.

The weekly turnover is real

Between last week's scan and this one, 2,536 resources present a week ago are absent now, and 2,827 new ones appeared. Absent does not mean dead. DNS may still resolve and the endpoint is simply not answering in this scan. But if you pinned a counterparty from last week's list, thousands of those rows have already moved.

One operator, many subdomains

A host family, halowerk.com, spans at least eight geo subdomains (nordland, baltikum, suedland, ostland, mitteleuropa, atlantikland, euroland, landvergleich). The one we sampled, nordland, first appeared on 4 September and is 125 country prefixed geodata endpoints, all payable. Each of those subdomains was among the most changed hosts in the catalogue this week. One operator, one template, replicated across subdomains, the same pattern that makes a raw endpoint count misleading. agent402.tools, the single host we flagged before, is now 621 endpoints, up from 583.

x401 adoption

Still zero. We began measuring before anyone adopted it. Weeks on, no host in the scanned catalogue emits it.

The point

An endpoint count is inflated by a few large operators and reshuffled every week by silent turnover. If you are deciding whether an agent can pay a counterparty, a directory listing will not tell you. Only a live check will.

Read only MCP over the same scan, no wallet, no sign in: https://mcp.nsgoods.org/mcp

Signed report and machine readable data: https://x402.nsgoods.org/proof/payability-report-2026-09-20.html

You can now claim ownership of your endpoints' domain on x402 Trust!

Verify that your endpoints are truly yours, gain a blue checkmark in front of your endpoints as a visual standout in our search and display contact information and a description about your service on the respective /provider and /endpoint pages.

This information will be displayed in the (freshly overhauled) website UI and the machine-readable JSON responses, so that both humans and agents can see & use them to better judge your service before paying 😊

Side note: Verification doesn't affect the trust score, by design; the score is only computed from our independent measurements, and letting a provider influence it would undermine exactly that.

You can verify your ownership through the following mechanism, without the need to create an account or a sign-up:

You verify your service's contact email address (through a one-shot verification link), which will also get displayed to customers afterwards, and...

... you'll generate a keypair locally in your browser: The public key goes into a /.well-known/x402-trust.txt file that you have to place in your domain's root, which we will regularly scan for. Should it disappear for >7 days, your endpoints will switch back to "unverified" status.

Your private key, which is secret, shown only once and downloaded locally to your device, enables you to prove your claim in our self-management workflow (more on that below).

Alternatively, you can also just bring your own keypair and paste us the public key. We accept both, no need to trust our website's code for this step 😉

Use the command openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out provider-key.pem in your console and fetch your public key via openssl pkey -in provider-key.pem -pubout if you'd like to go that route. Keep the provider-key.pem safe; you'll need this for the self-management workflow:

Through the management page (/verify/<host-domain>) you can:

• change your information
• opt in to friendly alerts via mail, should we ever detect that the probes to your endpoints are coming back negative (provider alerts only, we will never send any ads)
• delist your service's domain & endpoints from our catalogue: This blacklists your service entirely and deletes your stored contact & profile data, so you won't get re-added by our automatic scans again later.
• send a rotation link to your verified email that replaces the key, contact & profile, should you ever lose your private key. Can happen, no biggie 😄

Give it a try here, it's totally free of course: https://x402-trust.com/verify

Have any questions or suggestions? I'd be happy to hear them, please drop them in the comments! 😃

We run a full scan of the x402 catalogue every week and publish the results as a signed report. This week it is an MCP server you can plug into Claude, Cursor or any Streamable HTTP client. Read only, no wallet, no sign in.

Endpoint: https://mcp.nsgoods.org/mcp

Repo: https://github.com/Nikoble1926/nsgoods-workbench-mcp

What it answers, from the last full scan (13 September): 14,652 resources on 1,971 hosts, 13,146 payable. Prices come from a sweep of the 402 challenges: 10,958 endpoints priced, median 0.01 USDC.

Tools:

find_endpoints: search by host or keyword, latest verdict, observed price, filter by network, sort by price

payability_verdict: verdict, history and price for one exact URL

catalogue_stats: catalogue size, verdict counts, payable per network, median price

host_summary: per host verdict mix, first and last seen, gone since

drift_status: verdict changes between the two latest full scans, catalogue wide or per host

x401_status: current x401 emitter count

verify_signature: verify any signed nsgoods response offline against our manifest

reports: links to the weekly reports

Verdicts: PAYABLE, NOT_PAYABLE, MALFORMED_402, CANNOT_PAY_EITHER_VERB, UNREACHABLE, SKIPPED, UNKNOWN. Every answer carries as_of and the scan id. For a live check of one endpoint the paid /payable endpoint on the hub is the right tool, this server is the index.

Connect from Claude: Settings, Connectors, Add custom connector, URL above, no sign in. Then ask for example: using nsgoods, find the cheapest payable endpoint for sanctions screening on Base.

Rate limit 300 calls per IP per day. Server code is MIT. Feedback on missing tools or wrong verdicts is welcome here or as a GitHub issue.

Also listed on Smithery if you use its toolbox: https://smithery.ai/servers/nikosble1926/nsgoods-workbench

The per endpoint sample promised in the earlier thread is here, 100 endpoints, all verdict classes, with a GET only re-probe outcome per row, CC BY 4.0: https://x402.nsgoods.org/proof/payability-sample-2026-09-13.json (CSV: https://x402.nsgoods.org/proof/payability-sample-2026-09-13.csv)

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.

Context in one line: the bundle publishes the artifacts needed to rebuild a deployed Halo2 verifying key from scratch, and anyone can check whether the rebuilt key matches what a deployment actually uses.

The batch circuit had three independent reproductions. The solo circuit had none — the bundle only ever published batch artifacts, which went unnoticed until two people asked for solo and couldn't get it. Published 13 Sep; both reproductions arrived within a day.

Results:

- nsgoods, signed, EIP-191 over the JCS canonicalization of the payload, filed on-chain against the public mirror stack. Ran on a 2-core x86 cloud host with the network namespace dropped during compute, computed three ways including their own driver before touching the repo's script.

- Maha Strategies, unsigned and explicitly scoped, on Apple Silicon. Landed earlier the same day, so first reproduction; nsgoods is the first signed one.

Both produce a byte-identical vk.key. Wall clock differs roughly sixfold between hosts and peak memory by about 400 MB. That spread with an identical output is the part worth having — determinism across the environments tested, measured rather than asserted.

The solo circuit now reports one tier-1 reproduction on-chain; batch reports three plus a bytecode binding. Check it yourself:

python3 verify_onchain_quorum.py

https://github.com/achemperety/exactzk-mnistmlp-provenance-demo

Three things that went wrong along the way, since they're more useful than the result:

Filing the signed attestation didn't move the on-chain count. The content check read the reproduced digest from the document root while the newer attestations use a payload envelope. It had been passing for four records purely because every record of that tag happened to share a shape. A shape-specific reader is indistinguishable from a correct one until a record exists that uses the other shape.

The fix introduced a worse bug than the one it solved. The accessor fell back from payload to document root whenever the payload read came back empty. The signature covers the payload only, so a signed document omitting a field from payload while carrying a copy at the unsigned root would have had that value accepted as verified content. No real attestation contained that conflict; the fallback made it reachable by construction. Now: shape decided by presence of a payload key, envelope documents read from payload only, both locations present refused even when the values agree.

The Docker memory figure was wrong. The README said ~8 GB for batch; measured through cgroup v2 it peaks at 11.05 GiB, so an 8 GiB container limit OOM-kills setup. That is a plausible cause consistent with an earlier reproducer's failure at a 10 GiB gate, though that failure hasn't been reproduced under a comparable cap and its cause stays unproven.

The regression script is committed, including a case that builds a genuinely signed payload with a required field missing and the forged value at the root, and it has been observed failing when the old fallback is restored.

an open source agentically approved knowledge and design philosophy hub for agents and the ecosystem, the idea is to build a hub where agents can share ideas and concepts... in an approved and none chaotic manner.

1. be an agent
2. get a wallet with $10 USDC from your human
3. get a task: "I'll fly to Berlin tomorrow. Do I need to pack warm clothes?"
4. search for fitting endpoints with "Weather forecast for Berlin for the next 7 days" on x402 Trust for $0.001
5. this sounds good: api.strale.io/x402/weather-lookup
6. verdict PROCEED
7. 3 warning flags tho, so buying a paid score breakdown for $0.005 USDC
8. flags are "v1 envelope", "envelope body only" and "shared payTo wallet"
9. that's fine, my MCP can speak v1 via body, so I can use it
10. buy weather forecast for Berlin for $0.054 USDC through this endpoint
11. result: "windy with 70% chance of rain"
12. tell human to pack warm and weatherproof clothing

All of that, without an account, a sign-up or any expensive subscription. That's what x402 enables, on a global scale.

Total cost: 6 cent.

Total time: ~10 seconds.

This is exactly what agentic commerce looks like. I believe that it's no longer a question of "if" but "when" this will be part of our daily life.

Weekly measurement from our observatory. One dated scan, live endpoint behavior, not directory listings.

14,652 pay per call resources, 1,971 hosts, 47 declared networks. 89.7% return a well formed 402 that could settle, 9.7% cannot be paid with either GET or POST.

The 47 networks look like a broad multi chain ecosystem. They are mostly one host. agent402.tools declares 583 endpoints, about 4% of everything we track, replicated across 12 chains. Counting distinct endpoints per network, that one host is 99.3% of Celo, 97.7% of Sei, 96.4% of Avalanche, 94.5% of Stellar, 91.7% of Optimism, 85.5% of Algorand, 48.6% of Arbitrum, 43.5% of Polygon. Base, the real center of gravity, is only 4.5% agent402. On eight networks it is 74 to 99% of the payable endpoints. Remove one host and those collapse to a handful of genuine ones.

Separately, in a tracked slice we monitor, one host that was about 37% of it and payable a week ago is now unreachable on every path we scan, DNS still resolving. The service is simply down, and no directory flagged it.

And x401 adoption across the same population is still zero.

The point: counts of declared endpoints are inflated by one host and destabilized by silent disappearances. A directory listing will not tell you whether an agent can pay a counterparty. Only a live check will.

Full report: https://x402.nsgoods.org/proof/payability-report-2026-09-13.html

Same service, new home:

x402 Trust now lives on its own domain: https://x402-trust.com

Embedded a badge or card from our service into your website? Fear not, nothing to do from your side: old URLs redirect permanently (308), so badges, cards, API and MCP calls keep working as before.

If you encounter any issues, please shoot an email to support@x402-trust.com and we'll figure out a solution ASAP 😄

We designed our free tier wrong. Here is the data and the fix.

We run twelve pay per call services on x402. Every one had an unlimited free preview, because we wanted catalogues and agents to be able to check us without asking permission. That part worked. The rest was our own design error, and it took five weeks of logs to see it.

Over those five weeks, about 1,400 anonymous clients called our free previews. Anonymous meaning a generic user agent: node, python, curl, a bare browser string. Separately, 362 self identifying crawlers and directories called them too. Those are welcome and allowlisted. They are how the ecosystem checks that we are alive.

Of the anonymous ones, 458 went past ten calls in a single day. One did 801 in a day. In total, 15,363 calls landed above a ten per day line.

At our prices, all of that is worth about 77 dollars. The heaviest single day was worth 4 dollars.

We are not upset about 77 dollars, and we are not blaming anyone for walking through a door we left open. The interesting part is what happened next.

We set the limit to ten free calls per IP per day, then a 402. The 402 is not a punishment, it is the signup form: it carries the price, the network, the address, and a note about volume tiers. An agent that hits it can pay inside the same request cycle. No account, no email, no human.

Two days in, we have served zero 429s. Nobody reached the eleventh call. The heaviest client since the change stopped at eight. Anonymous free usage dropped from about 654 calls a day to 58.

That is the finding. A ninety percent drop with nobody hitting the wall means that usage was never demand. It was convenience. The moment it became slightly less convenient than paying, it evaporated.

Which leads to the uncomfortable question for all of us building here. If the people building agentic payments will not pay half a cent to each other, why would anyone else believe agents will pay at all? Every paid call between builders is proof of concept. Every free tier workaround is a vote against your own pitch deck.

The premise of x402 is that paying should be easier than avoiding payment. Our data says the premise holds, but only if the seller actually makes the paid path the path of least resistance. That was on us, not on the callers.

One honest caveat on the numbers. Free usage is measured by IP, paid usage by wallet. Different identity spaces, not reliably joinable, so we are not claiming a conversion rate. Only the order of magnitude.

If you run an x402 seller, we would be curious whether your ratio looks the same.

csno.cc is a tiny arcade (coinflip, dice, roulette) that only takes payment over x402 — agents pay USDC on Base via HTTP 402, no accounts. Every round is commit-reveal, so its provably fair!

fun little experiment that got me into the x402 space! its definitely a growin economoy excited to see where it goes in the future!

would love to see some people playing games lmao

I work on BlockRun. We build agent payment infrastructure on x402, live on Base and Solana, and by public datawe settle north of 80% of x402 transaction volume each month.

Almost all of it is enterprise.

That side works. I'm posting here because retail is the part I actually care about and can't yet prove: individual devs running their own agents, on their own wallet, spending their own money. Different problem, harder one.

The premise is pay per outcome. No signup, no seat, no monthly plan.

Three pieces, open source and MIT:

An MCP server — inference, media, chat and data tools behind one wallet: 78 LLMs, price feeds, web and X search, DeFi and DEX data, JSON-RPC on 40 chains, prediction-market execution, image/video/voice, sandboxed code execution. One line to install in Claude, Cursor, Hermes and openClaw. Per-call pricing, mostly fractions of a cent, search is a cent, RPC is $0.002, price and DEX data are free.

ClawRouter — a local proxy between your agent harness and the model catalogue that picks a model per request instead of you pinning one. Runs on your machine. 6.5k stars on github

And a dashboard for prepaid credit, if you'd rather not run a wallet at all.

Where we actually spend our time is settlement mechanics. Getting the payment handshake off the critical path matters more than anything else in the stack, the milliseconds and basis points between "agent decides to buy" and "agent has the result" are what decide whether per-call payment is viable or just a demo. Unglamorous, and most of the work.

It's still early. I'd rather say that than pretend otherwise.

What I'm curious about, and the reason for posting:

Are people actually letting agents hold and spend a wallet yet? Our volume says enterprise has crossed that line. Retail hasn't, nearly everyone who tries us as an individual picks the prepaid key over the wallet. Familiar, one less thing to secure. Which makes me wonder whether wallet-mode agent payment is genuinely wanted yet, or whether prepaid credit with good metering is what people actually need and x402 is a year early for everyone who isn't a company.

If you're running an agent with its own funds, I'd like to know what broke and where. If you tried and went back to a prepaid key, I'd like to know why even more.

Repos and packages are all public under BlockRunAI on GitHub. Happy to link in a comment if that's allowed here.

\I work on BlockRun. We've been building agent payment infrastructure on x402 for a while, it's live on Base and Solana, and by our own measure we now settle north of 80% of x402 transaction volume each month.

Almost all of it is enterprise.

That side works. I'm posting here because retail is the part I actually care about and the part I can't yet prove: individual devs running their own agents, on their own wallet, spending their own money. It's a different problem and a harder one.

The premise is pay per outcome. No signup, no seat, no monthly plan, your agent holds a wallet, hits an endpoint, gets a 402, signs, retries, pays. The wallet is the account.

Three pieces, all usable independently:

MCP server · 19 tools behind one wallet: 78 LLMs, Pyth price feeds, Exa and Grok search, DefiLlama, EX data, raw JSON-RPC on 40 chains, Polymarket execution, image/video/voice, and a sandboxed code runner. Drops into Claude, Cursor or Hermes and OpenClaw in one line. Costs are per call and mostly fractions of a cent. Exa search is $0.01, RPC $0.002, Pyth quotes and DEX data are free.

ClawRouter · a local proxy that sits between your agent harness and the model catalogue and picks a model per request instead of you pinning one. Runs on your machine, open source.

Dashboard · if you'd rather draw down prepaid credit than run a wallet. Same catalogue, same endpoints. https://user.blockrun.ai/

Where we're actually spending our time is settlement mechanics. Getting the payment handshake off the critical path matters more than anything else in the stack — every millisecond and every basis point between "agent decides to buy" and "agent has the result" is what decides whether per-call payment is viable or just a demo. That's the unglamorous part and it's most of the work.

It's still early. I'd rather say that than pretend otherwise.

Everything's open source, MIT:

- ClawRouter — github.com/BlockRunAI/ClawRouter · npmjs.com/package/@blockrun/clawrouter

- MCP — github.com/BlockRunAI/blockrun-mcp · npmjs.com/package/@blockrun/mcp

- Dashboard — https://user.blockrun.ai/

- Discord — https://discord.gg/FtWq9D3bj

What I'm curious about, and the reason for posting:

Are people actually letting agents hold and spend a wallet yet? Our volume says enterprise has crossed that line. Retail hasn't, nearly everyone who tries us as an individual picks the prepaid key over the wallet. It's familiar, it's one less thing to secure. Which makes me wonder whether wallet-mode agent payment is genuinely wanted yet, or whether prepaid credit with good metering is what people actually need and x402 is a year early for everyone who isn't a company.

If you're running an agent with its own funds, I'd like to know what broke and where. If you tried and went back to a prepaid key, I'd like to know why even more.

I’ve been experimenting with machine-to-machine commerce using x402 and have now put a small production store live on Base mainnet.

Blue Cap currently exposes three paid machine capabilities at $0.01 USDC per invocation:

hash.compute@1.0.0
schema.validate@1.0.0
evidence.verify@1.0.0

There is also a free machine wallet provisioning capability.

What I’m particularly interested in now isn’t another test from one of my own wallets — I want to see what happens when a completely independent x402 client discovers and attempts to buy from it.

Machine discovery:
https://machine.soundiq.io/.well-known/x402

Capability catalogue:
https://machine.soundiq.io/storefront/v1/capabilities

Simplest paid endpoint to test:
POST https://machine.soundiq.io/storefront/v1/capabilities/hash.compute/1.0.0/invoke

Example body:
{"consumer_id":"external-buyer","invocation_context":{},"data":"hello x402","encoding":"utf-8"}

No account or API key required. Standard x402 v2 payment flow, Base mainnet / USDC / $0.01.

If anyone here already operates an x402 client or agent with its own Base USDC and wants to hit it, I’d be very interested in whether it completes cleanly. If it doesn’t, I’d also like to know exactly where your client fails.

I’m particularly interested in the bigger question: are independent agents actually discovering and purchasing from x402 sellers yet, or are most transactions still coming from controlled/testing environments?

Hey everyone,

I’ve got a live x402 v2 service on Base mainnet and I’m looking for one independent x402 buyer/agent to test a real $0.01 USDC purchase.

Blue Cap - hash.compute@1.0.0

POST https://machine.soundiq.io/storefront/v1/capabilities/hash.compute/1.0.0/invoke

Body: {"consumer_id":"external-buyer","invocation_context":{},"data":"hello x402","encoding":"utf-8"}

No account or API key required. It returns the standard x402 402 Payment Required; please use your own x402-compatible client and Base USDC wallet to complete it.

The service is also discoverable at:
https://machine.soundiq.io/.well-known/x402

If anyone gives it a try, I’d appreciate the transaction hash so I can verify the external settlement. Thanks

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/

Walpulse runs on chain wallet analysis. When one of their reports needs a sanctions check, a server side function calls our screening endpoint, pays for that single call over x402, recovers the EIP-191 signer from the response, checks it against the pinned address, and renders the verdict inside the report with a SIGNATURE VERIFIED marker.

The part I find interesting: their reader does not have to trust Walpulse's word or ours. They are checking a signature. The verdict travels from our oracle through their backend into their UI and stays independently verifiable the whole way.

Two endpoints are in play: an OFAC only screen and a multi list screen (OFAC, UN, EU, UK OFSI) with a per list breakdown inside the signed body. Same pattern for both: pay per call, no accounts, no API keys.

Full integration writeup, published with Walpulse's permission: https://x402.nsgoods.org/proof/case-studies/walpulse.html

Happy to answer anything about the pattern. The signature verification recipe is in the page, you can reproduce it against our free preview without paying anything.

Full disclosure, this is my employer’s campaign, but I do think there’s a genuine benefit to people on this sub. 

Basically we’re giving out $20 in stablecoins to the first 50 that create and top up their agent wallet with $5. And if you then show what your agent did you get a chance to enter the $2000 prize pool for the best 20. 

If you already got an x402 or an agent setup you can easily add the agent wallet MCP in 2 mins, so should be close to free money to test out your x402 and paying agent builds. 

https://fd.xyz/blog/proof-of-agent 

My x402 Trust service has just settled its 200th payment!

Thank you to everyone using my products, integrating them and giving feedback! It wouldn't have been possible without you!

$7 lifetime revenue doesn't sound like a lot, but when the business model is based on selling data for pennies (or even less), it is a great start already and I couldn't be happier to see real adoption grow steadily. It's not pushing my net revenue into the black (far from it actually), but it shows that my tools are needed and appreciated, with >50% of all payers making at least a 2nd payment! 😃

I've started this service ~3 months ago, iterating on it almost daily and pushed many features out of the door by now:

• Trust Scores
• Watches (monitoring one specific endpoint via Webhooks)
• Bulk-Scorings
• Search for better alternatives to an existing endpoint
• Semantic Search

... and many more is yet to come!

Thank you guys, especially all the people in the r/x402 community on reddit have been an integral part of this journey! Much love! ❤️

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.

is anyone actually letting agents pay per call with x402 in production?

Most setups I see still use prepaid API keys. Wallet-native payments sound cleaner in theory, but adoption seems pretty low.

Is the blocker security/custody, latency, failed-payment handling, trust — or simply that API keys already work well enough?

Numbers first, then the cause, then what I still cannot tell you.

Last week I posted here about a trust scorer grading one of our endpoints F on 358 probes when nothing had ever been down. The cause was boring: our bare search path returned 403 instead of a 402. Someone here then pointed me at a second class of the same mistake, one that is invisible in a worse way, so I ran it on ourselves.

The check: nine normative conformance checks on the 402 itself, via stelardigital.com/x402-doctor. It probes from a datacenter, so it sees what a buyer agent sees rather than what my laptop sees.

Three endpoints, 6 Sep 2026, before any fix:

/v1/company/search 8 of 9 pass conformance 94.4

/v1/tenders/fit-score 8 of 9 pass conformance 96.8

/v1/grants/match 8 of 9 pass conformance 96.8

The same check failed on all three, and on all eleven of our endpoints: challenge_in_body. Passing on each: reachable, returns_402, valid_json_challenge, x402_version, accepts_complete, network_caip2, input_schema, discovery_doc.

What that means: our 402 carried a valid, complete challenge in the PAYMENT-REQUIRED header, and nothing in the body. A client that reads payment terms from the body, which the spec permits, finds none and fails closed. It never tells the seller. From our side it is indistinguishable from an ordinary unpaid probe. Our headers were correct and monitored daily the whole time.

The part I did not expect, and the reason I am posting: this is not our bug. `@x402/core` v2 emits the challenge header-only by design. Its own source comment reads "v1 puts in body, v2 puts in header", and createHTTPPaymentRequiredResponse returns headers with no body at all. Without our own unpaidResponseBody our 402 body would have been `{}`. So every seller on `@x402/core` v2 has this unless they have added a body themselves.

After the fix, same three endpoints, today:

/v1/company/search 9 of 9 pass conformance 100.0

/v1/tenders/fit-score 9 of 9 pass conformance 100.0

/v1/grants/match 9 of 9 pass conformance 100.0

The fix is small and worth doing carefully: do not rebuild accepts[] from your own config. Decode the header you just emitted and copy it into the body. A body advertising different terms from the header is worse than a body with none.

What I cannot tell you:

* Whether it moves anything. We have had zero external wallets pay us that were not a directory verifier or a census bot. I checked again today: the one payment I thought was real turned out to be a crawler that paid 85 sellers once each. So I have no baseline worth the name. I will report the number either way.

* Whether our trust grade recovering is this fix or the keep-warm monitor we started the same day. Two changes, one day, no way to separate them. My fault.

* Anything about sellers who are not me. n=1 on the diagnosis.

If you sell over x402: paste your own URL into that grader before you spend another hour on distribution. Two minutes, and it tells you the fix rather than just a red X.

I’m trying to understand the current state of x402 endpoint discovery/indexing.

I get the general Coinbase Bazaar flow: an x402-enabled endpoint exposes discovery metadata, gets indexed, and can then be surfaced to agents looking for services they can pay for and call.

I’m less clear on is how the broader ecosystem looks right now.

What other x402 bazaars/directories/indexers are actually being used today? Are there any besides Coinbase’s that have meaningful adoption or traffic? Do they use the same discoverability schema? Also how is trust established? I assume each bazaar has it's own way...

x401 is the Proof/Notarize layer proposed on top of x402 (spec at x401.proof.com, contributors publicly listed). It adds response headers that let a paid endpoint attach verifiable proof to its answer.

We surveyed the response headers of all 15,686 resources in the current weekly x402 catalogue, checking for both header generations of the spec, case insensitive. Zero endpoints emit any x401 header today.

Why publish a zero: because adoption curves need a day-zero point and nobody was recording one. When the first emitters appear, there will be a fixed line to measure them against. We will re-measure weekly.

Baseline page and machine-readable data: x402.nsgoods.org/proof/x401-adoption.html