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

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

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