Who actually settles x402 payments? Not the people paying.

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:

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