Anchor Channel

What Is an Anchor Channel?

An anchor channel is a Lightning Network channel type where each commitment transaction includes two small outputs, called anchor outputs, that either party can spend to attach additional fees via CPFP. This decouples the fee rate of a commitment transaction from the moment it was signed, letting channel participants respond to current fee market conditions when they actually need to broadcast.

In the original Lightning channel design, commitment transactions were signed with a fixed fee rate negotiated between the two parties using an update_fee message. This created a fundamental tension: commitment transactions might be signed weeks or months before they are broadcast, but the Bitcoin fee market can change dramatically in that time. A fee rate that seemed reasonable at signing time could be far too low during a fee spike, leaving a force-close transaction unable to confirm promptly. Anchor channels were introduced to solve this problem.

The anchor channel type was formalized in BOLT PR #688 and is signaled through the option_anchors feature bit in the Lightning specification.

How It Works

Each commitment transaction in an anchor channel carries two additional outputs beyond the normal channel balance outputs and any HTLC outputs. These anchor outputs are small (330 satoshis each, matching the default P2WSH dust limit) and serve a single purpose: providing a hook for CPFP fee bumping.

Anchor Output Structure

Each anchor output is locked to the respective party's funding key. The spending script has two paths:

• Immediate spend: the owner can spend the anchor right away using their funding key signature, attaching a high-fee child transaction that pulls the commitment transaction into a block
• Anyone-can-spend after delay: after 16 blocks, anyone can sweep the anchor output, which prevents unspent anchors from permanently bloating the UTXO set

# Anchor output script (simplified)
OP_DUP OP_HASH160 <funding_pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG
OP_IFDUP OP_NOTIF
  OP_16 OP_CHECKSEQUENCEVERIFY
OP_ENDIF

CSV Delay on Non-Anchor Outputs

To make anchor-based fee bumping work correctly, all non-anchor outputs in the commitment transaction are encumbered with a one-block relative timelock (OP_CHECKSEQUENCEVERIFY). This ensures that only the anchor outputs are immediately spendable after broadcast, preventing an adversary from using other outputs to create competing child transactions that could interfere with fee bumping.

This design works together with the CPFP carve-out mempool policy. The carve-out allows a second child transaction to be accepted even when the normal descendant limit has been reached, as long as it has exactly one unconfirmed ancestor. This guarantees that both channel parties can independently fee-bump the same commitment transaction.

Fee Bumping Flow

When a channel force-closes with an anchor channel:

1. One party broadcasts their commitment transaction with a minimal fee (or the fee baked in at signing time)
2. That party (or the other party) inspects the current fee rate environment
3. They create a child transaction spending their anchor output with a fee high enough to bump the entire package to the desired confirmation target
4. Miners include both the parent (commitment) and child (anchor spend) together because the combined fee rate meets their threshold

Evolution of Channel Fee Handling

Lightning channel fee handling has gone through three major phases, each addressing shortcomings of the previous design:

Phase 1: Static Fee Channels

The original Lightning channel design required both parties to agree on a fee rate via the update_fee message. This created several problems:

• Fee prediction is inherently unreliable: no algorithm can accurately predict what fees will be needed days or weeks in the future
• Fee negotiation adds protocol complexity and a potential vector for disagreements that can trigger unnecessary force closes
• Funds reserved for fees reduce the channel's usable capacity

Phase 2: Anchor Channels (Current)

Anchor channels addressed the core problem by allowing post-broadcast fee adjustment. However, they introduced their own tradeoffs:

• Each commitment transaction adds 660 satoshis of overhead (two 330-sat anchors)
• Nodes must maintain a fee reserve: a pool of confirmed on-chain UTXOs available for CPFP spending, separate from channel funds
• Unspent anchors can temporarily bloat the UTXO set until swept after 16 blocks
• The update_fee mechanism was still present, though implementations began setting commitment fees to the minimum relay fee

Phase 3: Ephemeral Anchors and v3 Transactions

The next evolution replaces the two keyed anchors with a single ephemeral anchor on a v3 (TRUC) commitment transaction. This design, defined in a Delving Bitcoin proposal and formalized in BOLTs #1228, introduces several improvements:

• A single shared Pay-to-Anchor (P2A) output replaces both keyed anchors, which is smaller and cheaper
• The anchor can have zero value (ephemeral dust), since it must be spent in the same package as the commitment
• The update_fee message is eliminated entirely: commitment transactions carry zero fees, and all fees come from the CPFP child
• Either party (or a watchtower) can fee-bump because the anchor is keyless

For a deeper look at v3 transactions and package relay in the context of Lightning, see the research article on Lightning v3 transactions and package relay.

Use Cases

Safe Force Closes During Fee Spikes

The primary use case for anchor channels is protecting users during force closes. Without anchors, a channel that was opened during a low-fee period might produce a commitment transaction that cannot confirm during a fee spike. This can be dangerous: if the commitment transaction does not confirm before HTLC timelocks expire, the counterparty could claim funds they are not entitled to. Anchor channels let either party bump the fee to whatever the current market requires.

Watchtower Fee Bumping

With the move to ephemeral anchors, watchtowers gain new capabilities. Because the anchor output is keyless, a watchtower can attach its own fee-bumping child transaction without needing the channel party's private keys. This improves the security model for users who go offline, as their watchtower can ensure justice transactions confirm even in high-fee environments.

Mobile and Light Client Support

Mobile Lightning wallets benefit from anchor channels because they do not need to predict future fee rates at channel open time. A mobile wallet that may be offline for days can still force-close safely by fee-bumping when it comes back online, or by relying on its Lightning Service Provider (LSP) to bump fees on its behalf.

Why It Matters

Anchor channels represent a fundamental improvement in Lightning Network security. The ability to adjust fees after a commitment transaction is signed removes one of the most dangerous failure modes in the original protocol: a commitment transaction that cannot confirm in time. This matters for every Lightning user, from routing node operators managing large channels to end users relying on mobile wallets.

For Bitcoin Layer 2 solutions like Spark, anchor channel mechanics illustrate a broader design principle: separating fee responsibility from transaction construction. Spark takes a different architectural approach by avoiding on-chain commitment transactions entirely for most operations, but the same underlying challenge of adapting to dynamic fee markets applies to any protocol that interacts with the Bitcoin base layer.

For a comprehensive guide to managing Lightning channels effectively, including fee strategies and channel lifecycle, see the Lightning channel management guide and the Bitcoin fee bumping guide.

Risks and Considerations

Fee Reserve Requirement

Anchor channels require nodes to keep on-chain UTXOs available for fee bumping. These funds sit outside of Lightning channels and represent capital that cannot be used for routing or payments. Nodes must maintain a sufficient fee reserve to handle multiple simultaneous force closes during fee spikes, which can be a significant capital requirement for large routing nodes.

UTXO Set Impact

Each force close creates two anchor outputs (660 satoshis total in the current design). Typically only one anchor is spent for CPFP, leaving the other as dust in the UTXO set until the 16-block anyone-can-spend window allows cleanup. While this is a temporary effect, a large number of simultaneous force closes could create noticeable UTXO set bloat. Ephemeral anchors mitigate this by requiring the anchor to be spent in the same package as the commitment transaction.

Transaction Pinning

Despite the CPFP carve-out, anchor channels remain vulnerable to certain transaction pinning attacks. A malicious counterparty could attempt to prevent timely confirmation by creating low-fee descendants of the commitment transaction. The move to v3 transactions largely addresses this by restricting the descendant topology: v3 transactions allow only one unconfirmed child, eliminating most pinning vectors.

Complexity for Implementations

Supporting anchor channels adds significant complexity to Lightning implementations. Nodes must manage coin selection for fee-bump UTXOs, handle package relay requirements, track anchor output states, and coordinate between on-chain wallet and Lightning subsystems. This complexity is one reason the transition from legacy channels to anchor channels took several years across major implementations.

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.