Anchor Output

Anchor output is a small, immediately spendable output added to a Lightning Network commitment transaction so that either channel party can raise its effective feerate after the fact. Lightning commitment transactions are signed long before they are broadcast — often weeks or months — and the fee chosen at signing time may be far too low once the transaction actually hits the network. Because such a transaction often gates time-sensitive funds, a too-low fee that delays confirmation past a timelock can let a counterparty steal funds. Anchors exist to make sure "I signed this at yesterday's feerate" never becomes "and now I cannot get it confirmed."

How anchors enable fee bumping

Rather than pre-committing to a fee, the anchor design adds two small outputs — one per party — and encumbers all other commitment outputs with a 1 OP_CHECKSEQUENCEVERIFY (CSV) delay so they cannot be spent for at least one block. A party who needs the commitment confirmed spends its own anchor in a high-fee child transaction, dragging the parent along via Child-Pays-For-Parent (CPFP): miners evaluate the parent-plus-child package feerate, so paying generously in the child buys priority for both. This decouples the fee decision from the moment of signing — the fee is chosen at broadcast time, by whoever needs the confirmation, using the actual conditions in the mempool at that moment.

Carve-out and pinning resistance

Earlier fee-bumping via replace-by-fee proved vulnerable to transaction pinning: an adversary attaches low-feerate junk descendants to the shared transaction, saturating the descendant limits so the honest party's fee-bumping child is rejected. Anchors lean on the CPFP carve-out rule, a narrow mempool-policy exemption that guarantees each party can always attach at least one small child to its own anchor, no matter what the counterparty has stuffed onto the transaction. Full robustness depends on package relay reaching miners reliably, with higher baseline commitment feerates as an interim fallback; later "ephemeral anchor" designs (zero-value anchors that must be spent immediately) refine the pattern further and shrink the on-chain footprint.

The commitment format is negotiated per channel when it opens, and anchor-style commitments have been the default across major Lightning implementations for years — so if you opened a channel recently, this machinery is almost certainly what stands behind your force-close path, whether or not your wallet ever mentions it. Older channels created before the rollout may still use the legacy format, which is one practical argument for closing and reopening long-lived channels.

Why a node operator should care

If you run a Lightning node, anchors are why your wallet quietly insists on keeping a reserve of on-chain funds: fee-bumping an anchor requires UTXOs outside the channel, ready to fund the child transaction at whatever the market demands during a force-close. It is worth understanding this before the night you need it — a force-close during a fee spike is exactly the scenario anchors were designed for, and exactly when an empty on-chain wallet hurts. The design also carries a small ongoing cost: anchor outputs add dust-scale outputs to every commitment, a deliberate trade of a few sats of overhead for the guarantee that unilateral exit remains live under fee pressure. That guarantee is the point. Lightning's security model is "you can always leave with your money"; anchors keep that exit priced at broadcast time rather than gambled at signing time, which keeps self-custodial channels trustless in practice and not just on paper.

Anchor outputs are a direct response to weaknesses in older fee-bumping schemes. For background on how broadcast-time fees are chosen, see Fee Estimation; for the attack class they defend against, see Transaction Pinning.