The Lightning Network made payment channels practical at scale, but its complexity and liquidity requirements have spurred research into alternative Layer 2 designs. This chapter examines emerging protocols—Ark, Statechains, Channel Factories, and others—that offer different tradeoffs in interactivity, liquidity, and on-chain footprint. These systems are also what the covenant primitives of Chapter 30 would buy: several become simpler, safer, or possible at all given CTV or ANYPREVOUT.
32.1 Lightning's Limitations
Understanding new L2 proposals requires understanding Lightning's constraints.
Remark 32.1 (Lightning's Constraints)
Lightning Network faces several practical challenges:
- Inbound liquidity: Receivers need channel capacity toward them
- Online requirement: Must be online to receive payments
- Channel management: Opening/closing requires on-chain txs
- Routing complexity: Finding paths is non-trivial
- Capital efficiency: Liquidity locked in channels
32.2 Ark Protocol
Ark is a new L2 design that trades interactivity for simplicity.
Example 32.1 (Ark)
Ark is an off-chain payment protocol in which:
- An Ark Service Provider (ASP) facilitates payments
- Users hold virtual UTXOs (vTXOs) in shared outputs
- Payments happen by exchanging vTXOs
- No inbound liquidity needed
- Can receive while offline
Definition 32.1 (Ark Round)
The ASP periodically creates a round (the design calls for rounds every few seconds; deployed implementations batch less frequently):
- Collects payment intents from users
- Creates new shared UTXO containing all recipients' vTXOs
- Creates transaction tree allowing unilateral exit
- Publishes round transaction
Remark 32.2 (Ark Properties)
Ark provides:
- Non-interactive receiving: Recipient does not need to be online
- No inbound liquidity: ASP provides liquidity for everyone
- Unilateral exit: Before vTXO expiry, users can claim on-chain without ASP cooperation
- Privacy: Payments within rounds are unlinkable
Tradeoffs:
- ASP trust: Liveness trust before vTXO expiry
- Expiring vTXOs: Must refresh before expiry; afterwards, unswept funds are claimable by the ASP
- ASP capital: ASP must lock significant BTC
The capital requirement admits a simple steady-state analysis.
Proposition 32.1 (ASP Capital Requirement)
Consider an ASP that processes payment volume v (in BTC per day) and whose vTXOs expire T days after issuance, so that the BTC the ASP advances into a round at time t is recovered only at time t + T. Then at steady state the ASP's locked capital is
C = v · T,
and the capital turnover rate (daily volume per unit of locked capital) is v/C = 1/T per day.
Proof.
At time t, the advances still locked are exactly those made during the interval (t − T, t]: earlier advances have expired and been swept back by the ASP. At steady state the ASP advances v BTC per day, so the locked total is C = v · T. Dividing the daily volume by this capital gives the turnover rate v/C = 1/T. □
Example 32.2 (Ark Capital Turnover)
An ASP has 100 BTC locked and processes 1,000 payments per day of average size 0.01 BTC, a volume of v = 1,000 × 0.01 = 10 BTC per day. The turnover rate is v/C = 10/100 = 0.1 per day: each bitcoin of ASP capital supports 0.1 BTC of daily volume, so the capital cycles once every 10 days. By Proposition 32.1 this is the steady state of a vTXO expiry of T = C/v = 10 days; halving the expiry to 5 days would halve the capital requirement to 50 BTC for the same volume.
Remark 32.3 (Ark vs Lightning)
| Property | Lightning | Ark |
|---|---|---|
| Receive offline | No | Yes |
| Inbound liquidity | Required | Not needed |
| Payment latency | Instant | Round time (design target ~5s) |
| Channel management | Complex | None |
| Requires covenants | No | Optimal with CTV |
32.3 Statechains
Statechains enable off-chain UTXO transfer without channels.
Definition 32.2 (Statechain)
A statechain transfers UTXO ownership off-chain:
- UTXO is locked to a 2-of-2: user key + statechain entity (SE) key
- Transfer: user sends their key share to recipient, and the SE atomically re-randomizes the shares so the old owner's copy becomes useless
- SE cannot steal unilaterally, assuming it deletes prior key shares as the protocol requires (an SE retaining old shares can collude with a past owner); it can censor
- Backup transaction allows unilateral on-chain claim
Example 32.3 (Mercury Layer)
Mercury Layer is a statechain implementation using:
- Blind signing by the SE (it does not learn transaction details)
- Atomic swaps between statechains
- Fixed denominations for privacy
Remark 32.4 (Statechain Trust Model)
Statechain security properties:
- SE cannot steal: Only has partial key
- SE can censor: Can refuse to co-sign
- SE can collude: With previous owner to double-spend
- Backup tx: Allows on-chain exit if SE disappears
32.4 Channel Factories
Channel factories amortize on-chain costs across multiple channels.
Definition 32.3 (Channel Factory)
A channel factory is a multi-party channel that can create and modify internal channels without on-chain transactions:
- N parties create a single on-chain funding output
- Off-chain, they create internal Lightning channels
- Channels can be rebalanced without on-chain txs
- Only factory open/close needs on-chain presence
Remark 32.5 (Factory Scaling)
For a factory with n participants:
- On-chain cost: 1 UTXO (amortized over n users)
- Channel creation: O(n) signatures, no on-chain tx
- Complexity: All n must sign for factory updates
Remark 32.6 (Factory Challenges)
Channel factories face practical issues:
- Coordination: All parties must be online to update factory
- One bad actor: Can force expensive on-chain closure
- Complexity: State management is complex
- Covenants would help: CTV could simplify coordination
Proposition 32.2 (Factory Availability)
Suppose each of the n participants in a channel factory is online independently with probability p when an update is attempted. Then the probability that the update can proceed is
P(all n online) = p^n,
the probability that at least one participant is offline is 1 − p^n, and the expected number of attempts until a successful update is 1/p^n. In particular, update availability decays exponentially in n.
Proof.
Let A_i be the event that participant i is online, with P(A_i) = p. A factory update requires all n signatures (Definition 32.3), so it succeeds exactly on the event A_1 ∩ ⋯ ∩ A_n, which by independence has probability p^n. The complement has probability 1 − p^n, and the number of independent attempts until the first success is geometric with mean 1/p^n. Since p < 1, p^n decreases exponentially as n grows. □
Example 32.4 (Ten-Party Factory Update)
Take n = 10 participants with 95% individual uptime. By Proposition 32.2 the probability that an update attempt succeeds is 0.95^10 ≈ 0.599, so about 40% of attempts (1 − 0.599 ≈ 0.401) find at least one participant offline, and on average 1/0.599 ≈ 1.67 attempts are needed per update. Even with high individual uptime, a ten-party factory is updateable only about 60% of the time: this makes the coordination cost of Remark 32.6 quantitative.
32.5 LN-Symmetry (Eltoo)
LN-Symmetry is a symmetric channel design that removes the penalty mechanism; it requires SIGHASH_ANYPREVOUT.
Example 32.5 (LN-Symmetry)
LN-Symmetry (formerly Eltoo) simplifies Lightning channels:
- No asymmetric states—both parties have the same commitment tx
- No penalty mechanism needed
- State updates can be "rebased" on any prior state
- Requires ANYPREVOUT (BIP-118)
Remark 32.7 (Eltoo Advantages)
LN-Symmetry improves on LN-Penalty:
- No toxic waste: Old states do not risk fund loss
- Simpler watchtowers: Only need latest state
- Multi-party channels: Simpler to implement than penalty-based channels
- Smaller closure: Fewer transactions needed
32.6 Comparison Summary
| Protocol | Requires | Best For | Tradeoff |
|---|---|---|---|
| Lightning | Current Bitcoin | Payments | Liquidity, online |
| Ark | CTV (optimal) | Easy onboarding | ASP availability |
| Statechains | Current Bitcoin | UTXO transfer | Fixed amounts |
| Factories | CTV (optimal) | LN scaling | Coordination |
| LN-Symmetry | ANYPREVOUT | Cleaner LN | Soft fork needed |
Exercises
Exercise 32.1
An ASP has 50 BTC locked and processes 4,000 payments per day of average size 0.005 BTC. Compute the daily payment volume and the capital turnover rate. Using Proposition 32.1, what vTXO expiry is consistent with this steady state? How much capital would the ASP need if it doubled its volume while extending the expiry to 7 days?
Exercise 32.2
Design a hybrid protocol combining Lightning and Ark. How would you handle payments between users on different systems?
Exercise 32.3
Analyze the statechain double-spend attack. What makes it possible, and what mechanisms could reduce the risk?
Exercise 32.4
A channel factory has 15 participants, each independently online 98% of the time. Using Proposition 32.2, compute the probability that a factory update attempt succeeds and the probability that at least one participant is offline. Keeping p = 0.98, how large can n grow before the success probability falls below one half?