What a penny from a stranger taught us about how agents actually find things.
At 02:59:06 UTC on August 25, a wallet we had never seen paid our verification service one cent over x402. Four and a third seconds later, Coinbase's service catalog refreshed our listing. Nothing else we had ever done moved that listing. Deploys did not move it. Metadata edits did not move it. Validation runs did not move it. Money moved it, in under five seconds, every time.
The transaction is public: 0x5e9bd3c9c61d7556b1ffb1a5b936591efccd765af94a81da435432e1f62ff52a on Base. This article is the story of what that penny bought us, which was not revenue. It was a map.
Where we were standing
ScrapeCheck is an independent verification service for web data. You send a URL and the value you believe is on that page. We re-fetch the page from our own infrastructure and return a signed pass, fail, or unverifiable. Never a guess. Every verdict is ed25519 signed and verifies offline against our published key, so whoever holds it can check it without trusting us.
We listed on the x402 Bazaar, Coinbase's machine-readable catalog of paid services, on August 14. The catalog held a little over fifteen thousand rows. Listing is permissionless. Then we noticed something about discovery: the catalog's own API defaults to a curated view. A client that browses the normal way is shown roughly 110 hand-picked rows out of fifteen thousand. The two largest curated providers hold about 44 percent of that shelf between them. Everyone else, us included, is in the warehouse but not in the front window.
So we did what we do to web pages: we instrumented our own listing and started reading it back, on a schedule, with timestamps.
What moves a row
The catalog publishes freshness fields on every row. We recorded ours across every kind of event we could produce. The pattern was absolute.
Our row was created one second after our registration payment settled. It was crawled five seconds after a later settlement. It refreshed 4.3 seconds after the stranger's penny landed, and 1.7 seconds after a settlement on our second route. Between those moments we deployed new code, edited metadata, and ran Coinbase's own validator against ourselves repeatedly. The row never moved for any of it.
On this catalog, the settlement is the write event. Not uptime, not metadata quality, not validation. A row is alive because someone paid it recently, and for no other reason the data will admit.
We then made a prediction in writing, because that is house practice: predictions get committed before the act, so a miss is a finding instead of a shrug. We predicted that a settlement against a brand new route would create its catalog row within seconds, like the four prior observations. We paid our own service two tenths of a cent on the new route. The row did not appear in sixty seconds. It did not appear inside the documented ten-to-fifteen-minute indexing window either.
The miss looked like a clean split at first: settlements refresh existing rows synchronously, and creation rides a slower, separate pipeline. So we registered that as the model, and predicted that the next three brand new routes would also be slow to appear. They were not. All three rows existed within about one second of their settlements, descriptions intact. Five of our six creation and refresh observations now cluster between one and five seconds; the half-day outlier is the thing that needs an explanation, not the rule. Two registered predictions have now failed in opposite directions inside one week. We keep both misses in the ledger next to the hits, because the honest state of our knowledge is a distribution with an outlier, and a company that sells verification does not get to round that off.
The stranger
The wallet that paid us on August 25 has a shape worth describing. It holds a few dollars of USDC and zero ETH. It has never submitted a transaction of its own; every payment it makes is signed and handed to a facilitator to post on-chain, so its history is invisible under its own name. The facilitator that carried its payment has processed over 1.4 million transactions, nearly all of them the same x402 settlement method. This is not a person. This is purpose-built agent infrastructure, funded with pocket change, paying its way through the protocol call by call.
It ran the exact example from our documentation, paid the exact asking price, received a signed verdict, and left. We verified the settlement on the chain before we let ourselves believe it.
Then we read the wallet's outgoing history, which is public. It had paid roughly thirty services in bursts, minutes apart, a penny or a fraction of a penny each, each service at its own listed price. Two days later a second wallet we had never seen walked nearly the same route and paid us twice more. Different wallet, same fingerprint, same recipient list. Something out there systematically pays every service on its route to see what comes back, on rotating wallets, on a schedule.
We call it the census. It is not a customer. It is the catalog ecosystem checking its own inventory with real money, because in a machine economy, a paid round trip is the only health check that cannot be faked by a status page.
And the reaper follows the census. Coinbase's documentation is plain: resources that go thirty days without a settlement are removed from the catalog and from search. In the two days we watched, the catalog shrank by 367 rows. The shelf is not growing. It is churning, and the rows that survive are the rows that something pays.
The honest ledger
Our public stats page now reads, at the time of writing: five external settlements, five automated probes, zero organic buyers. Each settlement links to its transaction on Base, so the claim carries its receipt. Under the zero it says: a paying caller with a URL of their own. None yet. This is the only number we treat as demand.
We wrote the page so that sentence deletes itself mechanically the day it stops being true. Honesty that depends on someone remembering to update a page is not honesty for long.
For scale: our engine has now answered five hundred and some checks across six verification routes, pages, JSON endpoints, XML feeds, file checksums, redirect chains, and a presence tier, all under one signature, all verifiable offline. Our benchmark record across 67 frozen labeled cases and 21 live-web cases including adversarial traps stands at zero false passes. The census has tested us five times, and five times the verdict came back exactly as our documentation says it should. None of that is demand either. It is readiness.
What we think this means
The agent payments rail is real. Independent trackers counted 8.9 million x402 transfers in the third week of August, roughly double the week before, at an average of about four cents each. The announcements arrive weekly now: corporate spend platforms, cloud agent stacks, merchant checkouts. Machines are being given budgets.
But stand where we stand and you can see what the announcements leave out. Every payment product answers the same question: who spent what, on whose authority. The ledgering is excellent. What no payment record contains is whether the thing the agent acted on was true. An agent pays forty dollars because a page said forty dollars, and the receipt is perfect, and the receipt holds no evidence about the page. The census exists because even the catalogs know a listing cannot be trusted, only tested.
That second half of the audit trail, the was-it-true half, is the layer we are building. Six claim types today. One signature. A verifier anyone can run offline. A stats page that counts against us. And next, work to make ourselves easier to audit than to trust, so the proof does not depend on our word at all.
The penny did not make us a business. Zero organic buyers is the truth, published, linked to the chain. What the penny proved is that the machine economy's plumbing works end to end with a stranger on the other side, that the shelf rewards exactly one behavior, and that a very small company that writes its predictions down before looking can map a platform from the outside with pocket change.
When the buyers arrive, they will find the receipts already waiting.
Rick C. ScrapeCheck, by Fieldmode LLC Stats, with every settlement receipt: scrapecheck.fly.dev/stats Offline verifier: github.com/FieldmodeLLC/scrapecheck-mcp
Top comments (0)