Cooperative Close

What Is a Cooperative Close?

A cooperative close (also called a "mutual close") is the process of shutting down a Lightning Network payment channel with the agreement of both participants. Instead of either party unilaterally broadcasting a pre-signed commitment transaction, both nodes negotiate a final closing transaction that pays each side their correct balance directly to their chosen Bitcoin address.

The closing transaction is simple: it spends the channel's 2-of-2 multisig funding output and creates one or two outputs paying each party's final balance. Because both parties sign this transaction cooperatively, there is no need for timelocks, revocation paths, or penalty mechanisms. The funds become spendable as soon as the transaction confirms on-chain.

Cooperative closes are the default and preferred channel closure method in every major Lightning implementation, including LND, Core Lightning, and Eclair. When both peers are online and responsive, the process typically completes within seconds of initiation, though the on-chain transaction still requires the usual block confirmations.

How It Works

The cooperative close protocol is defined in BOLT #2 (peer protocol) and BOLT #3 (transaction formats). The process has two phases: shutdown initiation and fee negotiation.

Phase 1: Shutdown

Either node can initiate closing by sending a shutdown message:

1. The initiating node sends a shutdown message containing its preferred Bitcoin address (scriptpubkey) for receiving its share of the channel balance
2. The receiving node responds with its own shutdown message and payout address
3. Both nodes stop accepting new HTLCs on the channel
4. All pending HTLCs must be fully resolved (settled or failed) before closing can proceed

If either node committed to an "upfront shutdown script" when the channel was opened, it must use that exact address. This feature prevents an attacker who compromises a node from redirecting closing funds to a different wallet.

Phase 2: Fee Negotiation

Once both shutdown messages are exchanged and all HTLCs are resolved, the nodes negotiate the on-chain fee rate for the closing transaction.

In the legacy protocol, this works through iterative negotiation:

1. The channel funder sends a closing_signed message proposing a fee amount, along with their signature for the closing transaction at that fee
2. The other node either accepts the fee (by echoing the same amount with their own signature) or proposes a counter-fee
3. Each subsequent proposal must be strictly between the node's previous proposal and the most recently received proposal, which mathematically guarantees convergence
4. When both sides agree on the same fee, both construct and sign the final closing transaction

An optional fee_range extension allows nodes to communicate acceptable fee boundaries upfront, speeding convergence when ranges overlap.

The Closing Transaction

The resulting closing transaction is structurally simple compared to a commitment transaction:

// Cooperative close transaction structure
Input:
  funding_txid:funding_output_index  // 2-of-2 multisig
  witness: 0 <sig_A> <sig_B>

Outputs (1 or 2):
  output_0: <party_A_balance - fee_share> -> <party_A_scriptpubkey>
  output_1: <party_B_balance>             -> <party_B_scriptpubkey>

// No timelocks, no revocation paths, no HTLC outputs
// Locktime: 0
// Sequence: 0xFFFFFFFD

If either party's balance falls below the dust limit for their output type, that output is omitted entirely and the dust amount is absorbed into the fee.

The Simplified Close Protocol

In February 2025, the Lightning specification merged option_simple_close (features 60/61), replacing the iterative fee negotiation with a cleaner request/response pattern. The closer sends a closing_complete message and pays the fee from their own balance. The responder replies with a closing_sig message containing their signature. This new protocol also adds RBF support for cooperative closes and is designed for Taproot/MuSig2 compatibility.

Cooperative Close vs. Force Close

Understanding the difference between a cooperative close and a force close is essential for anyone operating Lightning channels. The two methods differ in cost, speed, complexity, and risk.

Force closes use the latest commitment transaction, which includes timelocked outputs, potential anchor outputs, and any unresolved HTLC outputs. The initiator's funds are locked behind a to_local output with a CSV (CheckSequenceVerify) delay, typically ranging from one day to two weeks. During this window, the counterparty can broadcast a penalty transaction if the commitment was outdated, claiming all channel funds.

None of this complexity exists in a cooperative close. The transaction is as simple as any standard Bitcoin payment.

Why It Matters

Cooperative closes are not just a convenience: they have practical implications for cost, privacy, and network health.

• Lower fees: the closing transaction is smaller and the fee is negotiated at the current market rate rather than pre-committed at channel open time
• Faster fund access: outputs are immediately spendable after confirmation, with no timelock delays
• Cleaner UTXOs: the resulting outputs are standard pay-to-address outputs, not complex scripts, making them cheaper to spend later
• Better privacy: cooperative close transactions look like ordinary multisig spends on-chain, making it harder for chain analysis to identify them as Lightning channel closures
• No penalty risk: since both parties agree on the final state, there is no risk of accidentally broadcasting an outdated commitment and losing funds

For node operators managing many channels, the cost difference adds up. A channel management strategy that prioritizes cooperative closes can significantly reduce on-chain fee expenditure over time.

When Cooperative Close Fails

A cooperative close requires both peers to be online, reachable, and willing to cooperate. Several scenarios force a fallback to unilateral closure:

• Unresponsive peer: the counterparty is offline, has crashed, or has lost its network connection. Without their signature, no cooperative closing transaction can be constructed.
• Malicious peer: the counterparty refuses to send a shutdown message or proposes unreasonable fees that prevent convergence. If fee ranges do not overlap, the spec requires failing the channel.
• HTLC timeout pressure: if a pending HTLC is about to expire and the counterparty stops responding, the node must force-close to enforce the HTLC on-chain before the timelock expires
• Extended disconnection: if peers disconnect during closing negotiation, they can resume on reconnection. But if the peer never reconnects, force close is the only option.

In all these cases, the node falls back to broadcasting its latest commitment transaction: a force close. This is why Lightning nodes maintain up-to-date commitment transactions at all times and why watchtowers exist to monitor for outdated commitments.

Use Cases

Routine Channel Management

The most common use case is simply closing a channel that is no longer needed. A routing node operator might close channels with low volume or poor connectivity. A merchant might close a channel after a seasonal demand spike. Splicing has reduced the need for full closures when the goal is simply resizing a channel, but cooperative closes remain the standard when a channel needs to be fully wound down.

Rebalancing On-Chain Funds

Node operators sometimes need to move funds from Lightning back to on-chain Bitcoin for cold storage, payments, or opening channels with different peers. A cooperative close returns funds to a standard Bitcoin UTXO at minimal cost, making it preferable to Loop Out or submarine swaps when the channel itself is no longer needed.

Upgrading Channel Parameters

Before splicing was widely available, the only way to change channel parameters (like switching from legacy to Taproot channels or adjusting channel reserves) was to cooperatively close the old channel and open a new one with updated settings.

Risks and Considerations

Peer Availability

The fundamental risk of relying on cooperative closes is that they require peer cooperation. If a peer goes permanently offline (hardware failure, abandoned node), a cooperative close is impossible. Node operators should always be prepared for force close scenarios and maintain sufficient on-chain funds to cover the higher fees associated with commitment transactions.

Fee Negotiation Failures

During periods of high mempool congestion, peers may disagree on appropriate fees. If one party wants a very low fee to save costs and the other wants a high fee for fast confirmation, the iterative negotiation process may fail, resulting in a force close. The newer option_simple_close protocol mitigates this by letting the closer set the fee unilaterally (since it comes from their balance) and supporting RBF if the initial fee is too low.

Timing Considerations

If an HTLC is in flight and approaching its expiry, initiating a cooperative close may not be safe. The shutdown protocol requires all HTLCs to resolve first, and if resolution is blocked, the node may need to force-close to protect against HTLC timeout. Operators should avoid initiating cooperative closes while the channel has pending HTLCs near expiration.

Privacy Trade-offs

While cooperative close transactions are less identifiable than force closes on-chain, they still reveal the final balance split between the two parties. A channel that opened with 1 BTC and closes with outputs of 0.3 and 0.7 BTC reveals the net payment flow over the channel's lifetime. For privacy-sensitive applications, consider the on-chain footprint of any channel closure.

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.