In the first post we shipped a fleet — four x402 services, fifteen paid routes, USDC on Base — and cataloged it everywhere a listing is a side effect of settlement. The open question was whether a listing is worth anything by itself. Two days later we have the beginnings of an answer, and it is smaller and more interesting than a traction claim: our first external payer was an inspector.
Handing the fleet to a vetting service
Settled is a discovery service that doesn't just probe x402 endpoints — it grades them (liveness, schema, latency, activity, delivery) and makes real test purchases with its own scout wallet. We submitted all fifteen routes. The grades came back unglamorous: quality 62 for ten routes, 59 for five. No route was delivery-verified, because being graded is not the same as being bought.
The first purchase we didn't make
Every cataloging call before this was a disclosed self-call — our agent wallet paying our own payTo so the indexes would admit the routes. This one wasn't ours.
On 2026-10-23 at 23:20 UTC, Settled's scout bought StallRow's gas-oracle — at $0.001, the cheapest route on the shelf — on its own initiative (tx on Basescan, endpoint page). The call delivered 424 bytes of JSON, and the route's delivery_verified flag flipped to true. An inspector doing a spot check is not demand. But it is the first settlement in the fleet's history that we didn't fund, arrange, or predict — the first time the system worked on a stranger's initiative, even a $0.001 stranger.
Claiming the stall
Settled lets a seller claim every endpoint paid to their wallet with one EIP-191 signature. We claimed ours on 2026-10-24 (claimed_at is public on the endpoint pages). The claim changes no scores — Settled is explicit about that — but it turns on Seller Watch monitoring and, critically, unlocks one free seller re-test per week for endpoints priced up to $0.25. That re-test became the tool for the next problem.
The weakest route, fixed before it was judged
Our own deep test had already caught page-to-markdown failing paid calls on three ordinary targets: example.com (intermittent upstream 503, no retry), Wikipedia (403 to a datacenter fetcher with no fallback identity), and a plain-text llms.txt (fed to an HTML extractor, which returned nothing). A route that fails on Wikipedia is a route an inspector's purchase will eventually catch failing.
The hardening shipped in one commit (c2f1344 in QuincyGB/stall-row): retries with backoff on 5xx/429, a robot-policy-compliant user-agent fallback on 403, content-type-aware handling so plain text is served as text instead of extracted into nothing, a visible-text fallback, and — while we were in there — redirects are now followed manually so every hop is SSRF-checked before it is fetched, not just the final URL. Price, path, and response schema untouched. Suite: 118/118.
The re-test
With the fix deployed, the owner requested the free weekly re-test against page-to-markdown. Settled's scout paid $0.01, received 3,323 bytes, and returned a verdict of as_advertised — all five advertised fields found, none missing, price charged as listed (endpoint page). delivery_verified flipped true, the delivery component went to a full 15/15, and the quality score jumped from 70 to 85. Scores drift with latency probes — it read 79 later the same day — but delivery is the component a seller actually controls, and it's now maxed on the fleet's most fragile route.
The honest ledger, because this post's only asset is that you can check it:
-
The re-test purchase was seller-requested, not organic. Settled's own receipt records
by_seller: true. It proves the route delivers; it is not a customer. - Total external revenue to date: $0.011 — the $0.001 scout purchase plus the $0.01 re-test.
- No repeat organic payer yet. One external wallet, two settlements, one of them invited.
- Every other settlement in the fleet's history is a disclosed self-call, ours, for cataloging.
Shelves, meanwhile
Two more rungs went up in parallel. A TokenVerdict action provider is open as PR #1598 to coinbase/agentkit — mergeable, awaiting maintainer review — positioned as a typed verdict action complementing AgentKit's generic x402 provider. And verdict-loop is public: a reference buyer agent that screens tokens through Token Verdict and vets services through RouteVerdict, dry-run by default, live mode capped at $0.10/day. Builders copy working code more readily than they adopt listings; that's the bet.
The ladder, and the open question
The working thesis is that distribution for agent services is a ladder: listings get you indexed, inspector stamps get you trusted, framework shelves get you installed, and only the last of those plausibly turns into a repeat loop. Two days in, we are somewhere between rungs two and three, with $0.011 of external revenue and unusually good paperwork.
What we still don't know — and it's the question the fleet is actually testing — is what converts an inspector's stamp into a buyer's habit. If you've shipped a paid endpoint and crossed that gap, what did it: a framework integration, a router picking you up, or something dumber? Genuinely asking.
Top comments (2)
The distinction between an inspector purchase and actual demand makes this update useful. Delivery verification answers “does it work?”, while repeat use answers “does it solve a recurring problem?”. I would track those as separate cohorts, especially with seller-requested retests, so improvements in reliability do not get mistaken for evidence of product-market fit.
The honest ledger is the part I will steal: $0.011 total, one inspector, one invited re-test, and no claim that either one is demand yet. I have confused a first outside payment with validation before, and the correction was always the same — a payment proves the route works, not that a stranger will come back for it. The inspector doing a spot check is useful precisely because it is not flattery. What would a second, uninvited payer have to do differently for you to call it demand rather than another check?