Overview
Anchor outputs are a critical improvement to the Lightning Network's channel commitment transaction format that solves one of Lightning's most persistent problems: the inability to adjust transaction fees after a commitment transaction has been signed. In the original Lightning channel design, both parties had to agree on a fee rate when signing each commitment transaction. If network fee rates changed dramatically between signing and broadcast, the pre-signed fee might be too low for timely confirmation or wastefully high.
Anchor outputs solve this by adding two small outputs (one for each channel party) to every commitment transaction. These outputs are specifically designed to be spent by their respective owner using Child Pays for Parent (CPFP), allowing either party to independently increase the effective fee rate of the commitment transaction at broadcast time. This makes Lightning channels far more robust against fee rate volatility and reduces the risk of stuck channel closures.
How It Works
Traditional Commitment Transaction:
┌──────────────────────────────────────┐
│ Inputs: Funding outpoint (2-of-2) │
│ │
│ Outputs: │
│ Alice's balance 0.5 BTC │
│ Bob's balance 0.3 BTC │
│ HTLC #1 0.05 BTC │
│ Fee (pre-signed): 0.001 BTC │ ← Fixed at signing time!
└──────────────────────────────────────┘
Anchor Output Commitment Transaction:
┌──────────────────────────────────────┐
│ Inputs: Funding outpoint (2-of-2) │
│ │
│ Outputs: │
│ Alice's balance 0.5 BTC │
│ Bob's balance 0.3 BTC │
│ HTLC #1 0.05 BTC │
│ Alice's anchor 330 sats │ ← Can be spent via CPFP
│ Bob's anchor 330 sats │ ← Can be spent via CPFP
│ Fee (minimal): ~1000 sats │ ← Just enough to relay
└──────────────────────────────────────┘
Fee Bumping:
Alice broadcasts commitment TX (with minimal fee)
│
▼
Alice creates child TX spending her anchor output
with a high enough fee to pay for BOTH transactions
│
▼
Miners include both parent + child via CPFP
The Problem It Solves
Before anchor outputs, Lightning channels had to predict future on-chain fee rates when signing commitment transactions. This created several serious issues:
Overpaying fees: To ensure commitment transactions would confirm even during fee spikes, channels often set fees conservatively high. This locked up channel funds in excessive fees that could never be recovered.
Underpaying fees: If fee rates rose beyond what was pre-signed, commitment transactions could get stuck in the mempool for extended periods. In adversarial scenarios — where one party is trying to cheat by broadcasting an old state — a stuck commitment transaction could prevent the honest party from claiming their funds before the timelock expires.
Fee update storms: Both parties had to frequently negotiate fee updates through the update_fee message, creating additional protocol complexity and potential disagreements that could lead to force-closes.
Technical Details
Each anchor output is exactly 330 satoshis — the minimum non-dust output value. The commitment transaction itself is signed with a minimal fee rate, just enough to meet relay policies. The anchor outputs have a special spending condition: the owner can spend theirs immediately, while anyone else can spend it after a 16-block delay (to prevent third-party griefing).
The latest iteration of anchor outputs, sometimes called "zero-fee anchor channels" or v3 anchors, takes this concept further by setting the commitment transaction fee to zero and relying entirely on CPFP for fee determination. This approach works hand-in-hand with Bitcoin Core's package relay and v3 transaction policy improvements, which ensure that the parent-child package is evaluated as a unit for mempool acceptance.
Adoption and Significance
Anchor outputs were introduced in the Lightning specification as part of the BOLT updates and have been adopted by all major Lightning implementations including LND, CLN (Core Lightning), Eclair, and LDK. They represent one of the most significant protocol-level improvements to Lightning's reliability and are considered essential infrastructure for the network's long-term robustness.
The development of anchor outputs also highlights the deep interdependence between Bitcoin's base layer and the Lightning Network. Improvements to Bitcoin Core's mempool and relay policies (such as package relay and replace-by-fee) directly enable better anchor output functionality, demonstrating how Layer 1 and Layer 2 improvements complement each other.
Related Concepts
- Lightning Channel — the payment channel type that uses anchor outputs
- Child Pays for Parent — the fee-bumping mechanism that anchors enable
- Fee Rate — the on-chain fee metric that anchors allow adjusting post-signing
- Lightning Network — the Layer 2 protocol that benefits from anchor outputs
- HTLC — hash time-locked contracts in commitment transactions alongside anchors
- Replace-by-Fee — an alternative fee-bumping approach used on-chain