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.
Top comments (2)
Good challenge.
On timestamps: you're right that the public table carries no time column (listing, route, amount, outcome, tx_hash — that's all of it). But every row carries a tx_hash, and I resolved all 160 of them on Base this morning — they all settle in-window (2026-05-29 → 09-13), and each one exposes its payer, which is the stronger signal:
So: the time-and-payer pattern separates the classes in the rows I checked — an inference from on-chain data, not a proof. Your velocity delta is the quick proxy; the tx_hash is the full one. Fair criticism either way: a public settlement ledger without time or payer is an incomplete public ledger.
The canary breakdown reframes the number completely. A badge enforced by a real payment is a paid handshake — it proves the payTo address works and says nothing about whether anyone wants the service. $3.42 of all-time volume with 93% of rows coming from the platform testing itself is the honest version of "the rails are real, the demand is a trickle".
The rows carrying no timestamps is the part I'd push on. Without them a repeat payer and a re-verification look identical except for amount, and any re-verification the platform runs later would read as demand in the ledger. Is there any signal that separates the two, or is the velocity delta between pulls (5 rows, $0.034) the only honest proxy you have?