Channel Reserve

What Is Channel Reserve?

Channel reserve is a protocol-enforced minimum balance that each participant must maintain in a Lightning Network payment channel. When you open a channel with 1,000,000 satoshis, you cannot spend the full amount. A portion, typically 1% of the channel capacity, must remain locked as your reserve balance.

This reserve serves as a form of security deposit. If you attempt to cheat by broadcasting an old channel state (claiming more funds than you should have), your counterparty can penalize you by taking the entire channel balance, including your reserve. The reserve ensures you always have something to lose, making honest behavior the economically rational choice.

The concept originates from the BOLT #2 specification, which defines the peer protocol for channel establishment. Both parties negotiate reserve requirements during channel opening, and these constraints remain enforced throughout the channel's lifetime.

Why Channel Reserves Exist

Channel reserves solve a fundamental game-theoretic problem in payment channels. Without reserves, a party with zero balance has nothing at stake and nothing to lose from cheating attempts.

Preventing Costless Fraud Attempts

Consider a scenario without reserves: Alice opens a channel with Bob and sends her entire balance to Bob through payments. Alice now has zero sats in the channel. If Alice broadcasts an old state showing she has funds, what does she lose if caught? Nothing. She had zero anyway. Bob would need to detect and respond to the fraud, incurring costs even if he successfully defends.

With reserves, Alice can never reduce her balance below the reserve threshold. Even at her minimum balance, she has sats at stake. Attempting fraud means risking that reserve to Bob's penalty mechanism. The reserve makes cheating economically irrational.

Ensuring Closure Fee Coverage

Beyond fraud prevention, reserves ensure both parties can cover on-chain transaction fees if the channel needs to be force-closed. Force-closing a channel requires broadcasting a commitment transaction, which requires miner fees. The reserve guarantees each party has funds to pay their share of closing costs.

During periods of high on-chain fee rates, this becomes particularly important. A channel where one party has zero balance might become unstuckable if that party cannot afford the fees required to close it on-chain.

Maintaining Penalty Mechanism Effectiveness

Lightning's security model relies on penalty transactions. If your counterparty broadcasts an old state, you can take their entire balance as punishment. This penalty only works as a deterrent if there is something to take. Reserves ensure the penalty mechanism always has meaningful funds to claim.

How Channel Reserves Work

Reserve requirements are negotiated during channel establishment and enforced throughout the channel's operation.

Negotiation During Channel Open

When two nodes open a channel, they exchange open_channel and accept_channel messages. Each message includes a channel_reserve_satoshis field specifying the reserve the sender requires from their counterparty.

Each node sets the reserve requirement for their counterparty. Alice specifies how much Bob must keep in reserve, and Bob specifies how much Alice must keep. This allows each party to set their own risk tolerance. If the proposed reserves are unacceptable to either party, they can refuse to open the channel.

Enforcement During Operation

Once a channel is open, every payment and HTLC operation must respect reserve constraints. A node will reject any proposed channel state update that would push its counterparty below the required reserve.

This enforcement happens locally at each node. When Alice proposes sending funds to Bob, both Alice's node and Bob's node verify that the resulting balances maintain proper reserves. If the payment would violate reserves, it fails.

Reserve and Channel Capacity

The relationship between reserve and channel capacity is asymmetric at channel creation. Initially, the channel funder holds all the funds. The non-funder starts with zero balance, technically below any reserve requirement. The protocol handles this through the push_msat mechanism, which can transfer initial funds to the non-funder.

The reserve requirement only applies once a party has received funds. You cannot receive payments that would leave you above zero but below the reserve. The first payment you receive must bring you at or above the reserve threshold.

Reserve Calculations

The standard reserve calculation in most Lightning implementations is 1% of the channel capacity, with minimum and maximum bounds.

Standard Formula

reserve = max(dust_limit, min(channel_capacity * 0.01, max_reserve))

# Example for a 10,000,000 sat channel:
reserve = max(546, min(10000000 * 0.01, 100000))
reserve = max(546, min(100000, 100000))
reserve = 100,000 sats

Dust Limit Floor

The reserve cannot go below the dust limit, typically 546 satoshis for standard transactions. Outputs below the dust limit are uneconomical to spend and would be rejected by the Bitcoin network. This creates a minimum viable reserve regardless of channel size.

Implementation Variations

Different Lightning implementations may use slightly different reserve calculations:

• LND: Uses 1% with a minimum of 1% of funding amount or the dust limit, whichever is higher.
• Core Lightning: Defaults to 1% of channel value.
• Eclair: Configurable reserve percentage with sensible defaults.

Liquidity Implications

Channel reserves directly impact how much of your channel capacity is actually usable for payments. This creates practical constraints that node operators must account for.

Reduced Effective Capacity

A 1,000,000 sat channel does not provide 1,000,000 sats of payment capacity. With 1% reserves on both sides, only 980,000 sats can ever flow in either direction. For routing nodes managing many channels, these reserves accumulate into significant locked capital.

Small Channel Inefficiency

Reserve requirements make small channels particularly inefficient. A 100,000 sat channel loses 2,000 sats to reserves (1,000 per side), leaving 98% usable. But a 10,000 sat channel might lose 1,092 sats to dust-limit-floored reserves, leaving only about 89% usable.

Impact on Routing

Routing nodes cannot route payments that would push either party below their reserve. This means the maximum routable amount through a channel is less than the apparent available balance. Pathfinding algorithms must account for these constraints when calculating maximum payment amounts.

Optimization Strategies

Lightning developers and node operators have developed several approaches to minimize the liquidity impact of channel reserves.

Anchor Outputs

Anchor outputs change how closing transaction fees are handled. Instead of pre-committing to a fee rate in the commitment transaction, anchor outputs allow fees to be added at broadcast time using CPFP (Child Pays for Parent). This reduces the reserve needed for fee coverage, potentially allowing lower reserve requirements.

Zero-Reserve Channels

Some implementations support negotiating zero reserves for trusted counterparties. This maximizes liquidity efficiency but sacrifices the fraud protection that reserves provide. Zero-reserve channels are typically used between nodes operated by the same entity or between highly trusted partners.

Larger Channels

Opening fewer, larger channels improves reserve efficiency. Ten channels of 100,000 sats each lock up more in reserves than one channel of 1,000,000 sats. Consolidating liquidity into larger channels maximizes the percentage of capital that remains usable.

Wumbo Channels

Wumbo channels lift the default channel size limit, allowing channels larger than 0.16777216 BTC. For large node operators, wumbo channels dramatically improve capital efficiency by reducing the number of channels needed and thus the total reserve locked.

FAQ