Channel Reserve

What Is a Channel Reserve?

A channel reserve is the minimum number of satoshis each participant in a Lightning Network payment channel must hold in their local balance at all times. This reserve cannot be spent, routed, or offered as part of an HTLC. It exists to ensure that both parties always have something to lose if they attempt to cheat by broadcasting an old, revoked commitment transaction.

Think of it as a security deposit. When you open a channel, each side locks up a small portion of the funds as collateral. This collateral underwrites honest behavior: a party that cheats forfeits not just their reserve, but their entire channel balance through the penalty mechanism.

The BOLT #2 specification defines the channel_reserve_satoshis parameter, which each peer sets for the other during channel opening. In the newer dual-funded channel protocol, the reserve is fixed at 1% of total capacity (or the dust limit, whichever is greater) and is no longer negotiable.

How It Works

During channel establishment, both peers exchange reserve requirements as part of the open_channel and accept_channel messages. Each party specifies the reserve that the other side must maintain: the value you set in your message is the minimum balance your peer must keep, not your own.

Reserve Negotiation

The protocol enforces several validation rules before a channel can open:

1. The channel reserve must be greater than or equal to the dust limit (minimum 354 satoshis for unknown SegWit outputs)
2. Both sides must validate that the other's reserve is above both dust limits to ensure commitment transaction outputs are never trimmed
3. The initial commitment transaction must leave at least one side with a balance above the reserve (otherwise neither party could be penalized)

For the original (v1) channel establishment, the reserve amount is a proposal: if either side finds it unacceptable, the channel simply fails to open. For dual-funded (v2) channels, the reserve is computed automatically:

reserve = max(
  floor(total_channel_capacity * 0.01),
  dust_limit_satoshis
)

Enforcement During Channel Operation

Once a channel is open, the reserve is enforced on every state update. A node must not offer a new HTLC if doing so would push its own balance below the reserve after accounting for commitment transaction fees. The fee-paying party (typically the channel opener) faces a stricter constraint: they must maintain enough balance to cover both the reserve and the commitment transaction fee at the current feerate.

The specification recommends a "fee spike buffer" that can handle twice the current feerate above the reserve. Without this buffer, sudden fee increases can push the funder below their reserve, creating a stuck channel where no new HTLCs can be added in either direction.

Progress Toward Reserve

When a channel opens, the non-funding side starts with a zero balance, which is below the reserve. The protocol allows this initial violation but enforces that every subsequent update moves toward meeting the reserve. Once the reserve threshold is reached (through receiving payments), it must be maintained from that point forward.

Connection to the Penalty Mechanism

The reserve derives its purpose from Lightning's revocation-based security model. Each time the channel state updates, both parties exchange revocation keys for the previous state. If Alice broadcasts an old commitment transaction that shows her with more funds than she currently has, Bob can use the revocation key to construct a justice transaction claiming all funds in the channel.

The reserve ensures this penalty always has real economic weight. If Alice could drain her side to zero satoshis, she could attempt to broadcast an old, favorable state with nothing to lose: the justice transaction would claim zero. By requiring a minimum balance, the protocol guarantees that cheating always costs the attacker real money.

How Reserves Affect Usable Capacity

The practical impact of channel reserves is reduced spendable capacity. Your effective outbound liquidity equals your channel balance minus your reserve:

spendable_balance = local_balance - channel_reserve

# Example: 5,000,000 sat channel, you hold 2,500,000 sats
# Reserve: 50,000 sats (1% of capacity)
# Spendable: 2,450,000 sats

Small channels are disproportionately affected. A 100,000 satoshi channel reserves 1,000 satoshis per side (2,000 total), which is a minor inconvenience. But for very small channels, the reserve plus commitment transaction fees can consume a meaningful percentage of the total capacity.

For a deeper look at how reserves interact with routing and balance management, see the Lightning channel management guide and the Lightning liquidity explainer.

Interaction With Dust Limits

The specification requires that the channel reserve always exceeds the dust limit. This cross-validation serves a critical purpose: if the reserve were below the dust threshold, the corresponding output on a commitment transaction could be trimmed as dust by miners, making the penalty mechanism unenforceable.

Standard dust limits vary by output type: 294 satoshis for P2WPKH, 330 for P2WSH, and 354 for unknown SegWit versions (the mandatory floor per BOLT #2). The channel reserve must exceed all applicable dust limits to guarantee that the to_local and to_remote outputs always appear on-chain.

Zero-Reserve Channels

Zero-reserve channels eliminate the reserve requirement entirely, making 100% of the channel capacity spendable. The option_zero_reserve feature (feature bits 64/65) was proposed in BOLT PR #1140 in early 2024 and is currently awaiting interoperability testing between implementations.

When option_zero_reserve is negotiated, one node signals that its peer may set channel_reserve_satoshis to zero. This is most common in asymmetric trust relationships:

• Lightning Service Providers (LSPs) waiving the reserve for mobile wallet users, giving them access to their full channel balance
• Channels between entities with existing business relationships where the economic incentives against cheating outweigh the reserve guarantee

Implementation Support

Eclair (the engine behind the Phoenix wallet) deployed zero-reserve support in production, where ACINQ as the LSP waives the user-side reserve. LDK (Rust-Lightning) has merged support for accepting zero-reserve channels from peers. LND and Core Lightning do not yet offer specific zero-reserve functionality.

Trust Implications

Without a reserve, a counterparty who drains their balance to zero has nothing at risk if they broadcast a revoked state. There is no output for a justice transaction to claim. This trade-off is acceptable when:

• The LSP maintains its own reserve (has skin in the game) while waiving the user's reserve
• The counterparty has strong business or reputational incentives against cheating
• The channel uses anchor outputs, ensuring at least one non-dust output exists on the commitment transaction

For peer-to-peer channels between untrusted nodes, zero reserve removes the economic deterrent against fraud and is generally not recommended.

Use Cases

Routing Node Operation

Routing nodes must account for reserves when calculating available liquidity. A channel that appears to have 1,000,000 satoshis of outbound capacity may only have ~990,000 satoshis available for forwarding after the reserve. Nodes that ignore this will create failed routing attempts and earn a lower reputation in pathfinding algorithms.

Mobile Wallet UX

For mobile users with a single channel to their LSP, the reserve directly reduces their spendable balance. A user who receives exactly 100,000 satoshis can only spend approximately 99,000 of them. Zero-reserve channels (as deployed by Phoenix) solve this UX friction by letting users spend their full balance.

Channel Sizing

The 1% reserve means that channel sizing decisions should account for the locked capital. Opening many small channels creates more aggregate locked-up reserves compared to fewer, larger channels. Splicing allows resizing channels without closing them, and the reserve recalculates to 1% of the new total after a splice operation.

Recent Developments

Several protocol improvements are reshaping how channel reserves work:

• Zero-fee commitments (feature 40/41, proposed February 2025): a new channel type using v3 transactions where commitment transactions pay zero mining fees. This eliminates the update_fee message entirely, removing the race condition where fee updates can push the funder below their channel reserve
• Splicing support across Eclair, Core Lightning, and LDK: dynamically resizing channels recalculates the reserve automatically, reducing the friction of managing locked capital
• The fee spike buffer recommendation: the specification now advises maintaining enough balance above the reserve to handle twice the current feerate, preventing channels from becoming stuck during fee spikes

For more on how these protocol-level changes affect channel management, see the research on splicing Lightning channels and payment channels from concept to implementation.

Risks and Considerations

Stuck Channels

If on-chain fees rise sharply, the fee-paying party (usually the channel opener) may find that their balance minus fees falls below the reserve. In this state, no new HTLCs can be added in either direction, effectively freezing the channel. The only options are waiting for fees to drop or performing a force close.

Capital Inefficiency

Reserves lock up capital that cannot be used for payments or routing. For large routing nodes operating hundreds of channels, the aggregate reserve represents significant idle capital. This is an inherent trade-off between security and capital efficiency in Lightning's design.

Small Channel Fragility

Very small channels suffer the most from reserves. Between the reserve, the dust limit, and commitment transaction fees, a channel with only tens of thousands of satoshis may have very little usable capacity. Layer 2 solutions like Spark address this by operating without Lightning-style channels, eliminating the reserve requirement entirely while maintaining self-custody.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.