A million payment messages is not a million onchain settlements

Solana Foundation’s 3 September announcement reports a test with 100,000 unique wallets issuing more than one million payments per second through a payment-channel proxy. The design opens an escrow, meters authorised spending off-chain and settles the consumed amount in one onchain transaction. Unused funds return to the original wallet. The headline is therefore about a channel-based workload, not one million independent blockchain settlements each second. The benchmark and cost estimate come from the foundation’s test and should be described with that scope. Source.

The x402 documentation describes an open payment protocol using the HTTP 402 Payment Required response. A client receives payment requirements and can retry with a payment payload, allowing services to charge for machine-accessible resources. Its documentation separates exact payments, spending up to a ceiling and batch settlement. Those options matter when the cost of a response is not known in advance or a session contains many small deliveries. The protocol is a payment interface; applications still choose networks, tokens, limits and settlement arrangements. Source.

Our view is that batching can make a tiny-payment product more practical, but the comparison must keep the workload constant. A benchmark should identify the number of participants, message validation, settlement frequency, hardware and failure handling. A low estimated cost per message is not automatically the full cost of delivering the paid service. Developers also need to decide when a session ends, how a disputed meter reading is handled and how spending authority is revoked. The improvement is easier to understand when these boundaries are visible: repeated authorisations happen cheaply within a limit, while the blockchain records the aggregate result.

For a metered AI response, an application could reserve a maximum amount and settle only for the delivered output. The product still needs to explain that reservation to the payer and release unused funds predictably. Showing the cap, amount consumed and final settlement gives the benchmark a concrete user-facing meaning instead of leaving it as an isolated speed claim.