Lightning Anchor Commitment

Anchor commitments are a Lightning channel design pattern that solves a critical fee-rate problem in older channel designs.

The problem is that a Lightning channel's commitment transaction (the on-chain transaction that closes the channel and distributes funds) is pre-signed. Both sides sign a fresh one every time the channel balance changes, long before anyone knows whether it will be broadcast, and that signature locks in a fee.

If you sign with a 10 sat/vB fee in a low-congestion period and then need to broadcast it during a high-fee storm at 200 sat/vB, the transaction is uneconomical to mine and may sit in the mempool for a long time, get evicted, or never be accepted at all. If payments are in flight, a stuck commitment can also miss their timelock deadlines, which can cost real money.

Pre-anchor designs handled this poorly. Channels could be effectively "stuck" if fees spiked, with no clean way to bump the commitment's fee post-signing.

Anchor outputs solve it. The commitment transaction is still signed in advance, with a modest fee that only needs to get it accepted into mempools, but it includes two small "anchor" outputs of 330 satoshis each, one per channel party. When either party broadcasts the commitment, they can use CPFP (Child-Pays-for-Parent) on their anchor output to attach an additional fee child transaction. The anchor child pays the real fee; the original commitment gets pulled along.

The benefits:

• Channels stay closable when fees spike. That holds as long as the node has some on-chain bitcoin to pay for the child transaction, which is why nodes with anchor channels keep a small on-chain reserve.
• Less pre-signed fee waste. Commitments can be signed with minimal fees, then bumped only when actually broadcast.
• Better resilience. Force-closes during fee storms are far more reliable, though not immune to every attack. One known weakness is transaction pinning, where an attacker uses mempool rules to stop a transaction from being accepted or fee-bumped in time.

Anchor outputs entered the BOLT spec in 2020. In 2021 the spec added a revised version, option_anchors, which also signs the channel's HTLC transactions with zero fee. That revised version is the one implementations adopted. LND made anchor channels its default in June 2021 (version 0.13), eclair followed in 2022 and Core Lightning in 2024. A new channel uses anchors whenever both peers support them. Eclair version 0.14.0, released in May 2026, dropped support for non-anchor channels altogether.

Also in May 2026, the spec added a successor called zero-fee commitments. The two per-party anchors give way to a single shared anchor that anyone can spend, a standard output type called pay-to-anchor (P2A). The commitment is also built as a version 3 transaction, which opts it into stricter relay rules called TRUC (Topologically Restricted Until Confirmation) that are designed to make pinning harder. The commitment itself usually pays no fee, and the child transaction carries all of it.

Zero-fee commitments depend on relay rules added in Bitcoin Core 28.0 and 29.0. As of October 2026 eclair offers them only as an opt-in feature.