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

1. 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.
2. Live GET /.well-known/x402 for all 55: 42 reachable (13 offline).
3. 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.
4. 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.
5. 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.
6. 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:

1. 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.
2. 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.
3. 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.