• Channel Factories: Lightning’s Billion-User Problem
  • The Arithmetic Problem
  • The Original Vision: Burchert-Decker-Wattenhofer (2017)
    • Three-Layer Design
    • The Numbers
    • Why It Never Shipped
  • The Building Blocks: What Changed
    • Decker-Wattenhofer Decrementing nSequence Channels
    • Timeout Trees (John Law, 2023)
    • LN-Symmetry (Eltoo)
  • SuperScalar: The “No Soft Fork” Path (ZmnSCPxj, 2024)
    • Architecture
    • Key Properties
    • The LSP Last-Mile Problem
    • Pluggable Channel Factories
  • Ark and Spark: The Factories We Got Instead
    • Ark as Channel Factory
    • Spark as Channel Factory
  • The Tradeoff Landscape
  • The Covenant Chicken-and-Egg
  • My Analysis
  • Related Notes
  • Sources

§Channel Factories: Lightning’s Billion-User Problem

#bitcoin #lightning #scaling #channelfactories

The original Lightning whitepaper acknowledged it: serving 7 billion users with just two on-chain transactions per person per year would require 133 MB blocks. Channel factories are the answer that’s been on the drawing board since 2017 — and in 2026, they’re finally arriving, just not in the form anyone expected.

§The Arithmetic Problem

Lightning’s scaling bottleneck isn’t throughput — it’s onboarding. Bitcoin processes ~4,000 transactions per block, one block every ~10 minutes. Each Lightning channel needs at minimum two on-chain transactions over its lifetime (open + close). At 350,000 transactions per day and 3 transactions per user for Lightning setup, you can onboard ~116,000 people per day.

To onboard the global adult population: ~140 years.

That’s not a rounding error. That’s a fundamental architectural limitation. As of October 2025, Lightning had ~12,632 active nodes and ~43,758 channels holding ~4,053 BTC. As of early 2026: ~41,724 channels, ~3,853 BTC capacity. The network is shrinking slightly — fewer channels, less BTC locked. This isn’t growth hitting a wall; the wall was always there.

Channel factories solve this by amortizing: instead of one on-chain transaction per channel, one transaction funds many channels. The math shifts from 140 years to something tractable.

§The Original Vision: Burchert-Decker-Wattenhofer (2017)

Conrad Burchert, Christian Decker, and Roger Wattenhofer published Scalable Funding of Bitcoin Micropayment Channel Networks — the foundational channel factory paper. The architecture is elegant:

§Three-Layer Design

1. Funding layer: A single on-chain n-of-n multisig transaction. The only thing that touches the blockchain during normal operation.
2. Allocation layer: Off-chain transactions distributing pooled funds into individual two-party channel outputs. Requires all n parties to sign.
3. Channel layer: Standard Lightning channels that operate independently. Only the two counterparties need to coordinate.

The key insight: the allocation layer is what makes factories powerful. Restructuring this layer off-chain means participants can create, close, and rebalance channels without ever publishing a transaction.

§The Numbers

A factory of 100 participants could reduce per-channel on-chain costs by two orders of magnitude.

§Why It Never Shipped

Despite being proposed in 2017, no production Lightning implementation supports BDW channel factories today. Three problems killed it:

1. The n-of-n coordination problem. Allocation updates require every participant to sign. If any single participant goes offline, the factory can’t update. In a factory of 10, someone being offline is likely. In a factory of 100, it’s certain. Larger factories = better amortization but worse coordination.

2. State management complexity. The original design uses LN-Penalty (the same revocation-based mechanism as current Lightning channels). Managing revoked states across three transaction layers with n participants introduces enormous complexity. Each update invalidates the previous state, requiring all participants to store and enforce revocation data.

3. No partial exits. Without covenants, factories face a binary choice: either all participants cooperate, or the entire factory state must be published on-chain. If I close my channel, I drag everyone on my branch of the Merkle tree out of the factory with me. No efficient middle ground.

§The Building Blocks: What Changed

Three developments opened the door to practical channel factories:

§Decker-Wattenhofer Decrementing nSequence Channels

Before LN-Symmetry/Eltoo, Decker and Wattenhofer proposed a simpler state management mechanism. Instead of penalty-based revocation, each new state gets a shorter nSequence timelock than the previous one. The latest state confirms first if published on-chain.

Advantage: No revocation complexity. No justice transactions. Dramatically simpler. Disadvantage: Limited number of state updates, bounded by the initial timelock value. If you start at 1,000 blocks, you get at most ~1,000 updates.

This is the mechanism SuperScalar uses instead of waiting for a soft fork.

§Timeout Trees (John Law, 2023)

John Law’s insight: instead of a “real” channel factory where participants can reorganize liquidity freely, create a one-shot tree guaranteed by CTV with a special escape clause.

An LSP (Bob) creates a CTV tree from coins he controls, unfurling to open channels with any number of users. Critical features:

• No simultaneous online requirement. CTV lets Bob set up channels one at a time. Once confirmed, channels can’t be doublespent.
• Timeout sweep. Every branch has a script path where Bob can sweep funds after a timelock. This is the genius: channels have an expiration date.
• Rolling renewal. Before timeout, Bob opens a new Timeout Tree and users migrate their funds via Lightning. Old tree gets swept with one tx.

The catch: requires CTV, which doesn’t exist on mainnet yet.

§LN-Symmetry (Eltoo)

LN-Symmetry would solve the state management problem entirely. Any later state simply replaces an earlier one — no penalties, no revocation storage. This eliminates the biggest complexity barrier for N-party channel factories.

But it requires SIGHASH_ANYPREVOUT (BIP-118) or equivalent — also not on mainnet yet. The CTV+CSFS proposal could emulate it, but that activation attempt faces its own challenges.

§SuperScalar: The “No Soft Fork” Path (ZmnSCPxj, 2024)

ZmnSCPxj proposed SuperScalar in October 2024 as a channel factory design that works on Bitcoin as it exists today. No CTV, no APO, no consensus changes. It combines three techniques:

§Architecture

1. Decker-Wattenhofer channels for state management (bounded updates, but no soft fork needed)
2. Timeout trees for the factory structure (LSP at root, users at leaves)
3. Laddered maturities — overlapping factories with staggered expirations, so users migrate to newer factories before timeout

§Key Properties

§The LSP Last-Mile Problem

SuperScalar targets a specific pain point: new users receiving their first Bitcoin over Lightning must pay for incoming liquidity. An LSP opening channels to 1,000 users currently needs 1,000 on-chain transactions. SuperScalar collapses that to a handful.

§Pluggable Channel Factories

In November 2024, ZmnSCPxj proposed a follow-up: making channel factories pluggable into existing Lightning node software (CLN, LDK, Eclair, LND) via their plugin/extension mechanisms. The specification changes would allow the factory manager to send messages through LN nodes to local factory plugins.

René Pickhardt responded to the proposal — he’d been thinking along similar lines. As of October 2024 when asked about a prototype, ZmnSCPxj said “no prototype… just something I had in my mind for a couple weeks.” It’s still in the design/proposal stage.

§Ark and Spark: The Factories We Got Instead

“If it walks like a duck…” — Bitcoin Magazine

In 2025, Bitcoin Magazine published “Ark and Spark: The Channel Factories We’ve Been Waiting For.” The argument: while nobody shipped BDW factories, Ark and Spark effectively deliver the same economic function through different mechanisms.

§Ark as Channel Factory

Pickhardt published a key insight on Delving Bitcoin (December 31, 2025): Ark’s best use case might not be as an end-user payment solution but as a flexible channel factory for LSPs.

The idea: many channel owners batch their liquidity changes (opens, closes, splices) using Ark’s vTXO structure, dramatically reducing on-chain costs. LSPs use regular Ark batches to shift liquidity between channels instead of individual splice operations.

Greg Sanders replied that he’d been investigating similar possibilities using hArk (which requires CTV/OP_TEMPLATEHASH) to facilitate transferring Lightning channel state between batches.

Vincenzo Palazzo posted proof-of-concept code implementing an Ark channel factory. This is the closest thing to running code we have.

Optech Newsletter #387 (January 2026): “Ark-like structures containing Lightning channels have been discussed earlier… Pickhardt’s ideas focus on the possibility of many channel owners batching their channel liquidity changes.”

§Spark as Channel Factory

Spark (Lightspark, David Marcus) launched on mainnet in May 2025 and represents a different approach:

• Statechain-based ownership transfer via private key delegation
• Spark Operators (SOs) consortium holds shared signing keys with users
• Moment-in-time trust: trust required only at transfer; once operators delete old key shares, perfect forward security
• Native Lightning interop via atomic swaps through LSPs

Q2 2026 roadmap (announced January 2026): cheapest BTC acquisition, one-tap cross-chain swaps, stablecoins on Bitcoin, wallet/neobank integrations.

Both Ark and Spark achieve the channel factory goal — reduced chain usage, scalable liquidity allocation — while sidestepping the coordination problems that killed BDW factories. Neither requires a soft fork.

§The Tradeoff Landscape

Every factory design navigates the same tension: amortization efficiency vs. coordination complexity vs. trust assumptions.

The uncomfortable truth: the most practical designs all introduce a trusted service provider. The fully trustless BDW design requires everyone to be online and either a soft fork (Eltoo) or enormous state complexity (LN-Penalty). This isn’t a failure — it’s the honest engineering reality of what’s deployable today.

§The Covenant Chicken-and-Egg

Channel factories are the strongest practical argument for covenants:

• CTV enables timeout trees without interactive signing — the LSP can pre-commit exit paths for thousands of users
• CTV+CSFS together emulate APO, enabling LN-Symmetry, which makes N-party channel management tractable
• OP_CAT could enable even more flexible factory constructions

But the urgency for covenants is partly driven by the need for constructions like channel factories. Without deployed factories demonstrating demand, consensus for protocol changes proceeds slowly. Meanwhile, CTV activation signaling starts March 30, 2026 — 8 days from now.

The no-fork alternatives are changing the calculus. Binohash achieves covenant-like behavior on mainnet today. PIPEs V2 uses witness encryption. If these prove robust, the political urgency for a soft fork diminishes even as the technical case remains strong.

§My Analysis

Channel factories are simultaneously the most important unsolved problem in Bitcoin scaling and the one making the most progress — just not through the path anyone expected.

What I think:

1. BDW factories will never ship in their original form. The n-of-n coordination problem is lethal at scale, and LN-Penalty state management is prohibitively complex for more than ~5 parties. This design needs Eltoo, and Eltoo needs a soft fork.

2. SuperScalar is the right idea at the wrong time. It’s architecturally sound and doesn’t need a soft fork, but it’s still a design on a forum. No implementation, no funding announcements, no LSP has committed to building it. The Decker-Wattenhofer bounded-update limitation is a real constraint that limits practical factory lifetime.

3. Ark-as-factory is the most promising near-term path. Pickhardt’s reframing is brilliant: stop thinking of Ark as a consumer payment layer and start thinking of it as infrastructure for Lightning. The proof-of-concept code from Palazzo shows this isn’t just theory. Ark’s round-based batching maps naturally to LSP channel management cycles.

4. Spark is winning the deployment race because it made pragmatic trust assumptions. The 1-of-n honest operator model is reasonable for most users’ threat models. David Marcus’s fintech background shows in the product focus (cheapest BTC acquisition, one-tap swaps, stablecoin integration). But the trust model means it’s not solving the sovereignty problem.

5. The real factory will be invisible. Users won’t know or care that their channels are inside a factory. LSPs will adopt whatever reduces their on-chain costs. The winning design is whichever ships first with acceptable trust tradeoffs and integrates into existing wallet infrastructure.

6. Lightning’s capacity metrics are misleading. The ~42K public channels with ~3,800 BTC don’t capture private channels, LSP-managed channels, or the growing proportion of Lightning activity that happens through custodial or semi-custodial services. The network is bigger than the numbers suggest, but the per-channel on-chain cost is still the binding constraint.

The 140-year onboarding timeline isn’t just a thought experiment — it’s the hard ceiling. Without channel factories (or equivalent shared-UTXO constructions), Lightning cannot serve more than maybe 50-100 million self-custodial users. Factories don’t eliminate the on-chain footprint; they compress it by 10-100x. That’s the difference between decades and years.

The irony: the vision of fully trustless, N-party channel factories coordinated via Eltoo remains the technically correct answer. But engineering ships products, not proofs. And in 2026, the products that are shipping all introduce a service provider.

§Related Notes

• LN-Symmetry - Fixing Lightning’s Foundation — the soft fork upgrade that would make BDW factories practical
• Bitcoin Covenants - The Next Soft Fork — CTV/CSFS, the consensus changes factories need
• The CTV Activation Attempt - Bitcoin’s Political Crucible — signaling starts March 30
• Ark Protocol - Bitcoin L2 — Ark’s architecture, now reconceived as factory infrastructure
• Spark - Bitcoin Statechain L2 — Lightspark’s mainnet L2
• Replacement Cycling Attacks - Lightning’s Mempool Achilles Heel — security issues factories must address
• Bitcoin eCash - Cashu and Fedimint — the alternative scaling path via custodial ecash
• The Agentic Economy - SaaSpocalypse and the Rise of Micro-Firms — agent payments need scalable Lightning

§Sources

• Burchert, Decker, Wattenhofer — Scalable Funding of Bitcoin Micropayment Channel Networks (2017)
• ZmnSCPxj — SuperScalar: Laddered Timeout-Tree-Structured Decker-Wattenhofer Factories (Delving Bitcoin, Oct 2024)
• ZmnSCPxj — Pluggable Channel Factories (Delving Bitcoin, Nov 2024)
• René Pickhardt — Ark as a Channel Factory (Delving Bitcoin, Dec 2025)
• John Law — Timeout Trees (Lightning-Dev mailing list, Sep 2023)
• Bitcoin Optech Newsletters #327, #330, #387
• Bitcoin Magazine — “Ark and Spark: The Channel Factories We’ve Been Waiting For” (Sep 2025)
• Spark Research — Channel Factories: Nested Channels for Lightning Scalability (Feb 2026)
• Lightning Network Statistics: 1ML, Nature Scientific Data (Oct 2025)