Channel Factories: Nested Channels for Lightning Scalability

Every Lightning channel begins with an on-chain transaction. Opening a channel means publishing a funding transaction to Bitcoin's blockchain, waiting for confirmations, and paying the associated fee. Closing a channel requires another on-chain transaction. For a network that aspires to serve billions of users, this per-channel on-chain overhead creates a fundamental scaling bottleneck.

Channel factories offer a solution: instead of each payment channel requiring its own funding transaction, a group of participants pools funds into a single on-chain UTXO, then creates multiple channels off-chain within that shared construct. The on-chain cost is amortized across all channels in the factory, potentially reducing the per-channel footprint by an order of magnitude or more.

The On-Chain Bottleneck

Lightning's scaling challenge is arithmetic. Bitcoin processes roughly 4,000 transactions per block, with blocks arriving every ten minutes on average. Each Lightning channel needs at minimum two on-chain transactions across its lifetime: one to open and one to close. If every person on Earth needed one channel, opening them alone would consume years of dedicated block space, assuming nothing else used the chain.

The fee market compounds this problem. During periods of high demand, opening and closing channels becomes expensive. Users with small balances may find their channel capacity barely exceeds the fees required to manage it. This dynamic disproportionately affects the users Lightning aims to serve: those making small, frequent payments.

Splicing helps by allowing channels to be resized without closing, but it still requires on-chain transactions for each splice operation. The fundamental issue remains: Lightning's per-channel on-chain requirement does not scale to global usage under current Bitcoin throughput.

The Burchert-Decker-Wattenhofer Proposal

In 2018, Christian Decker, Conrad Burchert, and Roger Wattenhofer published Scalable Funding of Bitcoin Micropayment Channel Networks, introducing the channel factory concept. The core insight: a multi-party off-chain protocol can serve as a factory that produces and manages payment channels without individual on-chain funding transactions.

The construction uses a layered transaction structure. At the base layer, n participants create a single n-of-n multisig funding transaction on-chain. Above that sits an allocation layer of off-chain transactions that divide the pooled funds into individual two-party channels. These channels then operate identically to standard Lightning channels, supporting HTLCs, multipath payments, and all existing Lightning functionality.

The Layered Architecture

The factory operates across three distinct transaction layers, each serving a different purpose in the protocol:

• Funding layer: a single on-chain transaction creating an n-of-n multisig output, the only transaction that touches the blockchain during normal operation
• Allocation layer: off-chain transactions that distribute the pooled funds into individual two-party channel outputs, requiring all n parties to sign
• Channel layer: standard two-party payment channels (Lightning channels) that operate independently, where only the two channel counterparties need to coordinate for updates

Key insight: The allocation layer is what makes factories powerful. By restructuring this layer off-chain, participants can create, close, and rebalance channels without ever publishing a transaction. The n-party coordination requirement only applies to allocation changes, not to individual payments within channels.

Factory Lifecycle

A channel factory moves through distinct phases, from creation to eventual settlement. Each phase involves different coordination requirements and on-chain costs.

Phase 1: Factory Opening

A group of n participants agrees to form a factory. They collectively construct a funding transaction that spends their individual inputs into a single n-of-n multisig output. Before broadcasting this transaction, all participants sign a refund transaction that returns funds to their original owners after a timelock expiry. This guarantees that uncooperative participants cannot hold funds hostage indefinitely.

The funding transaction is broadcast and confirmed on-chain. This is the factory's only required on-chain footprint during normal operation.

Phase 2: Channel Creation

With the factory funded, participants collaboratively sign allocation transactions that create individual payment channels. A factory with 10 participants might create 20 or more channels: each participant can have channels with multiple counterparties. These channels are indistinguishable from regular Lightning channels at the protocol level.

Creating a new channel within the factory requires a new allocation transaction signed by all n factory participants. However, once created, the channel operates independently: only the two channel counterparties need to be online for routine payments.

Phase 3: Off-Chain Rebalancing

Over time, channel balances shift as payments flow. In standard Lightning, rebalancing often requires on-chain transactions (closing and reopening channels) or complex circular rebalancing routes. Within a factory, rebalancing happens off-chain: participants sign a new allocation transaction that redistributes funds across channels differently.

This is where factories deliver their greatest advantage for liquidity management. A Lightning Service Provider operating within a factory can reallocate inbound liquidity across its channels without touching the chain.

Phase 4: Factory Closing

A factory closes in one of two ways. In the cooperative case, all participants agree on final balances and sign a single closing transaction that distributes funds on-chain. This is the ideal outcome: one on-chain transaction opens the factory, one closes it, and everything in between happened off-chain.

In the uncooperative case, any participant can unilaterally close by publishing the most recent allocation transaction. This puts individual channel states on-chain, where they can be settled using standard Lightning dispute resolution ( justice transactions and revocation keys). The on-chain cost in this scenario is higher, but no participant can lose funds.

On-Chain Savings

The efficiency gains from channel factories depend on factory size and how long participants keep the factory open. The following table illustrates the on-chain transaction requirements for managing channels with and without factories.

The savings scale with factory size and lifetime. A factory of 100 participants managing hundreds of channels could reduce per-channel on-chain costs by two orders of magnitude compared to individually funded channels.

Why Channel Factories Are Not Deployed

Despite being proposed in 2018, no production Lightning implementation supports channel factories today. The barriers are both technical and coordination-related.

The n-of-n Coordination Problem

Factory allocation updates require signatures from every participant. If any single participant goes offline, the entire factory cannot update its allocation layer. In a factory of 10 participants, the probability of at least one being offline at any given moment is significant. In a factory of 100, it approaches certainty.

This creates a tension: larger factories offer better on-chain amortization but worse coordination properties. Small factories (3-5 participants) are feasible but offer modest savings. The optimal factory size remains an open research question.

State Management Complexity

The original channel factory proposal relies on the same penalty-based revocation mechanism used in current Lightning channels (LN-Penalty). Managing revoked states across three transaction layers, with n participants at the allocation layer, introduces substantial complexity. Each allocation update invalidates the previous state, requiring all participants to store and potentially enforce revocation data.

Eltoo (also called LN-Symmetry) would dramatically simplify this. Instead of penalty-based revocation, eltoo allows any later state to simply replace an earlier one on-chain without punishment mechanisms. This eliminates the need to store all prior states and reduces the risk of accidental old-state publication. However, eltoo requires a Bitcoin soft fork to enable SIGHASH_ANYPREVOUT (BIP 118), which has not yet been activated.

Covenant Requirements

Several advanced factory designs rely on Bitcoin covenants: script-level restrictions on how transaction outputs can be spent. Covenants would enable more flexible factory constructions where participants can exit individually without forcing the entire factory to close. Proposals like CTV (CheckTemplateVerify, BIP 119), APO (BIP 118), and OP_CAT would each unlock different factory optimizations.

Without covenants, factories face a binary choice: either all participants cooperate, or the factory state must be fully published on-chain. There is no efficient middle ground for partial exits.

The chicken-and-egg problem: Channel factories would benefit enormously from soft fork upgrades like SIGHASH_ANYPREVOUT and CTV. But the urgency for those upgrades is partly driven by the need for constructions like channel factories. Without deployed factories demonstrating demand, consensus for protocol changes proceeds slowly.

SuperScalar: A Practical Path Forward

In 2024, developer ZmnSCPxj proposed SuperScalar, a channel factory design that works without any Bitcoin consensus changes. SuperScalar combines three existing techniques: Decker-Wattenhofer decrementing-nSequence channels, timeout trees, and laddered maturities.

Decker-Wattenhofer Channels

Unlike the penalty-based LN-Penalty mechanism, Decker-Wattenhofer state channels use decrementing nSequence timelocks to order states. Each new state has a shorter timelock than the previous one, so the latest state confirms first if published on-chain. This avoids the complexity of revocation and justice transactions but introduces a limited number of state updates, bounded by the initial timelock value.

Timeout Trees

SuperScalar structures the factory as a tree of transactions. A single LSP sits at the root and funds the tree, with end users at the leaves. The tree has a built-in timeout: after expiry, the LSP can reclaim funds from inactive leaves without requiring cooperation from those users. Before timeout, users can unilaterally exit by publishing their path from leaf to root.

Laddered Maturities

Rather than a single factory with one timeout, SuperScalar uses multiple overlapping factories with staggered expiration dates. As one factory approaches its timeout, users migrate their channels to a newer factory. This prevents the entire user base from needing to settle on-chain simultaneously.

SuperScalar makes practical tradeoffs: it sacrifices the theoretical elegance of unlimited off-chain updates in exchange for deployability on Bitcoin as it exists today. The LSP-centric design also reflects the reality that most Lightning users already interact through service providers rather than running fully sovereign routing nodes.

Channel Factories and the Broader Scaling Landscape

Channel factories represent one approach within a broader design space for reducing Lightning's on-chain footprint. Other proposals address the same problem from different angles.

The Ark protocol uses virtual UTXOs (vTXOs) to enable off-chain transfers with periodic on-chain settlement rounds. Like channel factories, Ark amortizes on-chain costs across many users, but it uses a fundamentally different architecture based on an always-available service provider (ASP) rather than multi-party channels.

Splicing allows channels to add or remove funds without closing, reducing but not eliminating on-chain transactions. Combined with zero-conf channels, splicing improves the UX of channel management but does not address the fundamental per-channel on-chain requirement.

Spark takes a different approach entirely. Rather than optimizing the channel model, Spark uses statechains to transfer Bitcoin ownership off-chain without channels at all. There is no factory coordination, no n-of-n signing for allocation changes, and no on-chain footprint per transfer. The tradeoff is a different trust model: Spark relies on at least one operator in its FROST threshold signing set behaving honestly, rather than the fully trustless model of Lightning channels.

Open Research Questions

Several unresolved questions affect whether channel factories will see production deployment:

• Optimal factory size: what is the right tradeoff between on-chain savings and coordination failure probability? Simulation results suggest 5-10 participants may be practical, but real-world data is lacking
• Incentive design: how should factory participants be compensated for the coordination overhead? Current Lightning routing fee models do not account for factory maintenance costs
• Factory-aware routing: should the Lightning gossip protocol (the BOLT specifications) be extended to advertise factory membership, enabling routing algorithms to prefer intra-factory paths?
• Interaction with anchor outputs and ephemeral dust: how do recent Lightning protocol upgrades affect factory transaction structures and fee bumping strategies?

Conclusion

Channel factories address a real limitation in Lightning's architecture: the per-channel on-chain cost that fundamentally limits how many channels Bitcoin can support. The original Burchert-Decker-Wattenhofer design demonstrated the concept elegantly, and SuperScalar shows a path to deployment without protocol changes.

The challenges are equally real. N-of-n coordination, state management complexity, and the lack of covenant support on Bitcoin today constrain what factories can achieve in practice. These are engineering problems with potential solutions, but none are trivial.

Meanwhile, the scaling problem that factories aim to solve is being addressed through multiple complementary approaches. Splicing reduces unnecessary channel closures. Ark reimagines the off-chain model entirely. Spark eliminates the channel abstraction altogether. The future of Bitcoin scaling likely involves not one of these solutions but a combination, each serving different users and use cases based on their specific tradeoff preferences.

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.