By Alejandro Ranchal-Pedrosa

Tempo's MPP Sessions have put payment channel networks back in the spotlight, this time for agentic, machine-to-machine payments on EVM chains rather than human purchases on Bitcoin. 

I co-authored the first papers demonstrating balance deanonymization and balance lockdown attacks on the Lightning Network, and one of the original channel factories proposals. From where I sit, the design is promising and the use case is real.

The question isn't whether sessions will work. They will. The question is what happens when they start working at scale. Is the ecosystem ready for the tradeoffs that follow?

Sessions are actually payment channels

A session is a payment channel: one party deposits funds into an on-chain escrow, and both parties transact off-chain by exchanging signed vouchers until someone settles or closes on-chain. Batch n sessions into a single open-and-settle transaction and you get channel factories. Connect sessions into a routed network, and you get a payment channel network, i.e., the same structure as the Lightning Network.

But there's an important distinction. Lightning was built on Bitcoin, which lacks general programmability. Sessions on an EVM chain are more accurately described as state channels: payment channels are a special case, but state channels can encode richer logic. This isn't a new idea. EVM-native state channels have existed for years. 

The differences from Lightning in practice are significant. Tempo offers much higher throughput, targets much smaller payment amounts, and provides much lower latency for on-chain operations like opening, settling, and rebalancing channels (~500ms finality with sub-cent fees). But the fundamental tradeoffs of payment channel networks (capital lockup, routing topology, and privacy) remain.

Capital efficiency and why hubs are inevitable

The core economic problem with per-counterparty channels is simple: you don't know how much to lock up.

Consider an agent that opens sessions with multiple services: an LLM API, a data provider, a storage backend. But the agent doesn't know in advance how much it will spend with each service, so the capital is locked for the duration of the channel, and every dollar committed to one counterparty is a dollar unavailable for everything else.

This means it doesn't always make sense to open a session. It's a function of capital locked over time, not just fee savings.

And channels are fundamentally two-party. You can't solve this by cramming more participants into a single channel. If you try, you have exactly three options, and none of them work well:

Factories let you open and close multiple channels in a single on-chain transaction. This helps amortize costs, but channels need to open, close, or rebalance simultaneously to benefit from the amortization. This is an unrealistic expectation in practice.

N-party channels require every party to sign every state update. If party C goes offline, no payment can be made between A and B. 

Require fewer than n parties to sign, and you've designed something that looks a lot like a rollup: a subset of parties can determine the state even if not everyone has explicitly approved it. 

The result of these constraints is predictable. Rather than maintaining expensive per-counterparty channels, agents will gravitate toward locking up capital with a small number of well-capitalized routing hubs. Think of it like choosing between Amazon credits, Netflix credits, and dollars in a bank account. The bank charges a small fee, but you can pay anyone. Per-service credits are inflexible and capital-inefficient.

This is exactly what happened on Lightning. Recent results showed that, between 2019 and 2021, the top 5% best-connected nodes were responsible for routing 89 - 95% of all payments; in 2025, the top 10% of nodes routed 96% of the total capacity of the network (Zabka et al.) Lightning didn't remain decentralized in routing; it converged in a star topology with a few dominant hubs. 

Here's the concrete version of how routing helps. Consider an agent with a session open to Amazon (with spare capacity) and an exhausted session with Netflix; the channel has capacity, but all of it has already been paid to Netflix's side. 

If a route exists through intermediary hubs, the agent can effectively top up its Netflix balance up to the capacity  without going back on-chain. This off-chain rebalancing is the mechanism that makes hubs convenient.

Whether Tempo has announced plans for multi-hop routing across sessions is, as far as I can tell, not yet public. But routing is something that will need to happen eventually. The capital efficiency arguments are too strong, and every payment channel network in history has converged toward it. For now, sessions appear to be direct, unidirectional channels between a client and a server. 

Fee structure

On-chain payments have a fee floor. Whether you're sending $0.01 or $10,000, you pay for the same amount of gas and bytes. The cost is flat relative to the amount transferred, which creates an irreducible minimum that makes true micropayments impractical on-chain.

Routed channel payments work differently. When a hub routes a payment, it consumes directional balance in the total capacity  in its channels. So the hub's fee is naturally proportional to the payment amount: the more you send, the more capacity you consume, the more the hub needs to charge to cover rebalancing costs. This proportional fee structure is exactly what makes sub-cent micropayments viable. 

This is already playing out in practice. Sei recently published a proposal for fee transparency in the x402 ecosystem, noting that facilitator pricing models have begun to diverge: some charge a flat fee (after a free tier), while others charge percentage-based fees. The fee model depends on the underlying mechanism. If the facilitator works by locking up balance in channels and routing payments, percentage-based fees make sense; they're compensating for directional capacity usage and rebalancing costs. If the facilitator settles each payment individually on-chain, a constant per-transaction cost is unavoidable. 

The napkin math for billions of payments per second

Tempo's headline claim that MPP can scale to billions of payments per second isn’t modest, but the architecture makes it plausible in theory. Session voucher verification is a single ecrecover call, pure CPU work with no chain interaction. If all you're counting is off-chain voucher throughput, billions per second is achievable.

But the system doesn't exist purely off-chain. Channels need to be opened, settled, and closed on-chain. Funds need rebalancing. And the chain has finite throughput.

Here's the constraint. If Tempo does 100,000 TPS on-chain and there are 1 billion active channels, then at most 100,000 channels (0.01%) can perform an on-chain operation per second. That's the ceiling for rebalancing, settlement, and channel lifecycle operations combined. 

If the real rebalancing rate exceeds 0.01% of channels per second, the chain becomes the bottleneck and the system can't sustain billions of off-chain payments.

Whether 0.01% is enough depends entirely on how often channels need to touch the chain. For long-lived sessions with infrequent settlement, it might be plenty. For a network with high churn, frequent rebalancing, or many short-lived channels, it might not be. Again, big hubs can help realize this vision.

Bundlers as infrastructure

There is, however, a more promising angle. Imagine a service that batches settlement and rebalancing transactions across many channels, similar to how block builders in Ethereum's proposer-builder separation (PBS) pipeline batch and optimize transaction inclusion today. 

These bundlers could amortize on-chain costs across hundreds or thousands of channels, making settlement significantly cheaper per channel. The tradeoff is a small amount of extra latency, but this is probably acceptable since settlement should become less frequent as the network matures and channels become longer-lived. There's a real business here for whoever builds this infrastructure.

Settlement bursts and systemic risk

A less-discussed concern is what happens when many channels need to go on-chain simultaneously. A mass rebalancing event triggered by a large hub going offline or a sudden market move could spike on-chain fees and create congestion precisely when settlement is most urgent.

The TempoStreamChannel contract has a 15-minute grace period: when a payer requests to close a channel, the server has 15 minutes to submit its latest voucher before the payer can withdraw the full remaining deposit. In normal conditions, this is plenty of time. During a settlement burst, it may not be. 

An attacker who can cause a mass close event and then censor or delay the counterparty's settlement transactions during the congestion window could potentially withdraw funds that have already been spent off-chain. 

Will watchtowers matter again?

On Lightning, watchtowers emerged as a necessary piece of infrastructure. A watchtower is a service that monitors the chain on your behalf: if your counterparty tries to close a channel with an old state, the watchtower detects it and submits a penalty transaction during the dispute window.

Watchtowers became important on Lightning because users can't realistically be online 24/7. If you go offline and your counterparty publishes a stale state, you lose money unless something is watching for you.

For agentic payments, the dynamics are different in one important way: agents and servers are expected to be online continuously. In theory, this reduces the need for watchtowers because the counterparties don’t actually need food or sleep. 

But in practice, the threat model doesn't change. Agents crash. Servers get rate-limited. Infrastructure goes down. An agent that loses connectivity for even a short window is vulnerable to a counterparty publishing an old channel state. 

The unspoken privacy problem

Payment channel privacy is strictly harder than on-chain privacy, and the current MPP design appears to deprioritize it. This may be pragmatic for launch, but the architectural decisions being made now will ossify.

On-chain payments are pseudonymous: transactions are tied to public keys, which provide some degree of anonymization if used right (e.g. via mixers). Channel payments are different. They require direct communication between counterparties, which means they're tied to IP addresses, which are a direct link to physical location and, often, real-world identity. 

This is a fundamentally weaker privacy model than on-chain transactions, which is counterintuitive given that payment channels are supposed to improve on the base layer.

The problem gets worse with routing. The paper I co-authored on balance deanonymization demonstrated a probing attack against the Lightning Network that uses a binary-search strategy to disclose channel balances. By attacking just 78 nodes, an adversary could disclose the balance of 80% of channels on the network. The entrance cost was minimal. The attack works because routing requires nodes to report whether they can forward a payment of a given size, which leaks information about their balance. 

The follow-up paper showed that the same routing primitives (specifically, time-locked multihop payments) can be exploited to lock down the balance of other participants in the network. An adversary holding only a fractional amount of capital can block a victim's ability to route payments entirely, at negligible economic cost. Privacy and availability turn out to be two sides of the same vulnerability.

These attacks can be adapted to any payment channel network. If sessions on Tempo eventually support routing, the same vulnerability applies.

The countermeasures are known but costly: public disclosure of balances improves route-finding efficiency at the expense of privacy, and the longer that tradeoff is deferred, the harder it becomes to retrofit once routing hubs have optimized around full balance visibility. 

What comes next? 

Sessions will work for agentic payments. The use case is real: usage-based billing for LLM APIs, data services, and machine-to-machine commerce needs a payment primitive that can keep pace with the service itself. State channels are the right tool.

But the lessons from Lightning apply. Capital efficiency pressures will centralize routing toward a small number of well-capitalized hubs. The scalability math has hard constraints tied to rebalancing frequency and on-chain throughput. The privacy model needs attention before sessions become load-bearing infrastructure for agentic commerce.

I'm not just optimistic about sessions as a technology. I think there are concrete businesses to be built in the infrastructure layer. Assuming agentic micropayments reach the scale claimed by Tempo, we can expect a star topology with routing hubs and service providers consolidating capital through network effects, just as it happened on Lightning.