Ephemeral Anchor

What Is an Ephemeral Anchor?

An ephemeral anchor is a special transaction output designed to be created and consumed atomically within the same transaction package. It uses the Pay-to-Anchor (P2A) script type defined in BIP 433: a 4-byte witness v1 output (OP_1 <0x4e73>) that anyone can spend without providing a signature. The output can carry zero value, and it exists solely to give any party a hook for attaching a CPFP fee-bumping child transaction.

The concept was proposed by Gregory Sanders (instagibbs) in October 2022 to solve a persistent problem in multi-party Bitcoin protocols: how do you let multiple participants independently fee-bump a shared transaction without introducing transaction pinning vulnerabilities? The answer combines three pieces: TRUC transaction topology rules (BIP 431), the P2A output type (BIP 433), and the ephemeral dust relay policy introduced in Bitcoin Core 29.0.

How It Works

Ephemeral anchors are built from three interlocking mechanisms that work together to enable trustless, keyless fee bumping.

TRUC Transactions (BIP 431)

A TRUC transaction sets nVersion=3, opting into strict topology rules enforced by the mempool:

• Maximum one unconfirmed parent and one unconfirmed child (1-parent-1-child topology)
• Parent limited to 10,000 vbytes, child limited to 1,000 vbytes
• Inherently signals replaceability (no BIP 125 flag needed)
• The parent can pay zero fees if submitted as a package with a fee-paying child

The 1-parent-1-child rule is critical: it prevents an adversary from attaching junk descendants that block the honest party from adding their own CPFP child, which is the core of package-limit pinning attacks.

Pay-to-Anchor Output (BIP 433)

The P2A output type uses the script OP_1 <0x4e73>, a witness v1 program with a 2-byte data push. Spending it requires no signature or witness data at all: the witness is empty. On mainnet, this output encodes to the bech32m address bc1pfeessrawgf.

# P2A output script (4 bytes total)
scriptPubKey: OP_1 OP_PUSHBYTES_2 4e73

# Spending input (empty witness)
witness: []

# Cost breakdown
# Creating the output: ~13 vbytes
# Spending the output: ~41 vbytes

Because anyone can spend a P2A output, any participant in a shared protocol (or even an unrelated third party) can create the fee-bumping child transaction. No private keys from the original signers are required.

Ephemeral Dust Policy

Normally, Bitcoin nodes reject transactions with outputs below the dust threshold to prevent UTXO set bloat. The ephemeral dust policy, shipped in Bitcoin Core 29.0, creates a targeted exemption:

1. The transaction must pay zero fees
2. It may contain exactly one output below the dust threshold (even zero-value)
3. Any child spending unconfirmed outputs from this transaction must also spend the dust output
4. Only one child is permitted (enforced by TRUC topology rules)

These rules guarantee that the dust output is ephemeral: it is created and destroyed in the same package and never persists in the UTXO set. The zero-fee requirement makes it economically irrational for a miner to confirm the parent alone, since doing so would earn no fees while adding a dust output to the UTXO set.

Putting It Together

The complete flow for a transaction using an ephemeral anchor:

1. Construct a TRUC (nVersion=3) transaction with zero fees. Include a P2A output (optionally zero-value) as the ephemeral anchor.
2. When the transaction needs to be broadcast, any party creates a small child transaction that spends the P2A output and pays the appropriate fee for current network conditions.
3. Both transactions are submitted as a package. Nodes evaluate the combined feerate and accept the package if it meets mempool requirements.
4. Miners include both transactions together. The P2A output is created and consumed in the same block, leaving no trace in the UTXO set.

Why It Matters for Lightning

The Lightning Network is the primary beneficiary of ephemeral anchors. Current anchor outputs on commitment transactions have several problems that ephemeral anchors resolve.

The Problem with Current Anchors

Today, each commitment transaction includes two 330-satoshi anchor outputs, one controlled by each channel party. This design has significant drawbacks:

• The update_fee message forces both parties to agree on a feerate at signing time, potentially hours or days before broadcast. Disagreements during fee spikes cause unnecessary force-closes.
• Each anchor requires a specific party's signature, so watchtowers need additional key material to fee-bump on a user's behalf.
• The two 330-satoshi outputs often remain unspent, permanently bloating the UTXO set.
• Maximum sendable amounts depend on the current feerate estimate, reducing the usable channel capacity.

The Ephemeral Anchor Solution

With ephemeral anchors, the commitment transaction becomes a zero-fee TRUC transaction with a single P2A output. The improvements are substantial:

• The update_fee message is eliminated entirely. Fees are set at broadcast time, not signing time, so parties never disagree about feerates.
• Any party can fee-bump without special keys. Watchtowers only need a funded wallet and the raw transaction, not channel-specific key material.
• A single anchor replaces two, and its zero value means no satoshis are wasted on outputs that exist only to enable fee bumping.
• Channel capacity becomes fully deterministic: the maximum amount you can send or receive no longer fluctuates with feerate estimates.

Implementation Status

Ephemeral anchors required changes at both the Bitcoin base layer and the Lightning protocol level. The rollout has been incremental:

Bitcoin Core

With Bitcoin Core 29.0, all three components (TRUC, P2A, ephemeral dust) are available on mainnet as standard relay policy.

Lightning Protocol

The Lightning specification for zero-fee commitment transactions using ephemeral anchors was defined in BOLTs #1228, authored by Bastien Teinturier (t-bast). This specification was merged in May 2026 and introduces a new channel type (feature bits 40/41) that uses TRUC commitment transactions with a single P2A ephemeral anchor.

On the implementation side, LDK shipped support for zero-fee-commitment channels in version 0.2 (December 2025), and Eclair began integrating support in early 2026. Core Lightning has experimental support in development.

Use Cases

Lightning Channel Management

The primary use case is fee bumping Lightning commitment transactions during a force-close. When a channel closes uncooperatively, the party broadcasting the commitment transaction needs to get it confirmed promptly. With ephemeral anchors, they set the fee at broadcast time by attaching a CPFP child to the P2A output, rather than relying on a feerate negotiated days or weeks earlier.

Watchtower Fee Bumping

Watchtowers monitor channels and broadcast justice transactions when fraud is detected. Under the current anchor design, watchtowers need channel-specific keys to spend a party's anchor. With ephemeral anchors, a watchtower only needs the pre-signed commitment transaction and a funded wallet to create the CPFP child, simplifying watchtower architecture.

Multi-Party Protocols

Any protocol where multiple parties share a pre-signed transaction benefits from ephemeral anchors. This includes channel factories, CoinJoin transactions, and Ark round transactions. The anyone-can-spend property means participants do not need to coordinate fee decisions at signing time.

Layer 2 Protocols

Bitcoin layer 2 protocols like Spark benefit from a more efficient on-chain fee market. When force-close transactions are cheaper and more reliable, the trust assumptions for off-chain protocols improve: users can be more confident that their on-chain fallback will confirm in a timely manner, regardless of fee market conditions.

Risks and Considerations

Policy vs. Consensus

The ephemeral dust exemption is a relay policy rule, not a consensus rule. This means miners are technically free to confirm a zero-fee parent transaction without including the child that spends the P2A output. However, the zero-fee requirement makes this economically irrational: a miner would earn nothing while adding a dust output to the UTXO set.

MEV Concerns

If an ephemeral anchor carries a non-zero value (for example, from trimmed HTLC amounts), a counterparty or third party could claim those funds by spending the P2A output. The Lightning specification addresses this by capping the ephemeral anchor value at 240 satoshis (the P2A dust threshold). In practice, trimmed HTLC values already go to miners under the current protocol, so this does not introduce a new loss vector.

Adoption Timeline

Ephemeral anchors require upgraded Bitcoin Core nodes (29.0+) for relay and upgraded Lightning implementations for channel support. Until a critical mass of nodes supports TRUC and package relay, transactions using ephemeral anchors may face propagation challenges. The new channel type also requires both peers to support feature bits 40/41, so adoption will be gradual as implementations roll out support.

Child Transaction Cost

The fee-bumping child must spend the P2A output (approximately 41 vbytes) and include its own inputs and change output. In practice, the party broadcasting the commitment transaction needs a confirmed UTXO available to fund the child. This is similar to the current anchor output requirement but remains an operational consideration for mobile wallets and lightweight nodes.

Comparison: Current Anchors vs. Ephemeral Anchors

For a deeper look at how v3 transactions and package relay work together to enable ephemeral anchors, see the research article on Lightning v3 transactions and package relay. You can also read more about fee bumping techniques including RBF and CPFP.

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.