Solana Payment Channels Hit 1m Payments a Second in Tests, but Settlement Risk Remains

Solana Foundation said on 3 September that a payment-channel system aimed at AI services had handled upwards of one million payments a second, routed through a proxy across 100,000 unique wallets.

The figure is narrower than it sounds, according to an analysis by CryptoSlate, and the design leaves different parties carrying risk in the gap between a service being delivered and being paid for on-chain.

How the channels work

The system lets software agents spend against a prepaid ceiling by signing messages, known as vouchers, rather than submitting a separate blockchain transaction for each delivery. A gateway verifies each signature and advances the channel's cumulative spending record off-chain, so many small authorisations can share the cost of on-chain operations.

Three parties are involved: a customer who puts money into the channel, a merchant who provides the service, and an operator that handles payment processing. Each carries part of the cost of the gap between authorisation and collection. The customer has its deposit tied up, the operator fronts SOL to cover fees and refundable account rent, and the merchant delivers before payment reaches the chain.

Alibaba Cloud's API endpoints were already running when the system launched, and a mainnet deployment appears in the program's repository.

What the benchmark measured

A benchmark template linked to the Foundation recorded roughly 1.09 million verified vouchers a second over a sustained 10-minute run, using a 128-core AVX-512 host. It measured the payment gate returning a response without any upstream service behind it.

That is a test of authorisation throughput. It does not show a million AI completions per second, nor a million independently settled mainnet transactions.

The template also carries a warning. Restarting its default in-memory store can forfeit vouchers that were accepted but not yet settled. A deployment with durable session storage has to be benchmarked separately, because a durable write then becomes part of every request.

Who bears the risk when things stall

When everything works, closure is simple. The payee's signature authorises the final close, and settling, sealing and distributing funds can happen in one transaction, so the merchant's payout and the customer's refund arrive together without a waiting period.

The harder case is an operator that goes silent. Under a 3 September session draft, which is still a work in progress, the customer can request a forced close, which starts a grace period. The draft recommends 900 seconds, or 15 minutes, with the setting chosen channel by channel. Timing runs from the moment the request lands on-chain, rather than from when the customer realises something is wrong. In a sponsored stablecoin session, a customer with no SOL would need to obtain some, or find a fee-paying submitter, before it could begin.

Once a close is requested, the ordinary settlement instruction stops accepting new vouchers. During the grace period, the merchant's final voucher must go through a payee-authorised settle-and-seal route. Any service not reflected in on-chain settlement before the deadline can become uncollectible from that channel. Funds already settled to the merchant stay reserved for distribution and do not form part of the customer's refund.

After the grace period ends, anyone can seal the channel. The customer can then withdraw its deposit minus the settled amount, or anyone can trigger distribution under the split committed when the channel opened.

Further limits and open questions

Program documentation adds caveats. An escrow frozen by the token issuer can block transfers, and distribution can send the share of an unusable beneficiary or refund account to the treasury. Operators face a timing constraint too: a drained channel account's refundable rent can stay committed until a 1,500-slot opening window has passed, though token payouts and refunds are not held by that timer.

The draft sets out two signing modes. In client mode, the default, the customer controls the voucher-signing key. Operator mode instead has the customer show a reusable bearer proof, with the operator producing the signatures. The escrow ceiling caps settlement in both. The published material does not establish a single grace period or signing mode for every live Alibaba or pay.sh channel.

The broader point is that fast acceptance and reliable collection are separate properties. Quick off-chain checks help a merchant decide whether to serve the next request; a voucher that survives a restart is what lets it get paid. The headline figure does not demonstrate both at once.

Benchmarks run with durable storage, and clarity on the settings used by live deployments, are the next things to look for.