Fee Reserve

What Is a Fee Reserve?

A fee reserve is the amount of Bitcoin held back within a Lightning channel to guarantee that the commitment transaction can pay sufficient miner fees if it needs to be broadcast on-chain. Every Lightning channel maintains a commitment transaction: a pre-signed Bitcoin transaction that represents the current balance split between the two channel parties. If one party needs to close the channel unilaterally, this commitment transaction must be broadcast and confirmed by Bitcoin miners, which requires paying an on-chain fee rate.

The fee reserve exists because on-chain fee rates are unpredictable. A channel opened when fees are 5 sat/vB might need to close when fees spike to 100 sat/vB or higher. If the commitment transaction does not carry enough fees to be mined promptly, the closing party risks having their transaction stuck in the mempool during a critical moment, potentially enabling their counterparty to broadcast a more favorable (or fraudulent) transaction first.

How It Works

In the original Lightning protocol design (pre-anchor channels), the fee reserve operates through a direct deduction from the channel funder's balance on the commitment transaction.

Commitment Transaction Fee Calculation

The BOLT 3 specification defines how commitment transaction fees are computed. The fee is calculated by multiplying the negotiated fee rate (in satoshis per 1000 weight units) by the transaction's expected weight:

fee = feerate_per_kw × commitment_tx_weight / 1000

# Base commitment weight (no HTLCs, no anchors):
# ~724 weight units ≈ 181 vbytes

# Each additional HTLC output adds ~172 weight units

# With anchor outputs, add ~224 weight units
# for the two anchor outputs

The channel funder (the party that opened the channel) pays this fee by having it deducted from their output on the commitment transaction. This means the funder's spendable balance is always the committed amount minus the current fee obligation.

Dynamic Fee Updates

Because on-chain fee rates fluctuate, the Lightning protocol includes the update_fee message. The channel funder can propose a new fee rate at any time, and the counterparty can accept or reject it. When a new fee rate is accepted:

1. Both parties recalculate the commitment transaction fee at the new rate
2. The funder's balance is adjusted to cover the difference
3. New commitment transactions are signed with the updated fee

If a fee update would push the funder's balance below the channel reserve requirement (typically 1% of channel capacity), the update is rejected. This creates a scenario where a channel might be stuck with an outdated fee rate during fee spikes.

Impact on Effective Channel Capacity

The fee reserve directly reduces the amount of Bitcoin available for payments. Consider a 1 million satoshi channel with a 10 sat/vB fee rate:

Channel capacity:         1,000,000 sats
Channel reserve (1%):       -10,000 sats
Commit fee (~181 vB):        -1,810 sats
                           ─────────────
Effective sendable:          988,190 sats

During high-fee periods, this reserve grows significantly. At 100 sat/vB, the commit fee alone consumes roughly 18,100 sats. For small channels, this can represent a meaningful percentage of total capacity. Channels with many pending HTLCs have even larger commitment transactions, further increasing the required fee reserve.

Fee Reserve vs. Channel Reserve

These two concepts are frequently confused but serve entirely different purposes:

Both reserves reduce effective channel capacity, but they stack: a channel's true spendable balance is the total capacity minus the channel reserve for both sides minus the current commit fee. For a deeper comparison, see Bitcoin fee market dynamics.

The Anchor Output Evolution

The original fee-reserve model created several problems. The funder had to predict future fee rates accurately at channel-open time, and the update_fee mechanism added complexity without fully solving the prediction problem. If the funder estimated too low, force-close transactions could get stuck. If they estimated too high, capacity was wasted on excessive reserves.

Anchor outputs fundamentally changed this model. Introduced as an optional commitment format in BOLT 3, anchor outputs add small outputs (330 satoshis each) to the commitment transaction that either party can spend. This enables fee bumping via Child-Pays-For-Parent (CPFP) after the commitment transaction is broadcast.

How Anchors Reduce the Fee Reserve

With anchor outputs, the commitment transaction can be signed at a minimal fee rate (as low as 1 sat/vB in some implementations). When a force close occurs, the broadcasting party attaches a child transaction to the anchor output, paying whatever fee rate is needed at that moment.

1. The commitment transaction is broadcast with a minimal in-transaction fee
2. The broadcaster creates a child transaction spending the anchor output
3. The child transaction pays a high enough fee to incentivize miners to confirm both parent and child together
4. This shifts fee estimation from channel-open time (guessing future rates) to broadcast time (observing current rates)

The tradeoff: while the in-channel fee reserve shrinks, nodes must now maintain on-chain UTXO reserves in their Bitcoin wallet to fund the CPFP child transactions. LND, for example, requires at least one UTXO reserved per anchor channel for potential fee bumping.

Ephemeral Anchors

The next evolution is ephemeral anchors, which pair TRUC (v3) transactions with a single keyless anchor output called Pay-to-Anchor. This replaces the two 330-sat anchors with a single zero-value output that anyone can spend, further reducing the on-chain footprint and simplifying fee management. With ephemeral anchors, the commitment transaction itself can carry zero fees, placing all fee responsibility on the CPFP child.

Why It Matters

Fee reserves have practical implications for Lightning node operators, wallet users, and protocol designers:

• Small channels suffer disproportionately: a 100,000-sat channel loses a larger percentage of its capacity to fee reserves than a 10,000,000-sat channel
• Fee spikes can render channels temporarily unusable if the funder cannot cover the increased commit fee while maintaining the channel reserve
• Routing nodes must account for fee reserves when calculating available liquidity, as the advertised channel capacity may overstate what can actually be forwarded
• Layer 2 protocols like Spark avoid per-channel fee reserves entirely by using a different architecture: Spark uses statechains and cooperative signing rather than commitment transactions, eliminating the need to pre-commit funds for potential on-chain fees

Risks and Considerations

Fee-Bumping Reserve Exhaustion

With anchor outputs, the fee reserve problem shifts from inside the channel to the node's on-chain wallet. A 2025 CVE disclosure (CVE-2025-27586) described a fee-bumping reserve exhaustion attack: a malicious counterparty opens many channels with a victim node, then force-closes them simultaneously. The victim must fee-bump all closing transactions at once, potentially exhausting their on-chain UTXO reserves. The anchor specification never defined how these external reserves should be provisioned, leaving nodes vulnerable.

Stuck Channels During Fee Spikes

Pre-anchor channels that set their fee rate too low may produce commitment transactions that miners ignore during congestion. The channel effectively becomes stuck: neither party can close it on-chain because the transaction will not confirm, yet the funds remain locked. The update_fee mechanism helps but requires the funder to have sufficient balance to cover the higher rate.

Capacity Fragmentation

Fee reserves contribute to the gap between advertised and usable channel capacity. A node reporting 10 million satoshis in outbound liquidity may only be able to route significantly less after accounting for fee reserves, channel reserves, and pending HTLCs across all channels. This makes capacity planning and liquidity management more complex for routing node operators.

Privacy Implications

On-chain observers can potentially infer information about a node's fee-bumping reserves by analyzing its force-close behavior. A node that consistently uses low-fee CPFP children may signal limited on-chain reserves, while aggressive fee bumping reveals the opposite. This creates a subtle privacy leak in how nodes manage their reserves.

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.