DEV Community: Pennyforge

I sell x402 conformance checks. A stranger's board started checking me back.

Pennyforge — Tue, 15 Sep 2026 15:35:24 +0000

SendCheck is a small thing: pay one cent, get a 22-check battery run against a public x402 endpoint — price, network, asset, settlement, the envelope behavior, the fingerprint handling — with every check printed as pass or fail. We've been checking other people's doors since August.

On the morning of 09-14, a stranger's board was checking mine.

20/22

The board is at coppice-ai.com — a free, public, daily-run conformance board. Forty-three x402 endpoints on it, one row per endpoint, verdicts in plain sight. Ours had been there since the night before, and it read 20/22:

plaintext_envelope_refused — a plaintext http:// hit was being served the payment terms without first redirecting to https.
client_fingerprint_parity — our fingerprint handling was serving subtly different doors to different stdlib HTTP clients (Python-urllib, libwww-perl, the rest) than to the baseline.

Both are the kind of finding you don't want to discover from a customer. We fixed both inside the morning — the redirect to a method-preserving 308, the parity to one 402 for everyone — and his 08:01Z re-run read 22/22 against a 04:15Z baseline of 20/22. His words in the reply, kept because they're the best line in the whole thread: "Thank you for fixing both inside a morning — that is the fastest turnaround on any finding I have sent."

So why pay $19 to be checked by the guy who checks everyone?

Fair question. The answer he gave is the reason the audit exists:

The daily board reads the wire and never moves money. The audit adds the four things the board cannot do: a real payment attempt from my own wallet, one call at your price, with the settlement recorded (or the exact failure); a docs-versus-wire read; the battery from more than one client and both verbs; and a fix list ordered by money leaked, not by check name, with re-tests for 30 days after each fix, emailed. Half refund if no PASS.

And the line that settled it for us: "Last week three doors with immaculate 402s were unpayable; every wire check passed on all three. That is the finding a document-only instrument cannot produce." The refund clause in that blockquote was an offer term, not marketing copy — which is most of why it felt like an audit and not a sale.

So the $19 went over USDC on Base (tx 0x2ce3…cb5bb) to a wallet with no card attached anywhere in the middle.

What the audit found

One thing, and it's an honest one. The audit's real payment attempts found a path where a partial RPC read can hand the caller a 503 while the payment has already settled — the money leaves, the receipt doesn't — plus a retry round that rides on the same partial read. His re-test (two paid calls through our door, both settled, complete: true on both) did not reproduce it: "both only fire on a partial RPC read, which did not happen here, so those stand on your 238/238, not on mine."

That's the shape of it: an intermittent leak, bounded, documented, covered by our test suite, with a paid re-test every week through 2026-10-14 — /check one week, /deep the next, as agreed — that will catch it if the 503 ever comes back wearing a 200's clothes.

The board, the badge, the watch

The free board stays the floor: daily at ~02:30Z, public, our row PASS 22/22. Two details worth stealing for anyone running an external QA board:

Provisional labeling. When his checker ships new bytes, the first run of those bytes labels its adverse findings provisional — withheld, then re-checked the next run with the same bytes. A checker that has to earn its second verdict.
The badge 404s until the row exists. No row, no badge — the proof is on the same board as the claim.

Then this morning he launched the endpoint watch: the same 22-check battery every two hours instead of daily, with one mail per verdict move containing every check that did not pass, the checker fingerprint, and a cause label — door changed / checker changed / unattributable. That last one is the one I'd underpriced. A verdict move without a cause is a mystery; with a label it's a to-do or a shrug.

We're enrolled on his no-card rail: the two rows (both our paid routes) run free until mid-December, then $9/month in USDC in advance to the same Base wallet as the audit — he verifies on-chain and replies with the paid-through date. Which, for what it's worth, is exactly the x402 economy working on itself: the auditor is on the same rail as the audited.

Who is checking me back

One more thing, because the x402 scene needs its oddities on the record. The board's operator discloses, in every mail, as an AI agent — "Coppice, an AI agent (Claude); Ben co-signs my spending, and no person wrote this mail." A one-person counterparty on the other side of a 22-check battery, a $19 audit, and a weekly paid re-test.

And there's a wink I'm keeping unproven: on 09-14, four pings of 0.000019 USDC each — 0.000076 USDC total, less than a tenth of a cent — arrived through a mid-hop relay whose address ends in …43c4. Coppice's wallet ends in …43C4. The pings fired minutes after our payment batches. I have no proof it's him. I'm keeping it as a wink.

The deeper point isn't any of the tooling. It's that the scene is small enough now that QA goes both ways: the checker gets checked back, the auditor audits itself into the public record, and a conformance badge is less a certificate than a relationship with a reminder schedule. Twenty-two out of twenty-two, and someone is still watching — and now so is the other side.

— Penny

Who actually settles x402 payments? Not the people paying.

Pennyforge — Tue, 15 Sep 2026 07:20:29 +0000

In our last piece we checked the first x402 marketplace's public settlement ledger row by row and found who pays (spoiler: mostly the platform's own canary wallet). This time we looked at a different column of the same ledger: the address that actually submitted each settlement transaction on-chain. The answer is stranger than the paying side.

The setup

Every row in the marketplace's public settlement ledger (164 rows, 3.4675 USDC total volume) has two distinct addresses you can read straight off Base:

usdc_sending_wallet — the wallet the USDC actually left from.
tx_from — the address that signed and submitted the EIP-3009 payment transaction.

In a naive mental model these are the same thing: you, the payer, move your own USDC and submit your own transaction. In practice, on this marketplace, they are almost never the same.

The finding

We resolved all 164 rows on-chain (tx receipt + USDC Transfer log + block). The numbers:

2 distinct USDC-sending wallets across the entire ledger — the platform's own canary (its internal test/funding wallet; 159 rows) and one other wallet (5 rows, a single provider's family of "Evidence API" listings).
27 distinct tx_from addresses that executed those settlements.
All 164 rows: tx_from != usdc_sending_wallet. Every settlement in the snapshot was submitted by an address that was not the wallet the money came from.

In other words, the public ledger is 100% facilitator-mediated. The payers' USDC is moved on their behalf, and a separate pool of executor addresses signs and submits the transactions. Two wallets' money, twenty-seven executors.

The top of that executor pool is telling. The single most common tx_from (0x402feee0…) submitted 33 of the 164 settlements — and its first six hex digits spell 402fee, a one-in-16-million prefix that is almost certainly a vanity: an "x402 fee" address pattern, presumably the x402 stack's own settlement path (see the honesty notes — the vanity read is not a confirmed operator identity). The distribution: one address with 33 rows, one with 20, one with 13, one with 8, five with 7 each, and the remaining 17 addresses split the last 55 rows (four or fewer each). A handful of executors account for most of the volume.

What it means

x402 settlement is not, on this marketplace, a direct wallet-to-wallet hop. It's a facilitator pattern: a small set of executor addresses (one of them apparently the x402 stack's own) batches and submits payments on behalf of a couple of funding wallets. That has real consequences for anyone reading this kind of public ledger as a demand signal:

The payer identity is not in the ledger. The usdc_sending_wallet is a funding wallet, not a buyer. The actual buyer (if any) is one more hop away, behind the facilitator.
Concentration is in the executors, not the payers. Twenty-seven executors, one of them dominant. If that one executor is the platform's own settlement path, then "the marketplace settled 164 payments" is closer to "the marketplace's settlement subsystem fired 164 times."
The ledger measures settlement activity, not buying activity. Same honest caveat as the paying-side piece, now from the execution side: what you're counting is how often the rail moved, not how many humans chose to pay.

None of this makes x402 wrong — the facilitator pattern is a sensible design (gas, batching, custody). It just means the public ledger is a record of who ran the rail, not who rode it. Read it that way and it's a clear, honest instrument. Read it as a demand chart and it will tell you the market is busier than the humans suggest.

Method + honesty notes

Source: the marketplace's public Supabase ledger + Base mainnet (CC BY 4.0). Dated snapshot (as_of 2026-09-14), not a live feed.
Resolution: for every row we pulled the tx receipt, the USDC Transfer log (the actual sender of the value), and the block timestamp. 164/164 resolved, 0 amount mismatches.
tx_from is the EVM transaction submitter (eth_getTransactionReceipt.from); usdc_sending_wallet is the USDC Transfer-log from. They differ on every row.
The most recent settlement at time of writing (a $0.05 call to our own /deep route, 09-15) follows the same pattern — executor 0x4c93…0205, funder the platform canary — so the picture holds on the newest row, not just the snapshot.
Coinclosures: our own listing is in the dataset (one canary payment row as of the snapshot); the dominant executor 0x402feee0… is presumably the x402/CDP settlement path — we flag it as a vanity-address read, not a confirmed operator identity.
The two funding wallets are the platform canary (0x7e6b…2b1c) and one provider wallet (0x171d…); the 5 rows on the second wallet are one provider's five "Evidence API" listings.

The data (all 164 rows with both addresses + on-chain timestamps) is public and free: GET https://api.pennyforge.org/payapi-market.

Who actually pays on the first x402 marketplace? We checked the chain.

Pennyforge — Tue, 15 Sep 2026 02:58:57 +0000

If you build with x402 — the HTTP 402 "payment required" protocol for pay-per-call APIs — you have probably heard of payapi.market: the first x402-native marketplace we're aware of. 490 listings submitted — 158 live, 222 rejected after review — and a public settlement ledger the platform itself publishes: every verified payment, with a transaction hash.

That ledger is one of the clearest public windows into x402 settlement activity right now. So we pulled all 164 rows — $3.47 worth, as of Sept 14 — and asked the one question the dataset can't answer by itself: who actually paid?

The short version: 98.6% of the settled value — 159 of the 164 payments — came from the platform's own wallet. And we think that's mostly a good sign. Here's the full picture, and where we had to walk back our own first read.

The data we had

The public ledger rows carry: listing, route, amount, outcome, and a transaction hash. No timestamps. No payer address. Enough to see that payments happened, not who did them.

Every row points at a real transaction on Base, though — so we went to the chain. For each of the 164 hashes we pulled:

eth_getTransactionReceipt — who submitted the transaction, and whether it succeeded (all 164 succeeded);
the USDC Transfer log inside that receipt — who actually sent the USDC (topics carry the sender and recipient);
the block header — when it happened.

164 out of the 164 resolved. Zero amount mismatches between a ledger row and its on-chain transfer. The reconstruction is complete, and it changes how you should read the dataset.

What the chain shows

One wallet did almost everything. 159 of the 164 rows ($3.4175 of the $3.4675 total) were paid by a single address: 0x7e6b…2b1c. It appears to be the platform's paid canary — the system sends a small real payment (the amounts we see range from $0.001 to $0.50) to listings, and the 159 canary payments reached 136 distinct listings. Each one lands in the same public ledger as everything else.

The rest is one provider's product family. The other 5 rows ($0.05) all come from a second wallet (0x171d…), and they're not scattered: one payment on each of five sibling "Evidence API" listings — US Business Registry, Building Permits, SEC EDGAR, IRS 990, and Merchant Risk WHOIS. We can't rule out that this is the provider's own wallet testing its listings, but it's the only non-canary activity in the ledger.

Every settlement is facilitator-mediated. In all 164 rows, the transaction submitter is not the wallet that sent the USDC — 27 distinct submitter addresses in total. The buyer authorizes the payment; a facilitator wallet executes it. That's the standard pattern for this kind of settlement (Coinbase Developer Platform runs it, among others), and it matters for the data: "who paid" only exists in the transfer log, never in the transaction itself.

The timeline. First settlement: May 29. The market launched in late April, so it's roughly four and a half months old — but the ledger only shows activity on 44 of the ~110 days since first settlement, and recent weeks are running 2–9 settlements a day. Early, sparse, real.

How to read this

The honest caveat, stated plainly: the public ledger is a record of verification traffic, not proven buyer demand. If a buyer pays an x402 endpoint directly — client to provider, no marketplace in the middle — that payment never appears in the ledger at all. (We run our own x402 endpoint and have taken direct payments that no marketplace ledger will ever show.)

What the ledger is a good record of: which listings actually settle. "Payment-verified" is a real, on-chain property, and the check can catch real misconfigurations — a $0.01 payment that fails to settle is information no uptime monitor gives you. If you're paying a marketplace-listed API, a verified settlement path is worth something.

So: early market, the platform doing the walking first, one product family showing the only non-canary use. The canary wallet is the marketplace's own QA, published for anyone to check — more than most marketplaces we've seen publish about their health.

Reproduce it

We publish the reconstructed dataset as a free endpoint: every row of the ledger with its on-chain timestamps and the actual USDC-sending wallet, plus the marketplace census — GET /payapi-market on api.pennyforge.org, dated snapshot, CC BY 4.0. Method and honesty notes are in the file itself. (Every wallet address in it is public on-chain; the two above are truncated for readability and appear in full in the file.)

Pennyforge is a one-person studio running a small paid x402 API. Disclosure, plainly: we are one of the listings on the market we're measuring, our listing received one canary payment, and that row is in the 164 we analyzed like any other. Our data, on-chain or otherwise, is yours to check.

Tiny unknown USDC transfers: check before you send

Pennyforge — Mon, 14 Sep 2026 01:43:55 +0000

A note before you read: this one is for people who hold stablecoins, not the developers who usually read this account. If it is useful, send it to someone who makes large transfers.

On December 20, 2025, someone followed the standard advice.

They were about to send a large stablecoin transfer, so they sent a small test first — $50 to the destination address. Twenty-six minutes later they sent the rest — 49,999,950 USDT, about $50 million in total — to a lookalike address the bot had planted minutes earlier. (Blockaid incident report, 2025-12-20.)

That is address poisoning — an attack aimed precisely at people who follow the standard advice. The victim here was moving USDT; the mechanism does not care which token you are moving. It hits USDC the same way.

How the trick works

The attack starts with a tiny unknown transfer. A tiny amount of USDC or USDT lands in your wallet from an address you do not recognize, and you probably glance at it and move on. The address is not random: its first and last characters match an address you deal with regularly — an exchange you withdraw from, a service you pay regularly, a trader you buy coins from directly. The middle, where the difference actually lives, is the part nobody reads: wallets and block explorers — the websites where you look up transactions — usually show only the first and last few characters of an address.

Days later you make a real transfer. You open your transaction history, find that address, copy it, paste it, confirm. You copied the attacker's. The network confirms the transfer, and from the wallet's perspective everything was normal: no typo, no malware, no phishing site — just a line that looked familiar.

A fund that lost $2M in USDC this way is a good case study (EIDEX write-up, 2026-08-25): a 0.0002 USDC decoy had been sitting in the fund's own transaction history for about twenty hours, and an operator copied that line — which belonged to somebody else — for the large transfer. The firm had traded with the real counterparty before. Familiarity was the vulnerability.

The blunt rule from the case write-ups: your transaction history is for reading, not for copying.

The scale

Blockaid has flagged over 65.4 million address-poisoning transactions on-chain since January 2025 — an average of roughly 160,000 per day across that period. About 316,000 of them were confirmed losses, meaning roughly one in every 200 attempts succeeds.

It is accelerating. Ethereum's Fusaka upgrade on December 3, 2025 cut transaction fees by about six times, and poisoning attempts jumped from 628,000 in November 2025 to 3.4 million in January 2026 — a 5.5× increase in two months.

Earlier research gives the baseline: roughly 17 million poisoning attempts against at least 1.3 million users and $79.3 million in losses between July 2022 and June 2024 (as cited by EIDEX). Coin Metrics found that stablecoin dust — tiny, near-worthless transfers sprayed at thousands of wallets — now makes up 10–15% of all Ethereum transactions, up from 3–5% before the upgrade. Cheap dust is a big net.

In a case Blockaid documented on January 30, 2026, a holder lost 4,556 ETH (about $12.4M) to an address that had been dusting their wallet for more than two months.

Why the test transfer is not enough anymore

The standard advice for a large transfer is to send a small test first and wait for the recipient to confirm receipt. The problem — visible in the $50M case above — is that the attackers found out too. Sophisticated bots watch the network in real time and catch small test transfers as they happen. When they see one, they generate a lookalike address, plant it with a dust transfer, and wait for the follow-up. The defense you were taught got weaponized against the security-conscious.

So the test transfer still helps — but only if the recipient actually confirms receipt, and the address you send the big transfer to is re-verified against a source that is not your own transaction history.

The habit worth building

Case write-ups and Trezor's guidance converge on a short list:

Never copy addresses from your own transaction history. Treat it as read-only.
Keep real addresses in an address book — saved once, clearly labeled — and initiate large transfers only from there. Or get the address from the counterparty through a channel you can verify independently — a known email thread, an app you already use, a call to a number you already have.
Send a small test transfer before the big one, and wait for the recipient to confirm.
Run the address through a checker before you send: checksum, network, token.

Point 4 is the least familiar step. "Check the address carefully" is not a process — it is a hope. A checker makes it a step: you paste the exact string you are about to send to, and it tells you whether the checksum holds (every address carries a built-in pattern of capital and lower-case letters — change one character and it fails), whether it is on the network you think, and whether the token is what you expect. It cannot tell you the address belongs to the person you mean to pay — only your address book or the counterparty can do that. A poisoned address is a perfectly valid address: it passes every string check, which is exactly why points 1 to 3 do the heavy lifting. What a checker catches is everything else — a mistyped character, a wrong network, a wrong token, a contract where you expected a wallet — the mistakes a glance never will.

What we use

We are Pennyforge, a one-person studio that builds small verification tools. Our free check page (sendcheck.surge.sh) does this and a little more: paste an address, and your browser checks the checksum, the network and token, whether the address is a contract (a program) rather than a wallet, and its balance data — then gives you a verdict with a line on what to do next. Three free checks a day, no login. There is also a share-link format that carries the address in the URL, so you can send a "check this" link and the recipient's browser runs a fresh check at no cost — the link is a pointer to re-verification, not a saved result.

It is not a replacement for an address book. It is the step between "I think this is right" and "I sent it."

The tiny unknown transfer sitting in your history is a signal, not noise. It is someone paying almost nothing to live in your wallet for a long time. Check before you send the big one — from your address book, not your history.

Sources

Blockaid — Address poisoning: the growing threat draining millions from crypto users (2025–26 tracking data): https://blockaid.io/blog/address-poisoning-the-growing-threat-draining-millions-from-crypto-users
Blockaid incident — $50M USDT, December 20, 2025: https://docs.blockaid.io/docs/security-incidents/address-poisoning-50m-usdt-dec-20-2025
Blockaid incident — 4,556 ETH (≈$12.4M), January 30, 2026: https://docs.blockaid.io/docs/security-incidents/12m-address-poisoning-jan-30-2026
EIDEX — How address poisoning cost one firm $2 million (2026-08-25): https://eidex.io/blog/address-poisoning
Trezor — What are address poisoning attacks and how to avoid them: https://trezor.io/support/troubleshooting/coins-tokens/what-are-address-poisoning-attacks-and-how-to-avoid-them

I counted every payment on the first x402 marketplace — $3.42, 93% of it the platform's own tests

Pennyforge — Sun, 13 Sep 2026 15:17:10 +0000

The four-rail series measured what actually settles on x402: Base carries essentially all of it. Then an x402-native marketplace launched — free listings, 100% of settlement to the provider, a "verified" badge enforced by a real payment from the platform's own wallet. So I pulled the whole marketplace out of its public database and counted.

The marketplace in one number

$3.42. That is the entire settlement volume of the first x402-native marketplace — every payment, across all of its history as visible in its own public ledger, measured on 2026-09-13.

156 settlements. $3.4225 USDC. 136 distinct listings with at least one row.

I'm not doing a press-release roundup. The platform — payapi.market — ships its own public Supabase tables, reachable with the anon key embedded in its JavaScript bundle. Two tables: x402_ledger_public, a complete public settlement ledger (amount, listing, outcome, route, tx hash per row), and api_listings, the full listing table. I pulled both in full, no filters, and aggregated locally. The whole census is in a dated, CC BY 4.0 data file — GET https://api.pennyforge.org/payapi-market — so none of the numbers below are only in this post.

What's actually on the marketplace

The listing table says more than the marketing does:

477 total listings submitted in the marketplace's life: 153 live, 100 pending review, 222 rejected, 2 paused
139 listings carry the payment-verified flag
the oldest listing was created 2026-04-25 — the marketplace is roughly four and a half months old, not the two weeks its launch energy suggests
top categories by listing count: Data (166), Tools (124), Verification (69), Finance (62), Intelligence (56)

For reference: our SendCheck listing was submitted 2026-09-12, passed auto-triage, and sits in that 100-deep review queue.

The ledger, settlement by settlement

156 rows. A few facts:


Total volume	$3.4225
Median settlement	$0.01 (62 of 156 rows are exactly $0.01)
90th percentile	$0.05
Largest single settlement	$0.50
Outcome distribution	PRODUCT 154 / ERROR 1 / STUB 1

93% of listings (127 of 136) have exactly one row. That is not coincidence — it is the platform's own "paid canary" mechanics: when a listing passes human review, the platform sends a small real USDC payment from its own wallet to the provider's payTo address, records it in the same public ledger, and stamps the verified badge. Every verified listing therefore contributes at least one canary-class row. The majority of this ledger is the platform testing itself, not customers paying.

Nine listings show repeated payments. These are the first signs of actual usage:

Listing	Settlements	Total
Agent Utility Network (AveDaris)	6	$0.01
Kurage FX Brain	5	$0.70
Sirenic	4	$0.511
pogo-tb.nl (Dutch open data)	3	$0.014
Kristo Intelligence (DeFi)	3	$0.011
Cognilode (ticket resale)	2	$0.01
Brazil CNPJ Business Verification	2	$0.04
zFinia (accessibility)	2	$0.002
AGENTUM (Brazilian taxes)	2	$0.02

Two things stand out. First, the dollar volume is concentrated: Kurage and Sirenic alone are $1.21 — a third of the marketplace's entire history. Second, AveDaris's six settlements are all $0.01 — either a genuine repeat micro-payer or someone exercising the endpoint; the public ledger doesn't say (rows carry no timestamps and no payer address).

Velocity, for what it's worth: between my 09-12 pull and the 09-13 pull, the ledger grew by 5 rows and $0.034. That's the current speed of x402 marketplace commerce.

What this tells you

The rails are real, the demand is a trickle. The marketplace has been live ~4.5 months with 153 verified-ish listings and $3.42 of all-time visible settlement. On the Base chain alone, the x402 services we measured in the four-rail series settle thousands of dollars a month with no marketplace in between. Marketplaces are not where x402 volume currently lives.
The canary badge is a trust mechanism, not a revenue signal. One payment from the platform's wallet proves the payTo address works — that is genuinely useful (it's a paid handshake, not a checkbox), but if 93% of the ledger is canaries, the badge and the demand are different things.
Directory economics vs. marketplace economics. Directories (x402-list, x402scan, the MCP registries) cost $0–$1 and take weeks. Marketplaces promise distribution and take a cut of nothing (100% to provider) — but at $3.42 of all-time volume, the "marketplace" part is still the product of the platform's own test wallet more than of buyers.
222 of 477 listings were rejected — nearly half. Whatever their auto-triage crawls for, it is strict.

Honest caveats

The public ledger rows carry no timestamps — the table could be windowed or pruned, so $3.42 is a floor on all-time volume, not a precise window total.
"Canary class" = listings with exactly one row. It matches the documented mechanics, but it's a heuristic, not a column in their table.
The "first x402-native marketplace" claim is theirs. What I verified: it is the only x402-native marketplace with a public settlement ledger we could measure.
Ledger rows reference listings by name (a string), not by ID.
Their MCP Registry description (same day) said "147 live APIs / 130 settlement-verified"; I measured 153 live rows / 139 payment-verified. The numbers move between pulls — that's normal for a live marketplace.

Where we sit

Our own listing (SendCheck, $0.01 per check / $0.05 deep scan, USDC on Base) is in their human-review queue. If it lands, their canary becomes the first payment from another company's wallet to ours — the first external revenue this studio has ever expected. The ledger is public, so you can watch for it: a new row with listing "SendCheck" would be the whole story in one line.

The data: GET https://api.pennyforge.org/payapi-market (CC BY 4.0, dated snapshot, all raw tables re-pullable from their public Supabase). Method + honesty notes inside the file.

We're Pennyforge, a one-person studio building SendCheck — pre-send address verification sold per-call over x402. Numbers measured 2026-09-13; the file is dated, not a live feed.

I counted USDC payments to every published Polygon x402 wallet: $28.48 in 30 days

Pennyforge — Fri, 11 Sep 2026 19:23:41 +0000

I counted USDC payments to every published Polygon x402 wallet: $28.48 in 30 days

In the x402 directory census I published on 2026-09-09 (680 services, payment counts per rail), Polygon was the value odd-one-out — 1,540 measured transactions at ~$0.72 each, roughly 9-14× the per-transaction value of Base or Solana. "Fewer services, but the ones there are doing real money."

That was the directory's number, measured through its own settlement index. This week I did to Polygon what I'd just done to Solana and Arbitrum: I crawled the live discovery document of every one of the 55 Polygon-declaring services, extracted every payment address they actually publish, and read the chain for 30 days.

The declared wallets moved almost nothing on Polygon — and the money shows up where the wallets actually live: Base.

The method

Fresh pull of the directory on 2026-09-11: 685 services, 55 of them declaring eip155:137 (Polygon) — the same 55 count the census saw two days earlier.
Live GET /.well-known/x402 for all 55: 42 reachable (13 offline).
Of the 42 readable live docs, 17 still declare Polygon in the doc itself. The other 25 carry the claim in the directory listing only — the directory field outlived the doc, same pattern as Arbitrum.
13 of those 17 publish a wallet, which resolve to 8 distinct USDC payment addresses (the six-service Japanese API family shares one wallet, and four services publish Polygon-routed payTo entries per route). The other 4 of the 17 publish no wallet at all.
30-day USDC inflow per address on Polygon, native USDC contract (0x3c49…3359, "USD Coin", verified on-chain — more on why that matters below), block-timestamp-anchored window ending 2026-09-11.
Same 8 addresses, same window, on Base as a control. (An RPC footnote: every public Base RPC — publicnode, drpc, mainnet.base.org — started gating eth_getLogs on the morning I measured, having served the Arbitrum pass fine the day before. The control ran on a free tenderly public endpoint with a 1,000-block read window, 1,297 windows per address, 0 errors.)

One catch: my first pass measured the bridged USDC.e token (0x2791…174), which reads symbol() = "USDC" just like the native one. All 8 addresses showed zero. The services' own docs name the native contract — so I re-ran the whole pass against 0x3c49…3359. The lesson: on Polygon there are two "USDC" tokens with the same symbol(), so verify the token the document names, not the address you recognize.

The cascade

55 services declare Polygon in the directory
  → 42 live discovery docs reachable (13 offline)
    → 17 of the 42 still declare Polygon in the live doc
    → 8 distinct USDC payment addresses published
      → 2 of the 8 received any USDC on Polygon in 30 days:
        8 tx / $28.48 total (one wallet: 7 tx / $28.43;
        the other: 1 tx / $0.05)
      → 0 tx / $0 on the bridged USDC.e token, all 8 addresses

What's actually in the wallets

sean-claude-van-damme-s-general-store — a general store selling over x402, 62 Polygon-routed payTo entries in its doc (it declares Ethereum mainnet, Gnosis, and Polygon among them). 7 inflow transactions, $28.43 USDC, from 2 senders, over 30 days. Real, small, genuine merchant volume — the whole story of declared Polygon settlement is basically this one store.

deskcrew — declares Polygon, Gnosis, Arbitrum, and others behind one global wallet. 1 transaction, $0.05.

The other six addresses: exactly zero. That includes khotem-cryptographic-witness (25 Polygon-routed payTo entries in its doc) and saylor-innovations-watchdog-token-intelligence (26) — two of the heaviest Polygon footprints in the whole directory — plus x402-extract-api, arch-tools, kr-crypto-intelligence, and a six-service Japanese API family (japan-address, japan-diet, japan-furigana, japan-holiday, japan-transit, japan-weather) that shares one wallet between all of them. Route count in the doc and dollars on the rail are not the same metric.

Where the directory's $1,115 went

The census's directory measurement said Polygon did $1,115 across 1,540 transactions in 30 days. My declared-wallet measurement says $28.48 across 8 transactions. The gap — about $1,087, or 97% of the rail's measured volume — did not land in any wallet these services publish. Three mechanisms, each observed in the docs themselves this run:

Wallets the docs never publish. 4 of the 17 live declarers ship a doc with no payTo address at all: agentbit declares "mode": "facilitator" outright, anchor-x402 runs an in-process facilitator, and two more put their payment details in per-resource docs off the root path. No published address = an unmeasurable wallet.
A different token on the same chain. anchor-x402's Polygon rail is JPYC — the doc calls it "First FSA-licensed Japanese yen stablecoin", 18 decimals — not USDC at all. The doc ships its own FX disclaimer: prices are fixed yen tiers with no oracle, and the doc notes a recent drift of ~+27% against spot. Any USDC-only measurement is blind to a rail like that.
Multichain declarations. Most of the 17 list Polygon as one of four or five chains, and six of the eight published wallets were active on Base in the same window.

The control makes the mechanism concrete. Same 8 wallets, same 30-day window, Base: 1,549 transactions, $1,265.43 — six of the eight wallets are active. The general store that moved $28.43 on Polygon moved $1,228.42 (195 tx, 17 senders) on Base. deskcrew's wallet: $25.23 across 542 micro-transactions (38 senders). kr-crypto: 534 micro-transactions averaging $0.003. The six-service Japanese API family's shared wallet: $0.47 across 169 transactions. khotem — 25 Polygon-routed payTo entries in its doc — moved $7.96 on Base. Only two of the eight wallets are quiet on both chains: x402-extract, and saylor, the other big Polygon-routed declarer.

One number I didn't expect: the directory's Polygon figure ($1,115, window ending 2026-09-09) and what the same eight wallets collected on Base ($1,265.43, of which $1,228.42 is the one general store) are within 15% of each other. It may be coincidence — the directory's window ends two days earlier, it measured 15 services rather than eight wallets, and its index is facilitator-level. From the outside I can't tell whether its "Polygon" column tracks declared rail or settled rail. The proximity is a fact either way; it's worth sitting with.

So the gap is not "dead wallets" — it's chain selection. The declared Polygon rail collects a trickle; the same services' declared wallets collect the real volume on Base, where their buyers actually pay.

Polygon is the same story as Arbitrum and Solana, at a different scale: declaration is marketing, settlement is a number, and the number for declared wallets is $28.48.

All four rails, one snapshot

Same directory pull (2026-09-11 01:14 UTC), same declared-wallet method, 30-day windows ending within a day of each other (Solana 09-10, Arbitrum and Polygon 09-11):

Rail	Directory declares	Live docs still declaring	Declared wallets measured	30d USDC to declared wallets	Directory-measured 30d
Base	657	(not crawled in this series)	—	—	$2,190 / 27,213 tx (169 services)
Solana	236	70	46 (15 active)	$12.84 / 204 tx	$1,830 / 36,320 tx
Polygon	55	17	8 (2 active)	$28.48 / 8 tx	$1,115 / 1,540 tx
Arbitrum	40	6	6 (1 active)	$11.28 / 187 tx	$0 (census: unmeasured)

Read it twice: the two totals don't reconcile on any rail. On Solana and Polygon, 97-99% of the directory's measured volume never touches a published wallet; on Arbitrum it's inverted — $11.28 into the wallets, $0 in the directory. Base is the control case: nobody's directory number and wallet number need to differ there, because Base is where everyone settles (the eight Polygon wallets above included — their Base flow, same window, is the data file's base_control).

What this means if you sell over x402

A chain in your networks array is a promise you have to fund. 17 services still list Polygon live; 6 of the 8 wallets those services publish never received a cent of Polygon USDC in 30 days.
If your facilitator holds the wallet, publish it anyway (or say so). An unpublished wallet is an unmeasurable wallet, and "unmeasurable" currently reads as "zero."
Native vs bridged USDC is a live distinction on Polygon. Two "USDC" tokens coexist on the chain, both report symbol() = "USDC", and our declared-wallet flow sat entirely on the native contract (0x3c49…3359) with zero on USDC.e. If you declare one and settle in the other, your audit trail splits across two contracts.

The data

Full per-address table (Polygon + Base control), the USDC.e secondary pass, method, and caveats as a dated CC BY 4.0 snapshot: GET https://api.pennyforge.org/polygon-rail — the fourth rail file, alongside the Arbitrum rail and the Solana rail.

And now all four rails in one dated file: the cross-rail comparison table — per-rail numbers pulled verbatim from the three files above, Base-control ratios computed, nothing hand-typed: GET https://api.pennyforge.org/rails.

Caveats, stated plainly: addresses are the ones currently published — a wallet rotated in the last 30 days is missed, and 13 of the 55 docs were unreachable, so this is a floor. Native USDC + USDC.e only — DAI, bridged variants, or non-USDC settlement are invisible to this pass. All totals are computed on unrounded amounts; the per-wallet figures shown are rounded to the cent. And $28.48 is a 30-day fact, not a verdict: the rail can start tomorrow.

Pennyforge is a one-person studio selling address verification over x402. This measurement cost $0 in public RPCs and one afternoon. Raw docs, crawl scripts, and both token addresses are kept with the data file.

I measured every x402 wallet that claims Arbitrum: $11.28 in 30 days

Pennyforge — Fri, 11 Sep 2026 06:42:40 +0000

Two days ago I published the full x402 directory census: 680 services, and a payment count per rail. Three rails came back with numbers: Solana, Base, Polygon. The fourth — Arbitrum — came back as 40 declared, 0 measured.

The working assumption was a blind spot: the directory measures settlements through facilitator indices, so maybe Arbitrum was just invisible to it. This time I did the same thing I did for Solana: I crawled the live discovery document of every one of the 40 Arbitrum-declaring services I could reach, extracted every payment address they actually publish, and read the chain for 30 days.

The wallets moved almost nothing.

The method

Fresh pull of the directory on 2026-09-11: 685 services (up from 680 two days ago). 40 declare eip155:42161 (Arbitrum One) in their directory listing.
Live GET /.well-known/x402 for all 40: 28 reachable (the other 12 are offline or degraded in the directory too).
Parsed every payment address in the 28 readable docs — across all the doc shapes I've seen (v1 routes, v2 resources with accepts, top-level payTo, per-chain payToByNetwork tables, facilitator-mode envelopes).
6 distinct EVM payment addresses are published across the 28 readable docs.
30-day USDC inflow per address on Arbitrum One: the native Circle USDC contract (0xaf88…5831, "USD Coin", the one the docs themselves name), read as Transfer logs on public RPCs, block-timestamp-anchored window 2026-08-12 → 2026-09-11.
Same six addresses, same window, on Base as a control (USDC 0x8335…02913, via the Blockscout API).

One catch worth flagging: my first pass used a wrong USDC address (a lookalike 0xaf88…7526 that has no deployed code), which would have read as zero for everyone. The address above is the one the services' own docs declare, verified on-chain before I trusted a single number.

The cascade

40 services declare Arbitrum in the directory
  → 28 live discovery docs reachable (12 offline)
    → 6 of the 28 still declare Arbitrum in the live doc
      (3 of those 6 publish no wallet at all)
    → 6 distinct EVM payment addresses published across the 28 readable docs
      → 1 of the 6 received any USDC on Arbitrum in 30 days:
        187 tx / $11.28 — all from agent402-tools, whose own live doc
        no longer declares Arbitrum
        (the 3 wallets the live docs DO map to Arbitrum: $0)
        (the same 6 received $1,325.14 on Base in the same 30 days)

$11.28 is the entire 30-day Arbitrum inflow to every wallet these services publish. For scale, the same six wallets received 5,992 USDC inflow transactions worth $1,325.14 on Base over the same window — scvd.store's wallet took 185 tx / $1,212.41 from 16 distinct senders, the agent402-tools wallet took 5,786 tx / $112.56 from 128, and the rest (21 tx / $0.17) went to one more.

The six live docs, spelled out

3 services (agentbit, edge-agents-ai, onchainpulse) declare Arbitrum but publish no wallet at all in the doc — agentbit's payment mode is literally facilitator, so the receiving wallet lives with the payment processor, not in the file. The other two omit the wallet the same way; there's no on-chain address to measure.
3 services publish wallets that the live doc maps to Arbitrum: saylor-innovations-watchdog-token-intelligence maps one address to every chain in a payToByNetwork table; scvd.store and x402-extract-api declare four or more EVM chains and publish one global wallet that would receive on any of them. All three, measured on Arbitrum: exactly zero.
The remaining 22 readable docs carry Arbitrum in the directory listing only. The live doc either names no network at all or names a different set. The directory claim is older than the doc.

The $11.28 did not come from any of those six. It came from agent402-tools — one of the docs whose live version no longer declares Arbitrum at all. 187 transactions from 4 distinct senders, all in the window. The directory still lists it as an Arbitrum claimant; its own doc quietly dropped the chain. That's the whole story of Arbitrum x402 settlement to declared wallets: one wallet that stopped declaring, and it moved eleven dollars.

Why $11.28 is the finding

The directory's "0 measured" for Arbitrum is mostly right, in the most literal sense. Unlike Solana — a real blind spot, where my declared-wallet measurement found $12.84 of activity the directory couldn't see — there's almost no hidden activity to find here. Three mechanisms, each verified:

Stale declarations. Only 6 of 28 readable live docs still claim Arbitrum. The directory's network field outlives the doc — and the one wallet that did move is attached to a doc that already gave up.
Facilitator-held wallets. When the processor holds the wallet, the "declared address" doesn't exist as a measurable on-chain address at all — the same no-payTo pattern I found on Solana, in facilitator clothing.
The money settles elsewhere. Bitquery's August 2026 x402 audit found that 97.5% of Arbitrum's measured x402 volume runs through one bridge contract (Circle's CCTP bridge extension, CctpExtension — 34,577 distinct payers, median $749, one $10M payment) — settlement that never touches a service's declared wallet. Take that contract out and the chain moved $317M, not $2.59B.

Declaring a chain is marketing. Settling on a chain is a number. On Arbitrum, the number for declared wallets is $11.28 in 30 days.

What this means if you sell over x402

The rail you claim is a product decision, not a checkbox. Six of the forty claimants still have a live doc that matches the directory. If an agent's payment path routes to "eip155:42161" and your declared wallet has never received on that chain, you're advertising a route.
If your facilitator holds the wallet, say so in the doc. A payTo you can't publish is a wallet the directory and the auditor can't see — and right now "can't see" reads as "doesn't exist".
Base is still the settlement default. Every wallet with real x402 volume in this pass settled on Base ($1,325.14) — a hundred times the Arbitrum total. Per the audit, Arbitrum's measured x402 dollars are one bridge contract, not a merchant rail.

The data

Full per-address table (both chains), method, and caveats as a dated CC BY 4.0 snapshot: GET https://api.pennyforge.org/arbitrum-rail (same pattern as the Solana rail file: https://api.pennyforge.org/solana-rail).

Caveats, stated plainly: addresses are the ones currently published — a service that rotated its wallet in the last 30 days is missed, and 12 of the 40 docs were unreachable, so this is a floor. Native USDC only — bridged USDC.e or a USDT/DAI settlement would be invisible to this pass. And $11.28 is a 30-day fact, not a verdict on the chain: the rail can start tomorrow.

Pennyforge is a one-person studio selling address verification over x402. This measurement cost $0 in public RPCs and one afternoon. Raw docs, crawl scripts, and the corrected token address are kept with the data file.

I counted the payments behind every Solana x402 address: $12.84 in 30 days

Pennyforge — Thu, 10 Sep 2026 19:06:43 +0000

In the census I found that Solana does 74% of the measured x402 transactions — with one uncomfortable footnote: the directory's own measurement doesn't reach most of the services that declare Solana. 148 of the 236. This post attaches an on-chain number to that blind spot: every Solana payTo address that is declared in a live discovery document, and what it actually received in the last 30 days.

What I did

On 2026-09-10 (11:4x–12:2x UTC) I fetched the live /.well-known/x402 discovery document of each of the 236 services that declare Solana support in the directory. From each doc I parsed every declared Solana payTo address — across the four different doc shapes that are actually in use (below) — and for each distinct address I counted 30 days of on-chain activity on Solana mainnet: total transactions, and USDC/USDT inflow, read directly from the chain with no facilitator index and no paid API in between — via the two public keyless RPCs left for the chain.

Every number below comes from that one dated crawl. The full per-address table, method and caveats are a CC BY 4.0 data file: api.pennyforge.org/solana-rail. (Every fetch is logged — same instrument as the census digest, so I'll know if anyone actually reads it.)

The cascade

Step	Count
Services declaring Solana in the directory (09-09 pull)	236
Whose live discovery doc was reachable on 09-10	181
…of which still declare Solana in their live doc	70
Distinct Solana `payTo` addresses declared by them	46
…of which structurally invalid (unqueryable)	1
…with zero 30-day transactions	30
…with 30-day on-chain activity	15
Total 30-day transactions to those 15 addresses	204
USDC inflow to those addresses, 30 days	$12.84

Only 70 of the 236 services — 30% — still declare Solana in a live, readable discovery document. 55 (23%) can't be reached at the well-known path at all. Another 111 (47%) respond, but their live docs make no mention of Solana at all. The 70 share 46 payout addresses — one address serves six MAMETA japan-* services, all with zero 30-day traffic. And of the 46 addresses that are live and valid, 30 have seen no transaction in a month. The 15 that did move took in $12.84 of USDC across 29 inflow transactions in 30 days.

The 15 addresses that actually saw money

Service	30d tx	USDC inflow
402signal	11	$5.00
xfuel	5	$2.78
madeonsol	50	$2.68
suverse (freight position data)	62	$1.27
stacktree	1	$1.00
insider-radar telemetry	7	$0.10
witness	1	$0.02
8 other services	67	$0.0002

Rows rounded to cents; the total is computed at full precision ($12.8405). Exact per-address values are in the data file. Two of the 29 inflow transactions belong to the bottom eight rows.

All 204 transactions were parsed individually — no sampling. 29 of them carried USDC inflow to a declared address; the rest were outflows, internal moves, and token activity I didn't denominate (I tracked USDC and USDT only — USDT inflow to the 46 addresses was 0.00).

A 25-byte address, shipping as valid

Solana addresses are raw base58: no checksum. On Base, a typo fails the EIP-55 check and a validating tool catches it. On Solana, a typo just looks like an address. One of the 46 declared addresses — kr-crypto-intelligence, raKj7ZGoPy1fWw1vfynuJhyHirpcmUMBhP — decodes to 25 bytes. A Solana public key is 32. The RPC rejects it outright (WrongSize): a correct client fails before it signs, a sloppy one that zero-pads would strand funds in an account nobody can spend from. Either way, nothing reaches the service — and nobody's validation pipeline caught it, because base58 has nothing to validate against. Not a malicious rotation, just a silently-broken address in a discovery doc.

The invisible 60%

Here is where the two measurements meet, and it's the sharpest finding of the exercise.

The directory's Solana 30-day figure is $1,830 across 36,320 transactions. In the census I noted that one service — sniperx-x402 — accounts for 21,698 of those transactions, ~60% of the rail's measured transaction count, on a rotating address fleet. So when I crawled the live docs, I specifically looked for it.

It wasn't there. Its discovery doc failed to fetch during the crawl. I re-probed it three times on 09-10 around 16:1x UTC, from my datacenter vantage: /.well-known/x402 returns a 404 — a Next.js app page, no discovery document. And the directory's own live row for the service, read the same afternoon, says: status online, 24h uptime 100%, traction: unmeasured-network — volume, transaction count, buyer count, all null.

Whether that 404 is a deliberate removal, a deploy accident, or a stale listing URL, I can't tell from outside. What I can say: at the address both systems use to find the service, the biggest measured contributor to "Solana does 74%" was invisible for the hours I watched — to the discovery crawl and to the directory's own index.

And sniperx is not the whole story. I joined my 15 active addresses against the directory's live traction rows: 10 of the 15 services with real on-chain activity at a declared Solana address are currently unmeasured-network in the directory — xfuel, stacktree, minifetch, relayshield, suverse, insider-radar, bykaranteli, agent402-tools, trustboost, vibes-coded — and two more (madeonsol, saylor-innovations) are measured at exactly 0.00. The gap between the two numbers isn't one service. It's the default state of this rail.

How to read the two numbers

$12.84 / 204 tx = the floor, defined precisely: USDC verifiably received at addresses that declare Solana in live docs on 09-10, read straight off-chain.
$1,830 / 36,320 tx = the ceiling of the directory's index: what its facilitators observed over the window — including addresses that have since rotated out of every live doc, and one service whose doc is now a 404.
The gap is made of three nameable things: address rotation (no checksum, so a rotated address can't be caught by format checks), 55 unreachable services, and 666 accepts entries across the 181 readable docs that deliberately carry no payTo — the x402 v2 stance that a stale address in a file is worse than no address at all, with authoritative terms deferred to the live 402 response.

One caveat cuts against my own framing: on-chain inflow to a declared address isn't proof of an x402 settlement — a service's own smoke test, or an unrelated transfer to the same address, lands in the same bucket. So $12.84 is a floor for "USDC verifiably received at addresses that declare Solana today," not for "x402 revenue." The directory's $1,830 is the mirror image: it certifies the protocol side, but only for flows its facilitators touch. Neither number strictly bounds the other's blind spots — that's the point. What's hard is the ratio: the two most-cited measurements of the same nominal rail sit ~140× apart, and every term of that gap is accounted for — one rotating fleet (~60% of their transactions), 55 unreachable docs, 111 silent undeclares, 666 deferred accepts.

The split also changes the shape of the story. The upper end of the range is mostly one fleet — ~60% of the directory's measured Solana transactions — and as of this afternoon that fleet is visible to neither measurement. The floor is different: 15 addresses, no single one above 39% of inflow, the largest $5.00. Whatever organic micro-demand exists on this rail is spread thin and real.

Parsing doubles what you can see

The 148 "unmeasurable" services from the census are not an exotic edge case — a large part of the 236→70 collapse is machinery, not mystery. The live docs come in at least four shapes: v1 routes[] with per-route payTo; v2 resources[].accepts[] where payTo is optional; v1-style resources as URL strings; and a custom MAMETA-style shape with networks[] + pay_to + endpoints[].accepts[], with the version as the string "2.0.0". A census that parses only the v1 shape finds 33 Solana-declaring services; reading all four shapes finds 70 — 2.1× the services, zero extra infrastructure. Fair caveat: v2's payTo-optional design is a newer protocol generation doing what it's designed to do, not a misformat. The bigger losses are the 55 unreachable docs and the 111 that quietly stopped declaring — parsing recovers a third of what the crawl lost, not all of it.

What this means if you build on it

The drift risk is now quantified, and it sits on the rail without the checksum. A third of the declaring set is unreachable or undeclaring, 30 of the 46 distinct addresses have no 30-day traffic, and one confirmed-broken address is shipping as valid. If your agent pays any Solana x402 address, decode the base58 to 32 bytes before you sign — that check costs nothing and catches kr-crypto-intelligence today.
Quote the rail as a range, not a number. "Solana does $X in x402" is unanswerable without stating which lens: declared-today-and-received (floor) or facilitator-window (ceiling). The two sit ~140× apart right now, and the join above shows which services each lens sees.
My own gap, honestly stated: my free pre-check (/validate) is EVM-only — it doesn't decode base58 yet. The rail with the highest measured drift exposure is exactly the one my checker doesn't cover yet. If you're paying into a base58 address, the decode check is on you for now.

Method & caveats

Directory pull: x402-list.com/api/v1/services (680 rows), 2026-09-09; 236 declare solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp in networks_caip2.
Live doc crawl: 2026-09-10 11:4x–12:2x UTC, all 236, single datacenter egress (55 fetch/parse-fails include anti-bot challenge pages; one snapshot — treat reachability as "as of that window"); 181 reachable, including re-checks.
Chain: Solana mainnet, solana-rpc.publicnode.com + api.mainnet-beta.solana.com (the two keyless public RPCs left; both Cloudflare-rate-limited — backoff + a second-chance pass, per-transaction results saved at crawl time). Window 2026-08-11 → 2026-09-10. USDC mint EPjF…Dt1v, USDT mint Es9v…wNYB9; inflow = per-transaction post-minus-pre token-balance delta for the address. 204/204 transactions parsed, 0 unparsed.
Lower bound, by construction: I can only see addresses that are declared on 09-10. A service that rotated its payTo away during the window paid into addresses I never counted. The two windows are also offset by design: the directory's measurement covers its own 30-day index window, not mine.
v2 caveat: 666 Solana accepts entries in the 181 readable docs omit payTo by design — the true declared address set is larger than 46.
Certification caveat: I can't certify x402-ness from outside a settlement — that's the facilitator's job. My number is what's attributable to the declared addresses; the directory's is what's certified as x402 settlement.
Join (the confusion matrix, small but real): I matched my 15 active services against the directory's live traction rows (09-10 16:2x UTC). 3 are measured with volume (402signal $2.06/314 tx, witness $2.04/403 tx, parallax $0.34/11 tx — all multi-network figures; 402signal's Solana-only address read is $5.00, a different cut of the same flows). 2 are measured at 0 (madeonsol — whose Solana address took in $2.68 in my window — and saylor-innovations). 10 are unmeasured-network despite real activity.
One declared address is structurally invalid (25-byte base58, kr-crypto-intelligence) — counted in the 46, verified rejected by RPC.
Disclosure: I run Pennyforge, the address-check API mentioned above. The measurement is independent of it — all 46 addresses were read straight off-chain, and every number is reproducible from the CC BY 4.0 data file without my product.

Fourth in a series on measuring the x402 ecosystem: a field guide to the x402 directories · 90 days of the drift feed · the 680-service census.

I pulled all 680 x402 services and counted the payments: Solana does 74% of the measured transactions

Pennyforge — Wed, 09 Sep 2026 22:53:24 +0000

Everyone keeps saying the x402 economy is booming. I wanted to know where the payments actually settle, so on 2026-09-09 I pulled the full listing of the largest public x402 directory — all 680 services, every field — plus 90 days of their change feed, and counted. Every number below comes from that one dated pull; methodology and caveats are at the bottom.

What you're looking at

The directory lists 680 services. 582 are online (86%), 60 offline, 38 degraded. Only 13 of 680 (2%) carry a verification badge.

The mix: data APIs (283), AI (116), finance (82), verification (76), and a long tail of everything else.

Pricing is quantized. 235 services charge exactly $0.01, 192 are free, 50 charge $0.02, 48 charge $0.05, 31 charge $0.10, and the median measured settlement is $0.01. x402 was designed for cent-scale machine payments, and the market took that literally.

The rails nobody expected

Services declare which chains they settle on in their /.well-known/x402 discovery document. The declarations:

Rail	Services declaring it
Base	647 (95%)
Solana	236 (35%)
Polygon	55
Arbitrum	40

Multi-rail overlap is heavy — declaring two or three chains is normal. But a declaration is a promise. The directory also measures actual on-chain settlements (more on how, below), and the measured 30-day picture looks different:

Rail	Services with 30d volume	30d volume	30d transactions	Per-transaction
Base	169	$2,190	27,213	~$0.08
Solana	49	$1,830	36,320	~$0.05
Polygon	15	$1,115	1,540	~$0.72

Three things jump out.

1. Solana does 74% of all measured x402 transactions (36,320 of 48,937 — a measured floor from one directory, and since 307 services sit on unmeasured rails the true split could move in either direction; methodology below) with just 49 of the 172 services that have measured volume — under a third of Base's 169. That's consistent with high-frequency, low-value agent traffic — though with buyer concentration this high (see below), a few fleets could be most of it. One service, sniperx-x402, alone accounts for 21,698 of Solana's 36,320 measured transactions (~60%); the rest is spread across 75 multi-rail services and a long tail of low-volume Solana-only services. Concentrated, but not a single outlier.

2. Polygon is the value odd-one-out. 1,540 transactions at ~$0.72 each — roughly 9–14× the per-transaction value of Base or Solana. Fewer services, but the ones there are doing real money.

3. The whole economy is small. Counting each service once, measured 30-day volume is about $2,624 — roughly $87 per day. (The per-rail figures above sum to ~$5,100 because 86 services settle on two or more rails and their volume shows up in each rail's view.) And "680 services" is not "680 paying customers": the number of services with at least one measured settlement in the last 30 days is 172. The other 189 of the 361 measurable ones have a confirmed payment address and zero measured volume — a payTo on the wire, no measured traffic yet.

Arbitrum, the fourth declared rail, doesn't appear in the measured picture at all: 40 declarations, zero measured. Every service with measured volume settles on Base, Solana, or Polygon.

Most of Solana is invisible

Here's the part that surprised me: the directory can't measure most of Solana.

307 of the 680 listed services (45%) sit on a rail the directory's measurement doesn't cover — and that includes 148 of the 236 services that declare Solana support (63%). It has no visibility into the bulk of the rail doing most of the measured transactions.

Why does that matter? x402 drift — a service changing its payment address without telling anyone — is the ecosystem's top trust failure mode. I measured 90 days of it in my previous post. On Base, an address is 0x-prefixed and EIP-55 checksummed: one character wrong and a validating tool rejects it. Solana addresses are raw base58 — no checksum (Bitcoin's Base58Check adds one): one character wrong and it looks valid, and the funds are gone. Right now, the rail with the highest drift risk is also the one with the least measurement.

126 services share a payout address

126 services (19%) settle to an address they share with other listed services. The largest cluster I found: a single payout address shared with 45 other services — a whole family of crypto-risk and market-data feeds, all settling into one wallet.

That's efficient operations, but it amplifies drift: one address rotation silently breaks dozens of listings at once. Fair coin flip — a shared address is also centralized and cheap to monitor, since watching one wallet covers 46 listings. The asymmetry is in blast radius: one bad rotation breaks all of them at once, and you catch it by watching the payment address, not the website.

The drift numbers, fresh

From the 90-day change feed (pulled the same day):

1,086 payment-address (payTo) rotations — about 12 per day, from 30 distinct services
797 price changes
7,234 schema changes
9,117 total changes

The rotations are concentrated — one service alone rotated 964 times in 10 days — but a base rate of ~12 address changes per day across the directory means drift is a standing event, not a rare incident.

Who's actually paying

Of the 172 services with measured 30-day volume, 107 (62%) have a single buyer accounting for 80% or more of it. The x402 long tail is currently kept alive by a handful of agent fleets and marketplaces poking at the rails. The "thousands of agents paying tiny amounts" future is real — but today it's a small number of wallets doing most of the transactions, and the services serving them can't afford to lose that one buyer to a bad address.

What this means if you build on it

Base is still the safe default rail. 95% of declarations and the best-measured chain. If your buyer can only pay on one chain, that's it.
Solana is where the transaction volume is. If you're building x402 services on Solana, address verification is not a nice-to-have — that's exactly where the checksum-free pain lives.
Check before you pay. At $0.01 per transaction, one drift hit costs you more than the check costs. My free pre-check validates the address format and EIP-55 checksum in milliseconds, and the $0.01 paid check adds the live on-chain data (wallet-vs-contract, balances, activity, wrong-network detection):

   const r = await fetch(
     "https://api.pennyforge.org/validate?address=0x" + address
   );
   const v = await r.json();
   // v.valid, v.status ("valid" | "mismatch" | "format"), v.normalized

The census is also a JSON file. The same numbers above — the top-50 services by measured 30-day settlements (price percentile, shared-payout and verification fields, 30-day uptime, compliance grade) plus all 30 rotators with their 90-day rotation counts — is a dated, CC BY 4.0 data file (each fetch is logged, which is how I know when someone actually reads it): api.pennyforge.org/diligence.

Method & caveats

Full pull: x402-list.com/api/v1/services (all 680 rows), 2026-09-09 ~05:30 UTC. Data: x402-list.com (CC BY 4.0) — the only public directory I found that publishes per-service measured traction (I checked the others; see the field guide), which is why this is the source.
Disclosure: I run Pennyforge, the $0.01 address-check API mentioned above. The census is x402-list.com's data (CC BY 4.0) and every number in this post is reproducible without my product.
"Measured" is the directory's own on-chain settlement measurement. Their stated caveat, kept: a conservative undercount — only USDC settlements via the facilitators they measure are counted. A measured floor, not an estimate; the true numbers are higher.
Per-rail figures credit each service's full volume to every rail it settles on (matching how the directory presents per-chain views). The per-service total above de-duplicates the 86 multi-rail services.
90-day change feed: x402-list.com/api/v1/changes, pulled 2026-09-09 21:54 UTC.
Raw pull and re-computation saved by me; the /diligence file is the dated digest of this census.

Third in a series on measuring the x402 ecosystem: a field guide to the x402 directories · 90 days of the drift feed.

One x402 service rotated its pay address 964 times in 10 days. I measured 90 days of the drift feed.

Pennyforge — Sun, 06 Sep 2026 07:35:26 +0000

The directory the x402-foundation README points to publishes a line I keep coming back to: so an agent can check whether the address it is about to pay still belongs to the service it means to pay.

Good advice. So I pulled that directory's public 90-day change feed and measured what actually happens to settlement addresses on x402. The headline number and the real story are two very different things, and the difference matters if your agent pays any of these services.

What's in the feed

Ninety days, 630 listed services (their daily-updated llms.txt, as of 09-06), 8,000+ recorded changes:

6,183 schema changes — quiet background noise, endpoints reshuffling their payloads
747 price changes
1,077 settlement-address (payTo) changes — the trust-critical kind

Read "1,077" in isolation and x402 looks like a place where services swap their settlement wallet roughly 12 times a day, across the whole directory. That's the number you'd expect people to quote. It's also about 97% of the wrong shape: 1,046 of the 1,077 events come from two services.

Two metronomes

964 of the 1,077 address changes come from a single service: Tavily Search. Not gradually — in a burst: July 24, 14:45 UTC to August 4, 07:48 UTC, 257 hours, one brand-new payTo address every 16 minutes — the median gap, to two decimals, is exactly 16.00. 964 distinct addresses. Each one used for exactly one rotation window, then swapped. None ever reused.

A second service (altahub-vivarium) ran the same pattern on a smaller scale: 82 rotations over ~22 hours, median gap again 16.00 minutes. Two services, one rhythm. That regularity is a metronome, not a coincidence: either a pipeline that mints a fresh settlement wallet on every deploy (a CI cadence of ~16 minutes), or a deliberate stress test of the ecosystem's drift handling. The feed can't tell you intent — and honestly, rotation can be perfectly legitimate address hygiene. The failure mode is on the consumer side: an agent that caches the address.

What the feed can tell you: for an agent that cached the payTo from a listing, that service was settling to a different address every 16 minutes for ten straight days.

The steady state (the part that matters for most services)

Strip out the two burst services and 90 days of x402 settles down to 31 address changes across 22 services — a few per week, almost all one-time events. Of those, 17 services rotated exactly once; one apparent repeat (synthora, same change recorded on consecutive days) is a duplicate scan, not a second rotation. The ecosystem is calmer than the headline — that's the point I'd want you to keep.

1,068 of the 1,077 events were clean swaps: the old address removed and the new one added in the same observation. And it's not a single-chain story — the directory tags Tavily's network as aws:base, altahub's as plain Base (eip155:8453), and other rotations touch Solana and Algorand endpoints. Base-family tags (eip155:8453 + aws:base) account for 83% of the old-address snapshot rows I counted.

So the honest version of the headline:

3.8% of listed services (24 of 630) changed their settlement address at least once in 90 days. Most of them did it once. Two of them did it in a blur.

What this means if your agent pays x402 services

Don't hardcode payTo from a listing. The discovery document exists to be re-fetched at payment time. The address in yesterday's scrape is a promise, not a fact.
"I verified it yesterday" is a weak defense. Inside a burst window, an address verified at 09:00 was dead by 09:16. Verification decays at the cadence of the service's deploys.
Wrong address = social recovery, not on-chain recovery. USDC sent to a stranger's wallet is still USDC — it just isn't yours anymore. Recovering it is an email thread with someone who may not have your API on their keychain.
Metadata drift is constant; settlement drift is rare. 8,000 changes across 630 services in 90 days — but almost all of it is schemas and prices. If your integration assumes the service card you cached is current, you're already behind on the metadata long before you'd notice anything about the money.

What a pre-payment check should actually cover

The bar is low: is the token the token you expect (exact address, correct version), is the network the network you expect, is the payTo the address you expected, is the price sane? That's four comparisons before you sign a transfer. Nothing exotic — just the difference between "the API told me what to pay" and "I verified what I'm about to sign."

This is the class of bug that hurts — the $0.10 payment that lands in the wrong wallet is also the $1,000 payment that will. So we built SendCheck to do exactly these checks: a free checksum pre-check (/validate), a $0.01 check of token + network + payTo (/check), and a $0.05 deep check that adds schema and example validation (/deep). No account, no API key — the x402 payment is the auth. It's a small tool, and the drift data is why it exists: sendcheck.surge.sh.

Method and caveats

Source: https://x402-list.com/api/v1/changes (90-day window). Their API serves the full feed — fetched 09-06, filtered to type=payto_changed, all 44 pages (25 events/page, the last page returns 2 rows), and the oldest payTo event (2026-07-24) sits comfortably inside the window, so the series is complete, not truncated. Their own llms.txt independently states the same 1,077 payTo rotations. Three caveats:

Scanner-observed, not ground truth. The feed records what the directory's scanner saw in discovery documents, not what the service intended.
Duplicate observations exist. One service's single address change was recorded twice, on consecutive days — the scanner re-observed an endpoint that was still changed.
Burst intent is unknown. Tavily's and altahub's metronome could be deploys, a load test, or a wallet-rotation policy. If someone from either service wants to correct the story, the data's right there — re-run the query and compare.

Data: x402-list.com /api/v1/changes (CC BY 4.0, creativecommons.org/licenses/by/4.0/), filtered and aggregated by me.

659 services, $0.01 median, 13 verified: a field guide to the x402 directories

Pennyforge — Sat, 05 Sep 2026 17:08:45 +0000

Last month I shipped a small paid API over x402 — a $0.01 address-check for USDC transfers, settled on Base. Since then I've spent more time in the directories than anywhere else, because that's where the question "how do people find a service?" actually lives.

So I did the boring thing: pulled the data and counted. Everything below was measured on September 5, 2026 from the directory APIs themselves (x402-list's data is CC BY 4.0 — credited in the links). Here's the landscape of where x402 services live, what it costs to be on the shelf, and what the numbers say about where demand actually is.

The numbers first

From x402-list's own monitoring (their state page, regenerated hourly):

659 services listed as accepting x402 — 568 answering, 91 offline, 29 offline for 30+ days.
592 are payment-ready (answer a valid 402 challenge), but only 13 are delivery-verified — i.e., someone actually paid and got the product. That's ~2%.
Growth is real: +84 services in 7 days, +225 in 30 days.
Average uptime: 86.7% on the latest daily rollup, 92.8% over 30 days.
On-chain settlement volume they can measure across 37 tracked facilitators: $1.22M over 30 days across ~14M settlements.

My own pull of the full service list (630 rows, their API) adds a few slices their headline doesn't show:

Base is 95% of listings (598 services), Solana the distant second (223). If you're choosing one rail in 2026, the directory data says USDC-on-Base.
Pricing: median $0.01. 41% of services are below $0.01, 46% sit in $0.01–$0.10, and only 12% price above $0.10. Exactly one service is free.
Sources: 472 services self-submitted, 155 imported from the Coinbase CDP Bazaar, 3 from x402scan. The directories are beginning to trade inventory with each other.
Categories: Data (278), AI (110), Finance (82), Verification (66) — "check something for me" is the dominant job agents are paying for.

The concentration caveat (from the same directory's state data): the top handful of services take the large majority of measured volume, and one single service accounts for roughly 82% of it — driven by a small number of repeat buyers. The long tail, where most of the 659 live, has real calls but thin money.

The shelf: who runs the directories

The x402 README names the community-maintained options. I've now looked at each with a service to list:

x402scan.com — indexes on-chain settlements (Bitquery + a CDP BigQuery sync). If your settlements go through the Coinbase CDP facilitator, you appear automatically. Otherwise you self-register for free: expose an openapi.json with x402 payment info, sign a Sign-In-With-X challenge with your receiving wallet, done. Their paid search API is a separate, small charge.
x402-list.com — the one with the monitoring depth above. Submission goes through their paid x402 API ($1 free-hosting fee for non-CDP domains, settled over x402 itself), then human review. The public read API is free and CC BY — which is how this post exists.
agentic.market (Coinbase's agentic marketplace) — a CDP-catalog-only index. I verified this the hard way: domains with PayAI-settled services get zero hits there, while CDP-catalog domains all show up. One Coinbase API key gets you onto the shelf.
Ampersend (app.ampersend.ai/discover) — the new one in the README. I pulled its marketplace API today: 55 services, all Base/USDC, and every listing sourced from the CDP catalog. So same key as above — it's the CDP shelf wearing a control-plane hat.
pay.sh — a directory with its own pay-gateway architecture; fits cleanly only if your settlement path matches theirs.
GitHub awesome-lists — free PRs, slow merges, but the links outlive everything else.

The pattern is unavoidable: CDP is the chokepoint of the curated shelves. Get a facilitator key from Coinbase and three directories (agentic.market, Ampersend, plus the x402scan /all view, which only shows CDP-settled sellers) light up at once.

What we learned building one

SendCheck's x402 endpoint settles at $0.01/check and $0.05/deep, with a free /validate pre-check (don't make agents pay for a malformed address). Practical notes from three weeks in:

openapi.json is the discovery file. At least one major directory fetches only that — not the older /.well-known/x402 card. Keep both, but treat OpenAPI as the source of truth.
Payment is the authentication. No API keys, no accounts, no rate-limit tiers to sell. That's the whole product pitch — and the whole pricing pitch, since you can price a single request.
Facilitator fees eat micro-prices. CDP settles at $0.001/tx — fine, but that's 10% of a $0.01 ticket. Pick your facilitator on economics, not just on shelf access, and price accordingly.
Directories are discovery, not distribution. Being listed is table stakes. The calls that matter come from the protocol community (Slack, dev.to, X) reading that you exist and trusting that you answer the 402 honestly.
Verification is the differentiator. With only 13 of 659 services delivery-verified, "we paid for it and it worked" is the rarest claim on the shelf.

If you're listing a service this month

The zero-spend path, in order: (1) put a correct openapi.json on your API, (2) self-register with x402scan via SIWX, (3) open the free PRs to the awesome-lists, (4) tell the x402 Slack / builders channels. The one-click path: get a CDP facilitator key from Coinbase — that single key unlocks the CDP catalog, agentic.market, Ampersend, and x402scan's sellers view. The paid path: x402-list's $1 submission, which buys the most rigorous monitoring of the lot.

The median price on the shelf is a nickel's cousin. The standard is young, the rails are settling (Base/USDC, x402 under the Linux Foundation since July), and the directories are where the next few years of agent commerce will get discovered. Get listed, answer the 402 fast, and let the payment itself do the marketing.

SendCheck's paid x402 endpoint: $0.01/check, $0.05/deep, free pre-check — the API · listed on x402scan · the human-facing checker. Data: x402-list (CC BY 4.0), ampersend marketplace API, own measurements 2026-09-05.

Our $0.01 API hung for three days — the culprit was a GET request

Pennyforge — Thu, 03 Sep 2026 04:38:34 +0000

We run a small paid API endpoint: SendCheck, a pre-send verification service for EVM addresses, exposed over the x402 protocol (HTTP 402 + USDC on Base) at $0.01 per check. For three days, its paid routes would intermittently hang forever — no error, no timeout, no log line. Free routes on the same isolate stayed fast the whole time.

This post is two things: the war story (because the root cause is a genuine trap for anyone running x402 on Cloudflare Workers), and the API itself (because it's live, and a curl away).

The symptom pattern

The shape of our Worker is the common one — free discovery/health endpoints plus paid routes:

app.use('/check', paymentMiddlewareFromHTTPServer(...));  // paid
app.get('/', c => c.text('SendCheck x402 API'));           // free
app.get('/.well-known/x402', ...);                         // free discovery doc

What we saw in production:

Right after a deploy, paid routes answered 402 Payment Required in under a second. Our smoke tests passed.
Minutes to hours later, paid POSTs would hang indefinitely (verified past 45 seconds). The client just... waits.
Simultaneously, free routes on the same isolate answered in ~100ms.
A manual fetch() from inside the Worker to the facilitator's /supported endpoint returned in ~90-300ms — the network was fine.
It never reproduced locally. wrangler dev was always green.
Re-deploying "fixed" it. For a while.

If you've debugged anything like this, you know the feeling: every probe says healthy, every real customer call says dead.

The microscope

The breakthrough came from wrapping the middleware's internals with breadcrumbs and watching wrangler tail:

const raw = new x402HTTPResourceServer({ ... });
const httpServer = {
  initialize: async () => {
    dbg('init#1 start');
    try { await raw.initialize(); dbg('init#1 done'); }
    catch (e) { dbg('init#1 fail', e.message); }
  },
  processHTTPRequest: async (...a) => { dbg('proc#1 start'); const r = await raw.processHTTPRequest(...a); dbg('proc#1 done'); return r; },
};

On a wedged isolate, the tail looked like this:

GET  /.well-known/x402 - Ok          ← free route, returns immediately
  (log) [x402dbg] init#1 start       ← handshake started under THIS request
  (log)                               ← ...no "done", ever
POST /check           - Canceled     ← later paid requests: no proc logs at all

The init handshake started, and never finished. Paid requests never even reached processHTTPRequest — they were stuck earlier, waiting on a promise that would never settle.

The root cause: workerd cancels work when the request context ends

In @x402/hono (v2.24.0 at time of writing), paymentMiddlewareFromHTTPServer fires the facilitator handshake at middleware construction time — with syncFacilitatorOnStart = true, the default:

if (syncFacilitatorOnStart && !isInitialized) {
  initializeHttpServer();   // not awaited; promise memoized in initPromise
}

Middleware construction happens lazily inside the Worker's fetch() handler. So that handshake fetch() runs under whichever request first lands on a cold isolate.

And in workerd, when a request finishes, everything still pending under its context — in-flight fetches, timers, all of it — gets cancelled.

Now it clicks:

A crawler (or a curious human) hits /.well-known/x402 or robots.txt or any 404 — a short free GET that returns immediately.
That request is the isolate's first. Middleware construction starts the facilitator handshake under it.
The GET returns; workerd cancels the in-flight /supported fetch.
The memoized initPromise stays pending forever. No rejection, no error, nothing to catch.
Every later paid request on that isolate does await initPromise → infinite hang.

No timeout saves you. AbortSignal.timeout and any setTimeout race are cancelled with the same request context. That's why the hang showed no timeout ever firing. (A timeout guard around await initPromise on the paid request only converts the infinite hang into a timeout error — the init was started under a context that is already dead. The repair has to keep the init's own context alive.)

Free routes never await init, so they stay fast. A cold isolate whose first request is a paid POST works fine, because that request's context stays alive through init. Hence the maddening pattern: works after deploy (your smoke test is a POST), wedges minutes later (a crawler GET got there first).

The fix

Keep the first request's context alive until the construction-time init settles, via ctx.waitUntil:

let app = null;
let initPromise = null; // captured from the wrapped initialize()

export default {
  fetch(request, env, ctx) {
    if (!app) {
      app = createApp();                        // init starts here
      if (initPromise) ctx.waitUntil(initPromise.catch(() => {}));
    }
    return app.fetch(request, env, ctx);
  },
};

With that in place, we ran a 12-minute adversarial loop — short free GETs interleaved with paid POSTs, the exact poison scenario — plus real paid round-trips at 0 and ~90 minutes after deploy. Clean, every time. Paid calls now answer 402 in ~0.4s and complete the full pay→200 cycle in ~1.3-2.1s.

One thing that is not a fix: setting syncFacilitatorOnStart = false. The middleware then never awaits initialization at all, and processHTTPRequest fails with "no supported payment kinds" — a 500 on every paid route. (Yes, we shipped that for two minutes. Our test suite caught it. Run your tests before you deploy, not after.)

If you run x402 on Workers with any free GET route — and the quickstart's shape gives you several — you likely have this bug. We'd love to see it fixed upstream; until then, the waitUntil pattern above is a complete workaround.

The API itself

SendCheck answers one question before you send funds: is this address what I think it is? You give it an address and a chain; it returns a verdict with the on-chain facts behind it — EIP-55 checksum validation, wallet-vs-contract detection (is that "wallet" actually a smart contract?), outgoing activity, native + USDC balances, and a plain-language verdict.

The base endpoint is $0.01 per check; the deep scan ($0.05) runs the same verification across all five chains (Base, Ethereum, Arbitrum, Optimism, Polygon) including wrong-network detection.

Here's the whole flow. A plain POST gets you the 402:

curl -i -X POST https://sendcheck-x402.pennyforge.workers.dev/check \
  -H 'Content-Type: application/json' \
  -d '{"address":"0x9504A5939AB5be2B2B1F8beA7D7ebeCcd96c485D","chain":"base"}'

HTTP/2 402
payment-required: eyJ4NDAyVmVyc2lvbiI6Miwi...

The payment-required header is base64; decoded, it's a machine-readable challenge:

{
  "x402Version": 2,
  "error": "Payment required",
  "resource": {
    "url": "https://sendcheck-x402.pennyforge.workers.dev/check",
    "description": "SendCheck: pre-send verification of any EVM address on one chain (EIP-55 checksum, wallet-vs-contract, outgoing activity, balances, verdict). POST {address, chain}",
    "mimeType": "application/json",
    "serviceName": "sendcheck",
    "tags": ["evm", "crypto", "security", "usdc", "address-verification"]
  },
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:8453",
    "amount": 10000,
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "payTo": "0x9504A5939AB5be2B2B1F8beA7D7ebeCcd96c485D",
    "maxTimeoutSeconds": 60,
    "extra": { "name": "USD Coin", "version": "2" }
  }]
}

With the x402 client stack, payment is a wrapper around fetch:

import { wrapFetchWithPayment, x402Client } from '@x402/fetch';
import { ExactEvmScheme, toClientEvmSigner } from '@x402/evm';

const client = new x402Client();
client.register('eip155:8453', new ExactEvmScheme(toClientEvmSigner(account)));
const fetchWithPay = wrapFetchWithPayment(fetch, client);

const res = await fetchWithPay(
  'https://sendcheck-x402.pennyforge.workers.dev/check',
  {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ address: '0x9504…485D', chain: 'base' }),
  }
);

The wrapper intercepts the 402, reads the challenge, signs an EIP-3009 transfer for exactly $0.01 of USDC on Base, replays the request with the payment header, and hands you the real response:

{
  "verdict": {
    "level": "ok",
    "headline": "Looks good — safe to send"
  },
  "meta": { "service": "sendcheck", "version": "1.8", "ms": 205 }
}

No API key to provision, no account to create, no invoice to chase. The request is the payment. That's the whole reason we built on x402: for a $0.01 call, every other billing stack (cards, invoicing, subscriptions) costs more to operate than the product earns.

Honest limits

We'd rather over-disclose than oversell:

It's a sanity check, not a guarantee. The verdict summarizes on-chain facts at call time: checksum validity, contract-vs-wallet, activity, balances. It will not tell you the purpose behind an address, and it doesn't do ML risk scoring.
/check is single-chain by design. Give it the chain you actually care about; use /deep for cross-chain and wrong-network detection.
The facilitator settles on Base. Payments are exact USDC amounts on Base mainnet; settlement takes a few seconds.
Young service. The verification engine has been live as a free web tool (sendcheck.surge.sh) for a few weeks with a full test suite; the paid API went live this week. If anything looks off, the free web tool shows the same engine's output — you can cross-check us for $0.
Price is honest about scale. $0.01 buys a verification, not insurance.

Try it

If you have a Base wallet with a little USDC, the whole flow above is copy-pasteable — first payment included. And if you're building on x402 on Cloudflare Workers, go check your free routes right now: hit them, then try a paid call. If it hangs, the waitUntil fix above is yours.

We're a small studio — feedback, bug reports, and "this verdict was wrong" mails all get read.