DEV Community: FieldmodeLLC

The settlement is the write event

FieldmodeLLC — Thu, 27 Aug 2026 15:22:10 +0000

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. Our monitor found no row at sixty seconds, none inside the documented ten-to-fifteen-minute indexing window, none at nearly the hour mark. We recorded a miss.

The miss was real, but it belonged to our instrument, not to the catalog. Three more brand new routes came later, and each row existed within about a second of its settlement, descriptions intact. That forced a re-audit of the first case from primary sources, and the primary sources agree to the second: the first row's own timestamps record its creation within about a second of its settlement too. What our monitor had been reading was the catalog's public listing, and a freshly created row takes time to become visible there: in our measurements, one new row was still invisible nearly an hour after its creation, and every new row had appeared by our next read, at nineteen minutes in the earliest-checked case and eighty-eight in the slowest. The prediction had come true and the thermometer was on the wrong wall. The model is now unbroken across every observation we hold: row writes are settle-synchronous, one to five seconds, six of six creations and seven of seven refreshes, while listing visibility lags behind, by nearly an hour and a half in the slowest measured case. We keep the miss in our ledger next to the hits, relabeled for what it is: a finding about our own instrument.

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.

Correction, 2026-08-28: an earlier version of this article reported that one catalog row, the newest route's, took roughly half a day to be created, and called that outlier the thing needing an explanation. A re- audit from primary sources found the outlier never existed. The row was created within about a second of its settlement, like every other row we have measured; what lagged was its visibility in the catalog's public listing, which is what our monitor was reading. The section above now tells it that way. The earlier wording, and the miss that led to it, remain in our ledger.

Rick C. ScrapeCheck, by Fieldmode LLC Stats, with every settlement receipt: scrapecheck.fly.dev/stats Offline verifier: github.com/FieldmodeLLC/scrapecheck-mcp

We ran our benchmark five times and we have no number to publish

FieldmodeLLC — Mon, 17 Aug 2026 13:04:55 +0000

We set out to measure something we could not find measured honestly anywhere: how much of the web data sitting in commercial datasets is still true.

Not stale in the sense of "this table has not refreshed." Stale in the sense that costs someone money: you bought a row, the row says a page contains a value, and the page does not contain that value anymore. We build independent web data verification, so running the measurement is the natural thing for us to do, and the number would have been the best marketing asset we could ask for.

We ran the study five times in one day. We have no number for you.

The one day is worth explaining before anyone else raises it, because it sounds like haste and it is the opposite. Running a verification pass costs us about $1.10 per thousand rows, so the runs are cheap and fast. What was slow was the rules, which were written first and which is why five runs produced zero publishable numbers instead of one convenient one. Cheap measurement plus strict rules gets you a lot of failures per hour. That is the system working.

This is the report on why, and it is more useful than the number would have been.

The rules we wrote before we looked

Before the first run we wrote down and committed the method: which datasets we would pull from, how we would search for them, how the sample would be selected, what would disqualify a run, and what a pilot run is allowed to produce. That last pair is what did the damage.

We pre-registered an honest-N floor. The study targets 25 usable datasets. Below 10, the run does not publish at all, no matter how interesting the result looks. We wrote that rule before we had any results, precisely so we could not decide afterward whether our sample was big enough. A sample size chosen after seeing the data is not a sample size, it is a preference.

We also pre-registered that pilot runs never publish their numbers, and deterministic sampling, so that which rows got tested was decided by a hash rather than by us. From the scale run onward we recorded parse coverage as a number on every dataset, so rows we could not read were counted rather than quietly dropped.

Every one of those rules has now cost us something. That is what they were for.

Run one: the search was wrong

The first run returned nothing usable. The cause was not the engine and not the data. Our dataset search matched on names rather than descriptions, so the protocol was looking through a keyhole and reporting an empty room.

We amended the search protocol and recorded the amendment. We did not rerun and quietly call it run one.

Run two: our own spot check was measuring the wrong thing

The second run came back with 28 of 28 rows unverifiable.

The interesting part is why we did not catch it earlier. Our pre-run spot check tested whether a sample row's URL was reachable. Reachable is not the same as addressable by the engine, and the difference is the entire study. A page can answer a request and still be something our verification cannot form an anchored question about.

We amended the spot check to require rows that are engine-addressable through the actual verification path, not rows that merely return HTTP 200 to a browser.

Run three: a number we are not going to show you

The third run was the pilot, and it produced an actual figure.

Pilot numbers never publish. We wrote that down before the run, so the figure is recorded in our results file and excluded from publication.

We are aware of how that reads in an article about honesty, so let us be exact. We are not withholding it because it embarrasses us. We are withholding it because the rule that governs it was written before we knew what it would say, and a rule you suspend the moment it becomes inconvenient was never a rule. Publishing the number here, framed as "the one we could not publish," would be publishing it.

If a later run clears the bar, you get that number with its full method attached. If none ever does, you never get one, and that will also be true.

The scale run, and the finding actually worth your time

The fourth attempt was the big one: 17 datasets, 1,694 rows. It produced no publishable number either. It produced something better.

The results came back bimodal, which tripped a flag we had pre-registered for exactly this shape. Bimodal means two populations are hiding inside one average, and an average across two populations is a lie with a decimal point in it. The flag forced us to characterize before reporting.

Characterizing found three defects, all three in our instrument rather than in the world.

One: we were reading the wrong column. Some datasets carry several URL fields, and the one we treated as the product page pointed at image assets. We were checking whether a price appeared on a JPEG.

Two: claimed values carried prefixes that were never on the page. A row whose value arrives with a vendor-added label attached fails verification for a reason that has nothing to do with data quality. The value was right. The string was not.

Three, and this is the one to take away: bot walls look exactly like stale data. A meaningful share of our failures were sites returning a challenge or interstitial page at HTTP 200. The request succeeds. The status code says everything is fine. The page contains no product and no value. To a verification pass that is indistinguishable from a page whose value has changed, and it scores as a confident failure.

The implication is worth stating plainly and carefully. Any measurement of web data decay that does not screen for challenge pages served at HTTP 200 will overstate decay, and will not be able to tell you by how much. We do not know how many published figures carry that defect. We know ours did, and we only caught it because a flag we had written in advance refused to let us average across it.

We now keep a frozen list of seventeen challenge-page entries, one of which is a paired rule. It was committed before the next run started, and any addition made mid-study is logged as an amendment rather than applied quietly, because a detection list you expand while looking at results is a way of choosing your answer.

The control, and why we threw it out

While characterizing, we ran a control against a dataset with clean product URLs. It passed at 95 percent, which told us the instrument behaves when the inputs are clean.

Then we disqualified it.

The control scraped a website that exists specifically for people to practice scraping on. It is static by design. It never changes, which is exactly why nothing on it had decayed, and exactly why it can tell you nothing about the world. The sandbox-exclusion rule we wrote afterward rejects it, so we applied that rule to our own most flattering result.

Our best-looking number came from a training site. We are telling you that instead of letting you find it.

The rerun, and the fifth wall

With the defects fixed we reran. The corrected harness screens challenge pages before they reach the engine, prefers page URLs over asset URLs, tests both raw and sanitized claim strings, excludes sandboxes, and caps how many datasets any single publisher can contribute so one source cannot carry the study.

Screening that aggressively removed a great deal. The run landed at 5 usable datasets, below our own floor of 10.

So it does not publish. That is the fifth time this study has produced no number and the third time it produced one we walled.

What we actually know now

We know our search protocol was wrong and we fixed it. We know our spot check was testing the wrong property and we fixed it. We know at least three ways to accidentally manufacture a frightening decay statistic, because we manufactured all three. We know the same mistake wore two different disguises in one day: a vantage that could not reach a page, and a vantage that reached a wall and mistook it for an answer. Both times we were describing our own position and calling it the world.

We do not know how much commercial web data is stale. We are further from claiming to know it than we were this morning, and that is the correct direction to be moving.

Why publish this

Because the alternative was available and we did not take it.

We could have published the pilot figure with a caveat paragraph. We could have published the pre-fix scale run, which produced a much more alarming number than the corrected one, and no reader could have caught the image-column defect from outside. We could have kept the 95 percent and left out where it came from. All three would have drawn more attention than this article will, and all three would have been the kind of vendor study that this industry has correctly learned to discount.

We sell independent verification. The only thing we are asking anyone to buy is that we do not round toward the answer we want. A company like that publishes its walls, or its numbers mean nothing when it finally has some.

Check us, and the limit of checking us

The pre-registration, every amendment with its date, the results, the decision log and the frozen challenge-page list are published alongside this article, with dataset identities replaced by opaque labels. The identities are withheld because we will not name someone's dataset in a study about failure without their consent, and we publish a commitment to the private mapping so that if anyone does consent later, the reveal is provably the same mapping and not a convenient one.

Here is the limit, since this is an article about limits. Our record shows the rules were written before the runs, but that record is ours. Timestamping it now would prove it existed now, not that it existed first, and we are not going to dress up a proof we do not have. From the next edition onward the pre-registration is timestamped by a third party at commit time, so the ordering becomes something you can check instead of something we assert.

We will run this study again. If it clears the bar, you get the number. If it does not, you get this instead.

Rick C. Fieldmode LLC

I couldn't find a tool that lets agents verify what they're buying. So I built it.

FieldmodeLLC — Sat, 15 Aug 2026 01:12:39 +0000

I built ScrapeCheck because as someone who has been in the crypto industry for over 9 years, I know how important it is for information to be public, like the blockchain. With the rise of agentic commerce, I wondered if there was a tool that bots could use to ensure that the item they're looking to purchase could be verified and I could not find it so I decided to build it.

Here's what that turned into, and one experiment that shows the whole thing working end to end.

The problem, in one sentence

Agents increasingly act on web data they didn't fetch themselves: a price from a scraper, a value from a search API, a row from a dataset. When that data is stale or wrong, nothing warns anyone. The agent that fetched it, the pipeline that stored it, and the buyer who acts on it are all trusting a number that may no longer be on the page.

What ScrapeCheck does

You give it three things: a URL, the value you were given, and what was asked. It independently re-fetches the page from its own infrastructure and returns one of three verdicts: pass, fail, or unverifiable. Never a guess.

Two design rules do most of the work.

First, a claim is never certified unless our own re-fetch actually contains it. There is a model in the loop, but it has one power only: it can veto a pass. It can never create one. AI may interpret evidence here; it never manufactures it.

Second, anything we cannot independently confirm comes back unverifiable instead of being rounded to an answer. Server-rendered pages only; JavaScript-only content returns unverifiable by design. On our benchmark that discipline has held at zero false passes across 67 frozen cases (26 held out, adversarial traps included) and 21 live-web cases. Small sample, and I label it that way on the stats page too.

Every verdict is signed with ed25519 and verifies offline against the published key with an open-source verifier. You don't have to trust me, my server, or my database. Check the artifact.

Built for agents to buy

There's no account and no API key. Payment is the credential: $0.01 per full check, $0.002 for a presence-only check, paid in-band over x402 (USDC on Base). The first 100 checks per client are free, and the 402 challenge itself tells your agent how to use them. It also runs as an MCP server on the official registry, and as the Scrape QA actor on Apify for verifying whole dataset runs. The API speaks x402 v2 and is listed in the CDP Bazaar catalog.

The experiment: one agent buys from another, then verifies what it bought

I wanted to know if the full loop actually works today, machine to machine, no human in the flow. So we pre-registered a test and ran it.

A small buyer agent, deliberately naive, paid Exa (a search API that sells over x402) for a search result. Cost: $0.007, settled on Base. It took a value from the answer it bought, then paid ScrapeCheck $0.01, same rail, to check that value against the live source page. It got back a signed verdict it could verify offline.

To be clear about what this was and wasn't: we funded the buyer wallet ourselves and labeled it as our own traffic. This was a demonstration that the loop closes, not evidence of organic demand. The methodology was committed to git before the run, no re-rolls, and the full transcript, settlement hashes included, is in the repo. And credit where it's due: Exa's endpoint worked exactly as advertised, first try. We picked them because they're one of the most real services on the rail.

That loop, buy from a machine, verify with a different machine, trust neither, is what I think agentic commerce actually needs before anyone lets an agent spend real money on web claims.

The honest state of things

The stats page is public and it labels our own test traffic as ours. I publish the misses next to the passes, and there's a permanent line on that page for external paid checks that will read zero until it doesn't. If you want to kick the tires: the repo, the verifier, and one free check in your browser are all one click from the landing page.

Service: https://scrapecheck.fly.dev
Repo and offline verifier: https://github.com/FieldmodeLLC/scrapecheck-mcp#verify-a-verdict-yourself-offline
Live stats, self-traffic labeled: https://scrapecheck.fly.dev/stats

If you're building agents that act on web data and this is useful or missing something you need, I want to hear it.

Rick C., Fieldmode LLC