Lightning Network Scalability: Theoretical Limits and Practical Constraints

The Lightning Network processes millions of payments per month, but its architecture carries scaling constraints that are rarely discussed in detail. Lightning Network scalability is bounded not by payment throughput (which is theoretically unlimited) but by the on-chain operations required to onboard users and manage channels. Every channel open and close consumes Bitcoin block space, and Bitcoin produces roughly 144 blocks per day with a hard weight limit of 4 million weight units each.

This article breaks down the math behind Lightning's scaling ceiling: how many users the network can realistically support, where bottlenecks emerge, and what proposed solutions exist to push past them.

How Many Users Can Lightning Support?

The original Lightning Network whitepaper by Joseph Poon and Tadge Dryja included an explicit calculation. Assuming each user needs approximately three on-chain transactions per year (one channel open, one close, and one additional operation), and assuming 1 MB blocks containing roughly 2,000 transactions each, Bitcoin's base layer can support approximately 35 million Lightning users.

With SegWit's effective capacity increase (blocks now average 2,000 to 2,700 transactions), that figure rises to roughly 40 to 47 million users. For context, that is less than the population of a single large country. To onboard all 8 billion people on Earth at two channel operations per year, the whitepaper estimated that Bitcoin would need 133 MB blocks.

Key distinction: Lightning scales transactions, not users. Once a channel is open, users can make an unlimited number of payments. But the number of people who can open channels in the first place is hard-capped by on-chain throughput.

The On-Chain Budget

A standard channel opening transaction (one P2WPKH input, one P2WSH 2-of-2 multisig output, one change output) consumes roughly 140 virtual bytes. A cooperative close adds another 170 vbytes. A force close is significantly larger, starting at approximately 180 vbytes and potentially ballooning to 15,000 vbytes if the channel has hundreds of pending HTLCs.

With Bitcoin blocks averaging around 2,500 transactions, and assuming 90% of block space is available for channel operations (the rest occupied by regular transactions), roughly 6,200 channels can be opened per block. At 144 blocks per day, that is approximately 893,000 channel opens per day, or 326 million per year. If each user needs two on-chain transactions (one open, one close), the network can onboard about 163 million users per year under these generous assumptions.

These numbers assume each user opens one channel and closes it once per year. Real-world usage patterns are far more complex: users may need multiple channels, channels may need to be spliced or rebalanced, and force closes consume substantially more block space than cooperative ones.

Where Lightning Is Today

As of early 2026, the Lightning Network has approximately 17,000 active nodes and 41,000 public channels holding roughly 5,000 BTC in public capacity. Estimates that include private channels place total capacity above 12,000 BTC. Monthly transaction volume has crossed $1.1 billion, with over 5 million transactions processed in peak months.

These figures represent significant growth but remain far from global scale. The network serves a user base in the low millions at most. The constraints are structural, not merely a matter of adoption pace.

Channel Capacity and Liquidity Fragmentation

Beyond the on-chain bottleneck, Lightning faces a capital efficiency problem. Every satoshi locked in a payment channel is capital that cannot be used elsewhere. Liquidity is both directional and location-bound: a channel with 1 million sats can only send up to its local balance and receive up to its remote balance at any given moment.

In practice, more than half of a channel's capacity is often unusable for a given payment direction. As payments flow predominantly in one direction (for example, consumers paying merchants), channels become imbalanced and require circular rebalancing or loop operations, both of which incur additional costs.

The Inbound Liquidity Problem

New Lightning users face a cold-start problem: inbound liquidity does not exist until someone opens a channel toward them. A merchant wanting to receive Lightning payments needs counterparties willing to lock up capital in channels pointed at the merchant. This creates a chicken-and-egg problem that Lightning Service Providers (LSPs) attempt to solve by opening channels on behalf of users.

LSPs absorb the liquidity management burden but face their own economic constraints. Capital locked in channels has an opportunity cost: LSP operators have reported yields ranging from 5% to 24% annualized on deployed Lightning capital, depending on routing volume and channel utilization. These costs are ultimately passed to users through routing fees.

Gossip Protocol Scalability

Lightning's gossip protocol (BOLT #7) propagates network topology information to every node using a flood-fill mechanism. Three message types drive this: channel announcements (~430+ bytes each), channel updates (~136 bytes each, two per channel), and node announcements (~140+ bytes each).

A full graph sync for the current network requires approximately 53 MB of data via traditional gossip. LDK's Rapid Gossip Sync compresses this to roughly 2 MB using gzip, a 96% reduction. But even with compression, the fundamental architecture requires every node to store the entire channel graph and process every topology change.

Scaling concern: Gossip bandwidth and storage scale linearly with channel count. At 10x the current network size (400,000+ channels), full syncs could exceed 500 MB uncompressed, and mobile nodes would struggle to keep their routing tables current.

Routing Complexity

All major Lightning implementations use variants of Dijkstra's algorithm for pathfinding, with time complexity of O((E + V) log V) where E is the number of channels and V is the number of nodes. For the current network, this is manageable. But the constrained shortest-path problem (finding the cheapest route that also satisfies capacity, timelock, and reliability constraints) is NP-complete in the general case.

Multipath payments compound this problem further. Splitting a payment across multiple routes requires solving a flow optimization problem that current implementations handle through heuristics rather than exact solutions. As the network grows, the computational cost of pathfinding grows superlinearly, while channel balance information remains hidden from senders, forcing trial-and-error probing and retry loops.

Proposed Solutions to Lightning Scaling

Several proposals aim to relax Lightning's on-chain constraints and improve capital efficiency. They range from incremental improvements already shipping in production to ambitious protocol changes requiring Bitcoin consensus upgrades.

Splicing: Fewer On-Chain Operations

Splicing allows adding or removing funds from an existing channel without closing it. Previously, resizing a channel required two on-chain transactions (close then reopen). Splicing reduces this to one, and the channel remains operational for payments throughout the process.

Core Lightning shipped production splicing in August 2023, followed by Eclair and Phoenix Wallet in July 2023. LDK completed its splicing implementation in 2025. LND has implemented the channel quiescence protocol as groundwork but does not yet support full splicing. Phoenix users reported a 60% decrease in on-chain fees after the upgrade.

Splicing is a meaningful improvement, but it addresses efficiency rather than the fundamental on-chain bottleneck. Every splice still requires one on-chain transaction.

Channel Factories: Amortizing On-Chain Costs

Channel factories allow multiple participants to share a single on-chain funding transaction, then create and manage bilateral payment channels entirely off-chain within that shared construct. A factory of 20 users with 100 intra-group channels could reduce blockchain costs by approximately 90% compared to opening those channels individually.

The scalability improvement is substantial in theory. Instead of each channel requiring its own on-chain UTXO, an entire group of users shares one. Channels within the factory can be opened, closed, and rebalanced without touching the blockchain.

However, channel factories remain in the research and proposal stage with no production implementations. The most promising designs depend on Bitcoin consensus changes that have not been activated:

• OP_CHECKTEMPLATEVERIFY (CTV, BIP 119)
• SIGHASH_ANYPREVOUT (APO, BIP 118)
• LN-Symmetry (eltoo), which requires APO

John Law's “Timeout Trees” proposal offers a path using CTV to create tree structures of off-chain transactions, potentially enabling a single UTXO to serve millions of casual users. But none of these opcodes have clear activation timelines.

Ark: Virtual UTXOs Without Channels

The Ark protocol, proposed by Burak Keceli in 2023, takes a fundamentally different approach. Instead of bilateral channels, Ark uses Virtual Transaction Outputs (VTXOs) coordinated through an Ark Service Provider (ASP). Users participate in periodic rounds where the ASP constructs transaction trees, broadcasting a single root transaction on-chain while users hold off-chain copies of their branch and leaf transactions.

Ark eliminates channel management entirely: no liquidity balancing, no inbound capacity concerns, and non-interactive receiving. The tradeoff is that VTXOs carry absolute timelocks requiring periodic rollovers to maintain trustlessness. Arkade, the reference implementation by Ark Labs, launched on Bitcoin mainnet in public beta in October 2025.

Comparing Scaling Approaches

Each proposed solution addresses different aspects of Lightning's scaling constraints, with different tradeoffs in trust, complexity, and deployment readiness.

Spark: A Different Scaling Model

Spark sidesteps Lightning's channel-based architecture entirely. Built on statechain technology with FROST threshold signatures, Spark transfers Bitcoin by rotating cryptographic key shares rather than routing payments through channels. The on-chain footprint is limited to deposits (locking BTC into threshold-signed outputs) and withdrawals (broadcasting pre-signed exit transactions). Everything in between is purely off-chain.

This design eliminates several of Lightning's scaling bottlenecks simultaneously:

• No channel opens or closes consuming block space for user-to-user transfers
• No liquidity fragmentation across bilateral channels
• No gossip protocol overhead for maintaining a network graph
• No pathfinding computation for routing payments
• Offline receiving via conditional payment holding by Spark Service Providers

The tradeoff is a different trust model: Spark requires that at least one operator in the Spark Entity behaves honestly during each transfer (a 1-of-n trust assumption). This contrasts with Lightning's fully trustless channel model but avoids the on-chain scaling ceiling that constrains Lightning's user count.

Scaling Characteristics Compared

Lightning's user capacity scales with Bitcoin block space. Spark's user capacity scales with operator infrastructure. Adding more users to Spark does not require additional on-chain transactions (beyond their initial deposit), which means the protocol's user ceiling is determined by server throughput and key management capacity rather than by the Bitcoin blockchain's 4 MW block weight limit.

For high-fee environments, this distinction becomes critical. When on-chain fees spike, opening Lightning channels becomes expensive and force closes become punishing. Spark users already on the network are unaffected by fee spikes for internal transfers, though deposits and withdrawals are still subject to on-chain fee dynamics.

The Broader Scaling Landscape

Lightning's scaling constraints are not a failure of design: they reflect the fundamental tradeoff of building on Bitcoin's limited block space without trusting third parties. Lightning achieves trustless, instant payments, which is a remarkable technical accomplishment. The constraint is that its trustless model requires on-chain anchoring at a per-user level.

The Bitcoin Layer 2 landscape is evolving toward a spectrum of trust-vs-scalability tradeoffs. Fully trustless systems (Lightning) anchor every user relationship on-chain. Semi-trusted systems (Spark, Ark) batch or eliminate on-chain operations at the cost of introducing operator trust assumptions. Federated systems (Fedimint, Liquid) centralize custody further but remove on-chain constraints almost entirely.

What Covenant Opcodes Could Unlock

Much of the theoretical scaling work for Lightning depends on covenant opcodes that Bitcoin does not yet support. OP_CHECKTEMPLATEVERIFY (CTV) and SIGHASH_ANYPREVOUT (APO) would enable transaction trees where a single on-chain UTXO supports thousands or millions of off-chain relationships. Without these opcodes, channel factories and timeout trees remain theoretical, and Lightning's per-user on-chain cost stays roughly constant.

Bitcoin's conservative upgrade culture means these opcodes may take years to activate, if they do at all. In the meantime, protocols that work within Bitcoin's current consensus rules (splicing, Ark without covenants, Spark) represent the practical frontier of scaling.

What This Means for Developers

For developers building Bitcoin payment applications, the choice of Layer 2 involves concrete tradeoffs. Lightning offers the deepest ecosystem and widest wallet support but imposes liquidity management complexity and an on-chain scaling ceiling. Newer protocols like Spark offer simpler integration paths (no channel management, no liquidity planning) with different trust assumptions.

The Spark SDK provides a developer-friendly entry point for building on Spark, with native Lightning interoperability so applications can send and receive across both networks. For users looking to experience Spark-powered payments today, General Bread is a wallet built on Spark that demonstrates the simplified UX made possible by removing channel management from the user experience. For deeper analysis of how these protocols compare, see the full Bitcoin Layer 2 comparison.

Conclusion

Lightning Network scalability is constrained by a fundamental architectural reality: every user relationship requires on-chain block space. At current capacity, Bitcoin can support tens of millions of Lightning users per year at best. Solutions like splicing and channel factories can improve efficiency by 50% to 90%, but splicing is incremental and factories require consensus changes with no clear timeline.

The next generation of Bitcoin Layer 2 protocols (Ark, Spark, and others) approaches scaling from a different direction, trading some degree of trustlessness for dramatically reduced on-chain footprints. Lightning will remain a critical piece of Bitcoin's scaling infrastructure, particularly for its established ecosystem and fully trustless model. But the math is clear: global-scale Bitcoin payments will require multiple complementary protocols, each optimizing for different points on the trust-scalability spectrum.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.