Mike Hale The Solana Foundation has launched payment channels, a new Solana primitive that lets an AI agent authorize a spending limit once, spend against it without signing a transaction per call, and settle the real amount in a single onchain transaction. It works like a bar tab. You put money down up front, run up usage without paying for each round, and settle once when you leave.
For developers building agentic payments, the program and the toolkit are both open source, and payment channels slot into x402 and MPP rather than replacing either one.
Where per-call payments break down
Pay-per-request works cleanly when an agent makes one call for a known price. It falls apart in two patterns that describe most real agent work.
The first is a single call whose cost is not known in advance. An LLM completion billed per token, or a job billed per byte or per second of compute, cannot be priced before it runs. The second is many small deliveries, like a token-by-token streaming response or a burst of hundreds of cheap calls inside a loop.
Settling either pattern onchain per request breaks three things at once. A human ends up back in the loop approving payments one at a time, which defeats the point of an autonomous agent. Every payment carries settlement cost and latency, and once you are settling billions of them those costs compound. And the usual workaround gives up custody, because prepaid credits mean your balance leaves your wallet on the first call and then lives in someone else's database.
A payment channel amortizes all of that down to one open and one settle, no matter how much metering happens in between. You set a cap, your agent spends against it, settlement happens in batches, and the funds stay non-custodial the whole time.
How a payment channel works
A payment channel has four steps, and only two of them touch the chain.
Open. Deposit a ceiling amount into onchain escrow. The funds are held by the program, not the operator, so they stay non-custodial.
Meter offchain. The agent authorizes spending with signed messages rather than transactions. Every call is a signature, and it incurs no transaction cost.
Settle. The actual amount consumed gets recorded onchain in one transaction.
Distribute and refund. Funds go to the recipients and any unused deposit returns to the buyer.
The escrow design is what keeps this from being a trust exercise. The operator can only claim against valid cryptographic signatures, and the buyer keeps recovery rights over anything unspent. The operator can also sponsor the transaction fees on open and settle, which means a buyer needs only a stablecoin and never has to hold SOL to pay gas.
What 1 million payments per second actually measures
The benchmark measures offchain signature throughput, which is a different thing from Solana transactions per second. Keeping payments off the chain is the entire design, so the two numbers are not comparable.
Solana Foundation engineers ran 100,000 unique wallets through a payment channel proxy and issued more than 1 million payments every second. That works out to more than 80 billion payments in 24 hours at an estimated processing cost of $0.000000000776 per payment, which is roughly eight hundredths of a cent per million payments.
Almost none of those payments are transactions. They are signed authorization messages passing between the agent and the operator, and the chain only sees the open and the settle. A million metered payments can be authorized and accounted for while the chain does two transactions' worth of work. Solana's validators are not processing a million transactions a second, and payment channels do not ask them to.
The benchmark ships as an open-source template with load-testing tools included, so anyone can rerun it.
Payment channels work across x402 and MPP
Payment channels map onto the agentic payment standards already live on Solana, in three modes covering different spending shapes.
Mode | What it does | Best fit |
|---|---|---|
x402 | Authorize a ceiling for one metered call, settle the actual amount, refund the difference | A single call with a cost you cannot know in advance |
x402 batch-settlement | Many deliveries settled together in one transaction | A burst of small calls with known prices |
MPP session | Channel stays open while a running cumulative voucher authorizes each delivery, settling once the session idle-closes | Streaming output, token by token |
The specification is public and the program is open source.
Alibaba Cloud is live at launch
Inference has been the most requested use case across agentic payment protocols, and Alibaba Cloud is the launch partner. An agent authorizes once and then consumes its API endpoints at scale, with no account setup and no per-call approvals.
Inference is the clearest case of a service with variable per-token costs and high call volume, which is the shape per-call settlement handles worst. Starting there puts the primitive against its hardest workload first.
Solana Foundation shipped a primitive whose main achievement is keeping payments off the chain, then made the escrow non-custodial so that skipping per-call settlement does not mean handing an operator your balance. Whether it holds up depends on how many operators run it, and at the start that list is Alibaba Cloud.