Solana’s “million-payments-a-second” AI system can leave sellers unpaid even after they deliver

A customer using a Solana payment channel can stop buying AI services before the channel has finished paying for them. If the operator goes silent in between, the customer needs a way to recover the remaining deposit, while the merchant needs its last bill to reach the blockchain before the recovery window closes.

That division of risk sits behind Solana Foundation’s Sept. 3 payment-channel announcement, which reported more than one million payments per second through a proxy using 100,000 unique wallets. The system lets agents spend against a prepaid ceiling through signed messages, reducing the need for a separate blockchain transaction for every delivery.

The customer funds the channel, the merchant supplies the service, and the operator runs the payment process. Each finances a different part of the interval between authorization and collection: customer deposits, operator advances of SOL for fees and refundable account rent, and merchant service awaiting on-chain payment.

A warning in the Foundation-linked benchmark template makes that interval consequential: restarting its default in-memory store can forfeit vouchers accepted but not yet settled.

The benchmark template reports about 1.09 million verified vouchers per second on a 128-core AVX-512 host during a sustained 10-minute run. It measures the payment gate returning a response without an upstream service. The result does not measure a million AI completions or independently settled mainnet transactions each second.

The gateway checks a signature and advances the channel’s cumulative spending record off-chain. That arrangement lets many small authorizations share the cost of on-chain operations. But the template says a deployment with durable session storage must be benchmarked separately because a durable write becomes part of the request path.

For a merchant, that distinction connects speed to recoverability. A fast acceptance record is useful for deciding whether to serve the next request. A surviving voucher is needed to support collection after a restart. The headline throughput figure does not establish the performance of both together.

The Foundation said Alibaba Cloud API endpoints were live at launch, and the program repository lists a mainnet deployment. The benchmark describes a test workload rather than measured commercial demand.

A refund has two routes

A payment channel starts with the customer depositing a ceiling into escrow held by the on-chain program. The program controls the balance and enforces its payment rules. Spending authorizations accumulate against that deposit, and closure provides a route back for the portion not recorded as settled.

When both sides cooperate, the designated payee, whose signature authorizes final closure, can submit final settlement, seal the channel and distribute the funds in a single transaction. Sealing freezes the settled total; distribution transfers the tokens. Merchant payout and customer refund can land together without a forced-close grace wait.

The September 3 session draft, a work-in-progress specification, describes the alternative for an unresponsive server: the customer requests forced close and starts a grace period. It recommends 900 seconds, or 15 minutes, configured per channel. The clock starts when the request is recorded on-chain, not when the customer first notices a stalled service.

In a sponsored stablecoin session, the operator pays normal fees and rent. A customer holding no SOL must therefore obtain SOL or a fee-paying submitter to initiate escape if that operator is unavailable. Permissionless recovery allows another party to help; a replacement submitter still has to be available and willing to pay the transaction fees.

After grace expires, anyone can submit the sealing instruction. The customer can then withdraw the deposit minus the on-chain settled amount. Alternatively, anyone can submit a distribution transaction that pays recorded merchant shares and the pending refund, using the payout split committed in the public opening transaction.

These recovery paths assume a functioning network and usable token accounts. The program documentation warns that an issuer-frozen escrow can block transfers and that distribution can redirect an unusable beneficiary or refund account’s share to the treasury. Those are separate limits on recovery, even when no operator signature is needed.

For the customer, practical delay includes arranging and landing the transactions as well as the configured timer. The fee burden depends on who submits them. The 15-minute recommendation describes one possible protocol wait; the per-authorization benchmark cost measures a different operation.

The merchant’s collection window narrows

The merchant’s position depends on which record its bill has reached. An off-chain voucher, an amount recorded as settled on-chain, and tokens already distributed to a recipient are three different things.

The current settlement implementation lets anyone present a valid voucher while the channel remains open. Once the payer requests close, that ordinary instruction stops accepting new settlement. During grace, the final voucher must instead pass through the payee-authorized settle-and-seal path described in the state-machine rules.

During grace, the payee has time to record its final bill. A third party able to pay transaction fees cannot necessarily replace a missing payee signature. Keeping a copy of the voucher helps only if the authorized settlement path can still use it before the deadline.

If delivered service never reaches the final on-chain settlement total before the deadline, it can become uncollectible from that channel. Once the channel is sealed, the customer’s refund is calculated against the recorded total, not an operator’s later reconstruction of what should have been billed.

Already-settled merchant funds have a different outcome. They remain reserved for distribution after sealing, subject to the required token accounts being usable. The customer’s refund does not include those recorded merchant shares. Operator failure therefore does not imply that every unpaid merchant balance disappears.

A missing payout transaction can therefore be completed through permissionless distribution once the channel is sealed, with usable accounts and a funded transaction. A missing final on-chain settlement is harder: after forced close begins, adding it requires a valid voucher and the payee-authorized path before grace expires.

The session draft offers two signing arrangements. In client mode, the customer controls the voucher-signing key; this is the default when the challenge omits a mode. In operator mode, the customer presents a reusable bearer proof and the operator signs the spending vouchers.

The escrow ceiling bounds settlement in either mode. The signing choice determines who creates the payment authorization. The published material does not establish a single live grace period or signing mode for every Alibaba or pay.sh channel, so the customer’s and merchant’s exposure depends on their particular channel terms.

The operator’s separate financing cost

There is also a separate operator financing cost. The instruction reference allows the drained channel account’s refundable SOL rent to remain committed until a 1,500-slot opening window has passed. That timer concerns account deallocation. Customer token refunds and merchant token payouts proceed independently of that rent timer.

For operators, durable voucher records and timely settlement address different problems: preserving the bill and getting it recognized on-chain. Distribution then completes payment. More frequent settlement can reduce the service value waiting to enter the record, while earlier distribution reduces the time recorded proceeds remain in escrow.

For customers, smaller committed balances reduce the money tied to a session, but the ability to exit still depends on the channel’s timer and access to a funded transaction submitter. The merchant, meanwhile, needs a collection process that can survive a restart and operate within the close window.

Solana’s payment channels move repeated authorizations out of the blockchain’s immediate workload. The financing remains visible in three places: the customer’s deposit, the merchant’s service awaiting collection and the operator’s SOL advance. A useful measure of the system’s economics is how reliably those three balances reach their intended owners when the fast path stops.