Anchor output
An anchor output is a small transaction output left on a presigned transaction so a later child-pays-for-parent spend can attach fees at broadcast time. On the Lightning Network, BOLT 3 option_anchors uses two keyed P2WSH anchors (typically 330 satoshis each). That design is distinct from Pay-to-anchor (P2A), which is a keyless native segwit output template (BIP 433), and from an ephemeral anchor, which is a usage pattern that creates and spends a P2A output in the same unconfirmed TRUC package so it never persists in the UTXO set.
option_anchors
A Lightning commitment is signed long before either party broadcasts it. If the commitment pays too low a feerate it may not confirm in time; if it pays too high, the parties overpay. Signing many feerate variants is unwieldy. Leaving the commitment underpaying and attaching a child that spends an output of the commitment lets fees be chosen later. Ordinary mempool descendant limits can still be exhausted by a counterparty who attaches many descendants, blocking child-pays-for-parent. Bitcoin Core's CPFP carve-out granted one extra descendant under conditions Lightning met by giving each party its own small keyed anchor.
Under option_anchors, each commitment includes to_local_anchor and to_remote_anchor. Each is a P2WSH whose witness script requires that party's funding key, or after 16 blocks any spend (OP_16 CHECKSEQUENCEVERIFY). The owner can spend immediately to fee-bump; after 16 blocks anyone can sweep an abandoned anchor. Two keyed anchors exist so one party cannot occupy the only fee-bumping output. The commitment itself still usually pays a modest fee so it is not entirely dependent on the child.
When a commitment is broadcast, the owning party builds a child that spends its keyed anchor into fees and any change. The child must satisfy ordinary standardness and, on older Core versions, fit under descendant limits with the carve-out exception. After cluster mempool removed carve-out, a second child competing for the same parent can fail relay even when both parties act honestly. That is a primary reason newer designs prefer a single shared Pay-to-anchor output inside a TRUC package.
BOLT 3 also defines trimmed HTLC outputs that fall below the dust threshold when fees rise. Anchors do not replace those trim rules. They only provide a place to attach fees after the fact. Peers negotiate option_anchors (and related bits such as option_scid_alias in other contexts) during channel establishment. A channel without the feature falls back to committing an explicit fee at signing time.
Migration
Keyed anchors add weight on every commitment, require a UTXO to fund the child, can litter the UTXO set if unswept, and depend on CPFP carve-out (not granted to TRUC transactions and removed with cluster mempool in Bitcoin Core 31.0). Protocols that need a guaranteed fee-bump path on that stack are expected to migrate toward TRUC packages and a single shared P2A / ephemeral-anchor style output. Some deployments still use keyed anchors when peers do not relay TRUC packages or when only a designated key should attach fees.
Channels that still negotiate only keyed anchors remain interoperable with older peers. Dual support during upgrade means a node may fee-bump with carve-out logic toward one peer and with TRUC and Pay-to-anchor toward another.