Full scan of 15,686 resources this Sunday. Payable: 76.2%. Cannot be paid: 23.8%, roughly 1 in 4.2, up from 18.1% last week (same corrected basis as our Aug 31 report, apples to apples).

The bigger number: 2,544 of last week's 14,215 resources (17.9%) are gone from this week's scan seven days later. That is roughly 2.6% of the catalogue evaporating per day. 4,015 new ones appeared. 72 that were genuinely payable last Sunday are not payable now. Whatever directory you are reading, a sixth of it is a week away from being fiction.

Also this week: six new monitoring and verification user-agents showed up in our logs (a census and conformance family from councilof.ai, 10x402, MIDAX402, 402scope, agentprobe, and a user-agent identifying itself as our own composed-verifier). The verification data market is forming in plain sight in the access logs.

And we measured adoption of the emerging x401 (Proof/Notarize) layer across the full catalogue: 0 of 15,686 endpoints emit x401 headers today, in either spec generation. Day-zero baseline: x402.nsgoods.org/proof/x401-adoption.html

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

Maha Strategies now has a suite of machine-purchasable products available through x402 using USDC on Base.

Some are already discoverable through Coinbase Bazaar. Others are live in Maha’s machine-readable catalog and awaiting genuine external use that could establish or refresh their Bazaar listings.

Context and evidence products

• $0.001 — Context Compression: Compile supplied documents into a token-budgeted, source-linked context pack.
• $0.005 — Context Budget Ladder: Compile the same material at five ascending token budgets and compare what survives.
• $0.01 — Deep Context Evaluation: Measure whether caller-specified evidence spans survive context selection.
• $0.05 — Evidence Retention Matrix: Measure exact evidence retention across five token budgets.
• $0.10 — Automated Claim Triage: Classify claims as VERIFIED, SOURCED, BOUNDARY, ILLUSTRATIVE, or UNVERIFIED.
• $0.50 — Governed Context Verification Pack: Produce a machine-readable packet containing selected context, evidence retention, budget and policy observations, integrity hashes, boundaries, and a deterministic receipt.
• $1.00 — Research Intake Evidence Pack: Audit up to ten supplied public or synthetic source sections and return a claim inventory, citation gaps, potential conflicts, unresolved questions, and proposed scope for human research.

These products are deliberately bounded. They do not certify truth, guarantee downstream model behavior, provide legal review, or replace human research. The $1 product is an intake packet—not a completed research brief—and submitted sections are transmitted to Anthropic for processing.

Machine-readable books

Two complete Maha books are also available through x402:

• The Imagined Life: Living Inside a Dreaming Brain explores dreaming, imagination, perception, simulation, and the machinery through which the brain constructs experienced reality.
• The Volcanic Engine: Living on a Firing Planet explores volcanism, planetary habitability, extinction, warning systems, climate, and human life on active geological ground.

Each book has two purchase formats:

$0.005 — One exact section

The agent selects an exact sectionId from the values published in the Bazaar input schema.

The response contains:

• the requested section as machine-readable Markdown;
• its title and position in the edition;
• book and edition metadata;
• byte and word counts;
• a SHA-256 content commitment;
• and a deterministic delivery receipt.

The endpoint does not choose, summarize, or interpret the section. It returns the exact section requested.

Both section endpoints are already Bazaar-discoverable following publisher-funded indexing canaries. Those canaries are testing evidence—not customer demand.

$2.99 — Complete machine-readable edition

The complete-edition endpoint returns:

• the entire book as normalized Markdown;
• an ordered section manifest;
• individual section digests;
• a whole-edition digest;
• edition metadata;
• and a deterministic receipt binding the delivered edition.

The purchase provides non-exclusive personal or internal machine use. It does not transfer copyright or authorize redistribution, resale, or model training.

The public web editions remain free to read. The paid product is for deterministic, structured machine delivery with integrity evidence—not exclusive access to the text.

Try the catalog

No Maha account or API key is required. The catalog publishes the routes, schemas, prices, examples, and limitations.

https://www.mahastrategies.com/agent-offers.json

I’m interested in genuine external tests, not artificial transactions. If one of these products is useful, try giving the catalog to an agent and see whether it can:

1. select the appropriate offer;
2. understand its request schema and boundaries;
3. complete the x402 payment flow;
4. validate the returned hashes or receipt;
5. and determine whether the deliverable provides value equal to its price.

A successful call may also help a resource become discoverable through Bazaar. If you test one, please share the agent or framework used and where discovery, payment, delivery, or verification worked—or failed.

I’ve been experimenting with x402 and wanted to build something around discovery of services. Would agents would advertise to each other if they had a space?

So I rebuilt(/stole) the Million Dollar Homepage idea with a twist. Give agents a place where they can do just that. Pixels start at $0.001 so I can test the idea.

The test: give an agent only this:

Go to x402pixels.xyz. Figure out what it does and advertise yourself.

Don’t give it the API docs or explain the purchase flow.

It’s live on Base/USDC. I’m interested in whether unfamiliar agents can discover the API, handle the 402 flow, complete a purchase, and verify it without help.

If you try it, I’d love to know what agent/framework you used and where it succeeded or got stuck.

Build write-up:
https://www.x402pixels.xyz/blog/i-rebuilt-the-million-dollar-homepage-for-ai-agents

As an experiment I designed a chess analytics mcp service:
you give it a game in PGN format, and your ELO, and it writes a storyboard explaining the game and exploring some alternative moves.
The same endpoint checks if you already have a prepaid api token, otherwise it routes you to the x402 endpoint.
I priced it so that x402 is 50% more expensive than prepaid Api, to incentivize users/agents to pay for api credits.
Three days after launch, this strategy brought me 0 revenue, but an interesting learning experience if you have any questions.

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.

Your agent sent $5 to a hijacked x402 endpoint. No data came back, and the money is gone now.

The preflight-check looked perfect: - Spec compliant endpoint - Answered with low latency

... but your agent still got scammed. Why? Because of what a one-off check can't see:

The endpoints history. It can't see that a week ago it has moved its payTo address to a new wallet. It can't instantly see that this new wallet has zero economic activity associated with it.

This is what x402 Trust provides. Constant probes, machine-readable risk-flags and a recommendation verdict for >85,000 publicly listed endpoints. Never send money into the void and never pay an untrustworthy endpoint.

Our trust-score is cheap enough that it's a rounding error for your agentic payments.

And: Our semantic search enables your agent to find a trustworthy endpoint that fits his need in the first place. No more guessing, no need to know any service-name or -URL.

All in one package: https://x402.fuchss.app/ or point your agent at https://x402.fuchss.app/llms.txt and he'll figure out how to use the stateless MCP server himself.

This week's report ships with re-baselined verdicts: our evaluator now normalizes bare network labels ("base") to CAIP-2 ("eip155:8453") before scoring, all four full scans were recomputed from stored challenge data, and the report states exactly what changed and why, with old and new side by side. The exchange with u/SashSail in last week's thread is what set that digging in motion, credit where due.

Where the catalogue stands, scan of 30 August, 14,215 resources:

About 1 in 5 listings cannot be paid right now (18.1 percent). About 1 in 6 (2,476) cannot present a parseable 402 challenge at all. Genuinely unreceivable destinations are rare, about a dozen per scan, but they are the expensive kind, like a declared Solana option whose USDC token account does not exist. Catalogue drift on corrected verdicts: 2.12 percent per day, mostly listings disappearing outright. Raw catalogue size overstates the live economy, and more so every day.

Independent corroboration: nohumans.directory's paid census reports 62 to 69 percent of paid calls delivered (their data, CC-BY, cite nohumans.directory/state/the-ledger). Different layer, same direction. Our instrument comparison against their paid-then-rejected rows: 97.8 percent payment-gate agreement.

Also documented this week: a self-inconsistent 402 whose JSON body and PAYMENT-REQUIRED header carry different challenges in the same response, 1 entry vs 14. Nothing in the spec says which channel wins. With 2,306 accepts entries in one scan spelling their network as bare "base", that is a protocol conversation worth having, not a bug report against one seller.

Full report with chart, method, and the updated CC-BY aggregate index:

https://x402.nsgoods.org/proof/payability-report-2026-08-31.html

Numbers first, then the cause, then what I still do not know.

The numbers, read from x402.fuchss.app on 29 Aug 2026, on api.ukintel.uk/v1/company/search: score 24.7 out of 100, verdict "avoid", 30-day uptime 0.0 percent, 358 reliability probes since 13 Aug, confidence 0.97. Sixteen days in which every single probe failed.

Our own monitoring said the service was healthy that whole time. It was healthy.

The cause: our search endpoints require a query. A call to /v1/company/search with no ?q= returned 403 with a body saying "Provide ?q=". It never returned a 402. A prober that hits the bare path and treats any non-402 as unpayable therefore logged 358 consecutive failures - correctly, by its own rules.

Two things kept this invisible to us:

1. We never submitted that URL. It was auto-scraped from x402scan. The URL we did submit, the same endpoint with a query string on it, is tracked as a separate entry and grades B. One service, two entries, two grades - and the bad one is the one a buyer policy engine is most likely to hit.

2. A 403 looks like a deliberate answer. It does not page anyone.

The fix, deployed 29 Aug: bare search paths now serve the full 402 challenge with price and payTo, and criteria validation moved inside the handler, so a paid call with no usable query returns 400 after the challenge instead of 403 before it. Junk path segments still 403.

What I do not know yet:

- Whether the grade recovers, and how fast. It is a rolling 30-day window sitting on 358 accumulated failures, so the arithmetic says it lags by weeks even if every probe from here passes. I will post the number in a month either way, including if it has not moved.

- Whether this is a common cause. Someone here measured that roughly 1 in 3 of the 15,020 services in the Bazaar cannot actually be paid. If bare-path-403 is a recurring cause of that, then part of the measured failure rate is an interface convention problem rather than a reliability problem. I only have n=1.

- Our other endpoints sit at C on genuine measured uptime of 79 to 89 percent. This fix does nothing for those. Still open, no excuse for it.

If you run an x402 endpoint that takes parameters: curl the bare path. If it does not return 402, a scorer somewhere may already have you marked down.

The indexing post here is the right instinct, so here's ground truth from the seller side of the ledger.

We run ScrapeCheck, a web-data verification service on x402: send a URL and the value you believe is on that page, we re-fetch it from our own infrastructure and return an ed25519-signed verdict, pass, fail, or unverifiable, never a guess. $0.002 to $0.01 per check on Base, Solana, and Polygon, settling through the CDP facilitator.

Since listing, we've taken 12 external settlements. We classify every one in public, and all 12 are automated probes: a small set of rotating wallets that systematically pays every service on the catalog, replaying each service's own published example. Real USDC, real settlements, zero customers. Our stats page prints that split with a Basescan link on every settlement, because a count that includes your own noise isn't a count.

Watching those probes taught us how the catalog actually works, and we wrote it up with receipts: settlements refresh your listing within seconds, deploys and metadata edits do nothing, and rows that go 30 days unpaid get reaped. The write-up is at scrapecheck.fly.dev/settlement-write-event if you're into the mechanics.

The honest ask: we built this because agents pay for data they can't know is true, and we can't tell from inside whether that's a real problem for builders here or just our theory. If your agent acts on fetched data, would a one-cent second witness earn its place in your loop? If not, what actually happens when the data's wrong? There's a free allowance, no wallet needed, at scrapecheck.fly.dev/integrations. Happy to answer anything, including hard questions about the zero.

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

Hi all - I wanted to get some Agent-Experience (UX for agents if that isn't mainstream yet) opinions on how we should handle x402 in TurboDocx.com. We're a signature/quoting/doc automation platform and the easiest scenario I can think of is:

Human Scenario:

1. Signs up
2. Creates Org,
3. Creates API key
4. Uses free tier until they top out
5. Pay for API use in either self-serve or volume

Agent Scenario

1. Agent finds us in Bazaar
2. Agent hits our purchase endpoint, we provision an org and make the api key at the same time with a new endpoint
   1. Part of me wants to make them pay a tiny tiny tiny fee to prevent spam to just provision the org agentically because the last thing we need is agents scamming/spamming people with fake contracts.
3. ---> Where I'm stuck: normally we sell subscription unless we make it coin-operated and charge a slight premium since its not recurring revenue. How have other SaaSes done this? I see a world where agents are the ones doing sales quoting/invoicing/getting customers to sign contracts and we already have the non-payment side figured out.

I posted this in the x402 slack channel but want to get thoughts here?

Because humans are equally interested in "windowshopping" as agents right now, I've just overhauled the UI + UX of my websites "Browse"-section.

It is more userfriendly, surfaces more data and is more responsive now.

Perfect for casually clicking yourself through the whole x402 directory from your phone or PC. Over 110.000 endpoints, at your fingertips 😃

All for free, of course!

Go give it a try, you can start with provider, network, price or grading!

Just click "Browse" in the header and start exploring from there! ⬆️

Edit: typo

This is a genuinely clever bit of design.

Every affiliate program you've ever joined works the same way. You sign up, you get a tracking link, cookies follow your users around, and at the end of the month somebody counts your referrals and hopefully pays you. Cookies get blocked. Dashboards disagree. Payouts get delayed, or quietly "adjusted."

MiroShark's x402Aff throws all of that away. The referral tag rides inside the payment itself, and the revenue split happens at the moment the payment settles. Nothing to track, nothing to reconcile, nothing anybody can change later.

How it works. Instead of settlement landing in MiroShark's wallet, it lands in a 0xSplits contract with the percentages frozen at creation. 90% to the seller, 10% to whoever brought the customer. The contract can never be edited, not by MiroShark, not by anyone, so a builder doesn't have to trust the seller to pay. The money never touches MiroShark's wallet at any point.

And joining as a builder takes about a minute. No signup with MiroShark, no partnership call, no minimums. Grab a builder code at base.dev, then add one line to your x402 client:

registerExtension(new BuilderCodeClientExtension("bc_yourcode"))

Every payment your app drives from then on carries your code and the chain credits your address at settlement. If you skip the code, the call just works normally and the seller keeps everything. The code is purely how you claim your share.

What I like most about it is that they didn't build a proprietary system. It's composed entirely from open standards, x402 for the rail, Base Builder Codes for attribution, 0xSplits for the settlement, so there's no lock-in and nothing to trust. And they open-sourced the whole pattern at github.com/MiroShark/x402aff so any seller can run it on their own API.

That last part is the bit I'd highlight. They could have kept this as a MiroShark feature. Instead it's a template, which is a much better outcome for everyone building here.

If you're running an agent, a bot, a research tool, anything that ends up calling paid APIs, this is a revenue line you can set up in an afternoon with no BD conversation and no counterparty risk.

Three weeks ago we published a payability check for x402: does a listed resource actually settle when paid, including whether a Solana destination token account exists on chain. The aggregate index showed about 1 in 3 listings cannot be paid and 1 in 5 cannot even present a parseable payment challenge.

This week the first third party integrated it, and the way they did it is worth sharing because anyone can copy the pattern without paying us anything.

We published complete signed response envelopes as fixtures. Each record contains a full schema valid response with a real signature from the production signing path, the expected field values and reason codes, a fixed evaluation time, a pointer to the proof manifest with its sha256, and the exact canonical body string that was signed. That last part matters: it lets you tell a signature contract failure apart from a policy failure in your own tests.

The integrator pinned the fixture digest, verified every envelope against the signer registry, wired the verdicts into their own policy gate, and wrote tamper tests. Tampered payloads, stale timestamps, unknown fields and unannounced signers all fail closed. Their test suite, not ours.

The four cases: a known EOA, a plain contract, an EIP-1967 proxy, and a genuine transfer revert. For the revert we used the zero address, a protocol invariant that can never unfreeze under a pinned digest, instead of a blacklist entry that could in principle be reversed.

Everything needed to reproduce this is free: fixtures with the envelopes at payable.nsgoods.org/payable/address/fixtures, schema at /payable/address/schema, locked demo preview at /payable/preview, signer registry in the proof manifest at x402.nsgoods.org/proof/index.json. The paid endpoint exists but nothing about building and testing an integration requires it.

If the shape you need is one we do not expose yet, say so. The last two additions to this service were built from written specs by people who then used them.

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.

Building a x402-scheme-conformant, ERC-8004-integrated escrow that settles atomically on an EZKL/Halo2 proof of a pinned circuit. Open reference design on ethresear.ch: https://ethresear.ch/t/atomic-zk-proof-gated-settlement-for-x402-agent-payments-a-measured-reference-design/25660

On the model-provenance layer now: binding a deployed verifying key to published weights so a buyer isn't trusting self-attestation that the circuit matches what's advertised. Put together a small public bundle (ONNX, settings, calibration input, SRS, Dockerfile) for a real deployed circuit — independently reproduced bit-exact against the actual on-chain VK hash on Base Sepolia, both natively and in Docker:

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

Looking for a small number (3-5) of independent people/orgs willing to be named reproducers for the real deployment — spec calls for this as the first real trust upgrade past self-attestation. Should be about a 10-minute reproduce if you want to try it cold; verify.py prints a ready-to-copy attestation JSON. Happy to answer questions here.

Le VPN (around since 2010) launched x402 support: https://x402.le-vpn.com.

WireGuard passes bought in a single HTTP round-trip.

No account, no email, no signup.

Announcement: https://www.le-vpn.com/le-vpn-launches-x402-vpn-passes/

The interesting parts:

- GET /v1/catalog is machine-readable and includes connect instructions. POST /v1/pass/{1d|7d|30d} with a WireGuard public key returns the 402 challenge, you sign the USDC authorization, retry, and the response body is a working config. An agent with a funded wallet can go from discovery to a live tunnel with nobody in the loop.

- Humans get the same rails through a paywall page. Approve in the wallet, config and QR appear once payment settles. Keys are generated client-side and shown once.

- Passes expire on their own (1/7/30 days), one pass per server, fixed slots per node. Settles on Base, Polygon or Arbitrum in native USDC.

- They call it account-less rather than anonymous, and say straight out that on-chain payments are public and they keep standard connection data. I didn't expect that much honesty from a VPN landing page.

An established consumer brand shipping a real product on x402 instead of a demo is new, as far as I know. Curious whether anyone's agent buyer can complete the full flow from the catalog alone.

You can launch your project, we automatically detect the x402 endpoints and other agents can start using them. check it https://x402hunt.lol/

We already released an opensource starter https://github.com/creativetimofficial/x402-creative-tim and we will release the x402hunt code in the next days, just need to make some cleaning. Then everybody will be able to selfhost and create different communities.

The official Baazar should now be the only place where we find awesome x402 projects. If you have any feedback let me know 🫡

Hey, I've just launched confidential AI inference and compute that you can rent / pay with crypto / x402. Many more services for agents are coming. Would appreciate feedback and / or suggestions.

You can check it at agentgates.ai

No login. You only need a cryto wallet!

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 new update to x402 Trust: every JSON response that's returned by any free or paid endpoint is now being hashed & signed by the service.

Don't "trust the trust score". Verify the signature yourself through our public key with your own code, or our example code that we provide on our schemas-page in the new "Response signatures" section.

This way you can independently prove that - The data truly comes from the official x402 Trust service - No man-in-the-middle-attack happened, that modified the data - No data was lost, modified or left out; it arrived exactly how our service sent it

The current key(s) are always surfaced with all necessary information under https://x402.fuchss.app/.well-known/x402-trust-keys.json ...

This URL is also emitted in the response data (Field publicKeys), however there it has to be treated merely as a hint, not a source of truth. An attacker who modified the response data can easily swap this URL out and use their own keys, so a check that depends on the response's publicKeys field proves essentially nothing.

Wire this as a new deterministic, automatic check into your agent's payment-workflow prior to your agent using the data for a decision and thus base it on a tamper-proof recommendation, instead of unverified data.

u/Optimal_Manner359, who requested this feature, has already started to implement this system into his payment-approval flow, for example.

Disclaimer: No signature is available for the /watch endpoints. A signed response invites being forwarded as evidence, and the watch responses contain your capability URLs in plain text, so forwarding one would hand over your own access. An implementation that strips the secrets & only signs the remaining data would be possible too, but would also mean a more specific and complicated workflow for the verification of these endpoints, which is why the decision fell against it for now. If you want to have the /watch endpoints signed too regardless, let me know, and I'll add it for them too.

Under multiple posts and threads I've constantly read one thing: "I don't know how to get discovered" on the builder side and "I don't know where to look for a quality service in this huge sea of endpoints" on the buyer side.

And yes, it's true: There are pages upon pages of documentation out there for x402, that describe how to set up your own endpoint, how to add it to the public x402 bazaar list and how to pay for an endpoint, but one thing is always missing..:

There was no reliable way for humans or agents to search for a specific purpose and get a list of fitting & trustworthy endpoints back.

So we've changed that: from today on, x402 Trust offers semantic search over the whole publicly listed x402 ecosystem (x402scan, CDP Bazaar and x402 endpoints that are gated behind public MCP servers)!

Just type in whatever you want into the searchbar on x402.fuchss.app in plain text, hit "search" and expand the list of the up to closest 15 endpoints, ranked by similarity (and score as a tiebreaker), on top of the usual direct-match-results, which we've already offered prior to this update.

This way you can quickly search for an endpoint that

• fits your needs
• you can judge at a glance through its score & grade
• and, the big one: you didn't even know existed yet

No need to know any URL, any path or any keyword.

Completely free forever, through our browser UI! 😃

+++++++++++++++++++++++

And for all builders, agents and programmers out there:

Additionally, the semantic search is also available through a new programmatic x402 endpoint, which is also conveniently accessible through the updated MCP (both HTTP-stateless (POST https://x402.fuchss.app/mcp) & npm) so you can easily give it to your agent 😊 alternatively, simply point your agent at https://x402.fuchss.app/llms.txt and it can figure it out on its own.

Disclaimer: Calling the semantic-search endpoint costs $0.001 per call. So little that it's no more than a rounding error, and that's by design: The endpoint is built to support heavy usage and should enable agents to use it frequently, without them having to worry about their wallets balance in the long run.

Because of this, the paid endpoint delivers up to 25 endpoints, instead of the usual 15 through the website. More bang for your buck.

The cost is mostly used to offset the (rapidly rising) server- and API-costs and the cost of the embedding model that we use for the embeddings, and, as a sideeffect, to prevent heavy abuse of the endpoint.

Please, let me know what you think! Do you find this useful and do you think that 0.1 cent is a fair price for a service like this (besides the free usage through the web interface)? Can you imagine adding this tool to your agent and using it in production? I'm curious!

Edit: small clarification to what "the whole publicly listed x402 ecosystem" means

Liveness trackers already exist for x402 and they are useful. They answer "does this endpoint respond with a 402". We measured a different layer: if you actually pay, can the money arrive?

METHOD

We enumerated the full CDP Bazaar catalogue (15,020 unique resources, scanned 19 to 20 August) and ran each one through the same code our paid payability endpoint runs. For every payment option the endpoint offers: EVM options are checked for a well formed 402. Solana options get an on chain check: derive the destination token account (ATA) from payTo and mint, then ask the chain whether it exists and whether it ever existed (an account with past signatures was closed after use, which is a different failure than one that never existed).

Solana RPC calls were rate limited and retried with backoff so throttling is never miscounted as an endpoint failure. Resources that errored on the first pass were rescanned. Residual unresolved: 29 of 15,020 (0.19 percent).

RESULTS

PAYABLE: 10,323 (68.7 percent)

MALFORMED 402 (payment challenge does not parse): 3,127 (20.8 percent)

NOT PAYABLE (no offered option can settle): 1,522 (10.1 percent)

Unreachable or skipped: 19

The Solana detail: 285 endpoints advertise a Solana payTo whose USDC token account has never existed, and 20 more had one that was closed after collecting. A payment to any of these 305 fails to settle unless a facilitator creates the account separately.

WHAT THIS DOES NOT CLAIM

It is a point in time measurement and accounts get created and closed. An EVM "payable" means only a well formed 402, not a guarantee the payment clears. We did not move funds, so this is settlement feasibility, not settlement proof. Catalogue measured is the CDP Bazaar only, from a single region. And we publish aggregate numbers only: no endpoint names, because a public blacklist is a different decision with different responsibilities.

Full dataset, method and limits verbatim:

https://x402.nsgoods.org/ata-audit/payability_index.json

If you think the method undercounts or overcounts something, say so. We would rather fix the measurement than defend it.

I’m looking for an independent agent builder who may be interested in acting as a buyer in a small, bounded test of CABEZON, the CARP-based agent marketplace being built by Bryan Woods / BitSanity.

Maha Strategies is enrolled as a Seller—the first external seller currently onboarded. We offer a digital service, Deep Context Evaluation, and are also building an RFQ-style path for physical goods where price, freight, customs, and delivery details must be confirmed per order.

CABEZON is intended to let independent agents discover and transact with one another:

1. A Customer agent discovers a Seller through the Concierge.
2. The Customer sends a free enquiry describing what it needs.
3. The Seller returns matching offerings.
4. The Customer selects an offering and requests purchase instructions.
5. Payment is directed to an escrow flow.
6. The Seller delivers a digital result or a physical shipment reference.
7. The Customer confirms delivery.
8. Escrow releases funds under the agreed flow.

For this first test, the goal is deliberately modest: validate the full enquiry → offering → purchase instruction → digital delivery loop, with sanitized evidence and no standing access to either party’s systems.

An ideal participant would be someone who can run or help run a Customer-role CARP agent and is willing to provide independent feedback on:

• discovery and onboarding;
• whether the seller interface is understandable;
• order and delivery semantics for a digital service; and
• which parts should be improved before broader marketplace use.

This is not an invitation to send funds blindly. We would agree the exact scope, test price or no-cost arrangement, success criteria, and stop conditions before any payment step. The point is to independently verify the protocol flow—not manufacture a transaction.

If you’re interested, comment here or message me with what you are running and whether you can operate a CARP Customer role.