Dynamic Commitments: Upgrading Lightning Channels Without Closing Them

The Lightning Network faces an upgrade dilemma: every time the protocol introduces a better commitment transaction format, node operators must close existing channels and open new ones to adopt it. This close-and-reopen cycle costs two on-chain transactions per channel, temporarily locks liquidity, and fragments routing capacity across the network. Dynamic commitments offer a way out: a protocol extension that lets two channel peers renegotiate their commitment format in-place, without broadcasting anything to the blockchain.

First proposed by Olaoluwa Osuntokun in July 2020, dynamic commitments address a structural limitation of channel-based Layer 2 protocols: how to evolve the internal machinery of a channel without disrupting the on-chain anchor that funds it. The proposal is now tracked as BOLTs PR #1117 and remains under active review as of late 2026.

The Close-and-Reopen Problem

Lightning channels are anchored to the blockchain through a funding output: a 2-of-2 multisig UTXO that both peers cooperatively created when the channel opened. Every subsequent payment updates the commitment transaction off-chain, but the funding output itself sits on-chain, immutable, until one side closes the channel.

When the network introduces a new channel type (such as the move from legacy channels to anchor channels, or from anchor channels to simple taproot channels), the only way to adopt it has been to cooperatively close the old channel and open a fresh one with the new format. This creates three problems:

• Each close-and-reopen cycle requires two on-chain transactions: one to return the channel balance to each party, and one to lock funds into the new channel
• During the transition window, the channel's capacity is unavailable for routing, reducing network liquidity
• At scale, mass upgrades compete for block space and drive up fees for everyone

The Cost of Upgrading One Channel

A cooperative close transaction is approximately 170 virtual bytes (vB). A standard funding transaction with a single P2WPKH input runs about 141 vB. The combined close-and-reopen cycle therefore costs roughly 311 vB. At a moderate fee rate of 10 sat/vB, that is about 3,110 sats per channel. At 50 sat/vB during congestion, it climbs to 15,550 sats.

In his 2022 mailing list post, Osuntokun noted that dynamic commitments could upgrade all 80,000+ public Lightning channels to taproot without any on-chain transactions. At 10 sat/vB, the alternative (closing and reopening every channel) would consume over 160,000 on-chain transactions and cost roughly 250 million sats in aggregate fees.

Network-wide impact: A mass close-and-reopen event would not only cost individual node operators but would also spike on-chain fee rates for all Bitcoin users. Dynamic commitments sidestep this entirely by keeping the upgrade purely off-chain.

How Dynamic Commitments Work

The core insight behind dynamic commitments is that the funding output is the only component of a channel that is fixed on-chain. Everything else: the commitment transaction format, the HTLC structure, the fee strategy, and the channel parameters like dust limits and reserve amounts, exists purely in the off-chain state machine between two peers.

If both peers agree on a new set of rules, they can switch their commitment format without touching the funding output, provided the new channel type uses a compatible funding script. The protocol proceeds in three phases:

Phase 1: Quiescence

Before any upgrade can begin, the channel must enter a quiescent state where no HTLCs are in flight and no updates are pending. This is handled by the quiescence protocol (BOLTs PR #869), which introduces a stfu (“SomeThing Fundamental is Underway”) message. When one peer sends stfu, both sides stop proposing new updates and wait for all in-flight HTLCs to resolve. The channel enters a frozen state where the only permitted action is the upgrade negotiation itself.

Quiescence uses feature bits 34/35 (option_quiesce) and is a prerequisite not just for dynamic commitments but also for splicing. LND merged its quiescence implementation in late 2024 and enabled it in production in subsequent releases.

Phase 2: Negotiation

Once quiescent, the initiating peer proposes a new channel type. The proposal includes the target commitment format, updated channel parameters (reserve amounts, dust limits, max accepted HTLCs), and any feature bits required by the new type. The responding peer either accepts or rejects. If rejected, the channel resumes normal operation under the existing format.

Phase 3: Commitment Switch

Upon agreement, both peers construct and exchange new commitment transactions under the upgraded format. The old commitment transactions are revoked using the standard revocation key mechanism. The channel then resumes normal operation with the new commitment type, and the quiescent lock is released.

No on-chain footprint: When the old and new channel types share the same funding output script (for example, both use P2WSH 2-of-2 multisig), the entire upgrade happens off-chain. The blockchain never sees the change. This is the case for parameter-only upgrades, such as moving from static-remote-key channels to anchor channels.

The Funding Output Problem

Not all upgrades are purely off-chain. The move from anchor channels (which use a P2WSH funding output) to simple taproot channels (which use a P2TR funding output built on MuSig2) requires changing the funding output itself. Since the funding output is on-chain, this change cannot be done without an on-chain transaction.

Two approaches have been proposed to handle this:

Adaptor Commitments

First described in a March 2022 lightning-dev thread, the adaptor commitment approach inserts a “kickoff” transaction between the old funding output and the new commitment transactions. This transaction spends the v0 (SegWit) multisig output and creates a new v1 (Taproot) multisig output. Both peers pre-sign the kickoff transaction, then switch to building commitments against the new output.

The key trade-off: the kickoff transaction is not broadcast immediately. It defers the on-chain cost until the channel eventually closes. At that point, the close requires two on-chain transactions (the kickoff plus the final commitment) rather than one. As Antoine Riard noted in the discussion, this introduces fee uncertainty: you defer the upgrade cost but lose predictability about what fees will look like when the channel eventually closes.

Splice-Based Upgrades

The alternative approach, pioneered by ACINQ's Eclair implementation, upgrades the funding output during a splice transaction. When a node is already performing a splice-in or splice-out (adding or removing on-chain funds), the splice transaction can simultaneously change the funding output script from P2WSH to P2TR. Since the splice already requires an on-chain transaction, the upgrade comes at zero marginal cost.

Eclair v0.14.0 supports upgrading the commitment format to taproot during a splice, making it the first implementation to offer a production-ready funding output upgrade path. ACINQ reported approximately 15% reduction in overall transaction weight for channels using the new taproot format.

Upgrade Paths: From Legacy to PTLCs

The Lightning protocol has gone through several commitment format generations. Dynamic commitments define a migration path across all of them, each step unlocking new capabilities:

Steps 1, 2, and 4 can be performed entirely off-chain through the dynamic commitments protocol because the funding output script does not change. Step 3 requires either an adaptor commitment or a splice-based upgrade because the funding output moves from SegWit v0 to SegWit v1 (Taproot).

The ultimate goal is PTLC channels, which replace hash time-locked contracts with point time-locked contracts. PTLCs use adaptor signatures instead of hash preimages, so each hop along a payment route uses a different cryptographic proof. This eliminates the correlation attack where an observer identifies a single payment by spotting the same hash at multiple hops.

Implementation Status

Dynamic commitments remain an in-progress specification as of November 2026. The three major Lightning implementations have taken different approaches to the upgrade problem:

LND has laid the groundwork: quiescence support is merged, internal refactors to support multiple commitment formats are in progress (issue #7878), and the specification work tracks against BOLTs PR #1117. However, the full dynamic commitments negotiation state machine has not shipped in a release.

Eclair has taken a pragmatic shortcut: rather than waiting for the full dynamic commitments specification, it upgrades the funding output during splice transactions. This works well for the Phoenix wallet, which performs splices frequently, but does not help channels that never splice.

Core Lightning's development focus has been on BOLT12 offers, splicing, and Greenlight infrastructure. Simple taproot channels have not yet reached production in CLN, though experimental support for channel upgrades was added as early as 2021.

Security Considerations

Changing the commitment format mid-flight introduces several security concerns that the protocol must address:

Revocation Continuity

When the commitment format changes, all prior commitments under the old format must remain revocable. If a peer broadcasts a stale commitment from before the upgrade, the counterparty must still be able to claim the justice transaction penalty. The dynamic commitments protocol maintains revocation continuity by keeping the old revocation keys valid even after the format switch.

Quiescence Window Attacks

The quiescent state introduces a temporary denial-of-service vector. A malicious peer could send stfu repeatedly to freeze the channel, preventing legitimate payments from flowing. The protocol mitigates this through timeouts: if the upgrade negotiation does not complete within a specified window, the channel automatically exits the quiescent state and resumes normal operation.

Adaptor Commitment Chain Risk

The adaptor commitment approach adds an extra transaction to the unilateral close path. If a channel is force-closed after an upgrade, the closing party must broadcast the kickoff transaction first, then the commitment. This increases the total fee cost of a unilateral close and introduces a timing dependency: the commitment cannot confirm until the kickoff confirms. During periods of high mempool congestion, this additional confirmation step could delay fund recovery.

Partial Network Upgrades

Dynamic commitments are negotiated bilaterally. If your peer does not support the new format, you cannot upgrade that channel. This means the network will inevitably run mixed channel types for an extended period. Routing nodes must handle heterogeneous channel types, and gossip protocol messages must accurately reflect each channel's capabilities.

Dynamic Commitments vs Close-and-Reopen: Cost Comparison

The following comparison assumes a single channel with one input and standard transaction sizes. Real-world costs vary with UTXO composition and fee market conditions.

For parameter-only upgrades (steps 1, 2, and 4 in the upgrade path), dynamic commitments are strictly superior: zero cost, zero downtime, zero block space. For the P2WSH-to-P2TR migration (step 3), the adaptor commitment defers costs while Eclair's splice-based approach piggybacks on an existing on-chain operation.

Why Channel-Based Upgrades Are Inherently Friction-Heavy

Dynamic commitments represent an engineering solution to a problem that is inherent to payment channel architectures. Every channel is a bilateral contract between two specific peers, locked to a specific on-chain output, with a specific commitment format baked in at creation time. Upgrading requires both peers to coordinate, agree, and switch simultaneously.

This is why channel-based networks face upgrade friction that channel-free architectures do not. Consider Spark, which uses statechains instead of payment channels. In Spark's model, there are no bilateral channel contracts to renegotiate. Protocol upgrades can be rolled out at the operator level without requiring every user to coordinate a channel migration. There is no funding output to change, no commitment format to switch, and no liquidity downtime during the transition.

This architectural difference extends beyond upgrades. Lightning nodes must manage channel liquidity, handle backup and recovery for each channel's state, and deal with force closes when peers become unresponsive. Each of these operational concerns is a direct consequence of the channel model. Dynamic commitments reduce one category of friction (upgrades) but do not eliminate the underlying complexity.

For developers building Bitcoin applications, the choice between channel-based and channel-free Layer 2s should factor in long-term maintenance costs. The Spark SDK documentation provides integration guides for wallet and payment infrastructure that avoids channel management entirely. For a deeper comparison of the two approaches, see our Lightning taproot channel upgrade analysis.

What Comes Next

The dynamic commitments specification (BOLTs PR #1117) continues to be refined in Lightning specification meetings. Several milestones remain before network-wide deployment:

1. Finalization and merge of the BOLTs specification, which has been under review since its introduction
2. Implementation in at least two major Lightning codebases (LND and either CLN or LDK) for interoperability testing
3. Resolution of the funding output upgrade path: whether the network standardizes on adaptor commitments, splice-based upgrades, or both
4. Gossip protocol updates to support announcing upgraded channel types without requiring new channel announcements

Once dynamic commitments ship, the path to PTLCs becomes significantly shorter. Every existing taproot channel could upgrade to PTLC-based routing without an on-chain transaction, bringing meaningful privacy improvements to the entire Lightning Network.

The broader lesson is that protocol evolution in channel-based systems requires careful engineering of the upgrade path itself. Dynamic commitments solve the immediate problem of commitment format migration, but the underlying challenge of coordinating bilateral state machines remains a defining characteristic of the channel model.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.