Channel Close Types

What Are Channel Close Types?

Channel close types describe the three distinct ways a Lightning Network payment channel can be settled on-chain. Every Lightning channel begins with a funding transaction that locks bitcoin into a 2-of-2 multisig output. When the channel eventually closes, that locked bitcoin must be distributed back to the two parties. How that distribution happens depends on the circumstances: whether both parties are online and cooperating, whether one party is unresponsive, or whether one party is attempting to cheat.

The three close types are cooperative close, force close, and breach close. Each produces a different on-chain transaction pattern with different fee costs, confirmation times, and fund availability. The channel's commitment transaction plays a central role in all three scenarios, as it encodes the agreed-upon balance distribution at each state update.

How Each Close Type Works

Cooperative Close

A cooperative close is the simplest and most efficient way to close a Lightning channel. Both parties are online, agree on the final balance distribution, and jointly sign a single closing transaction. This transaction spends the 2-of-2 multisig funding output and creates one or two outputs paying each party their final balance.

The process follows these steps:

1. One party sends a shutdown message indicating they want to close the channel
2. Both parties stop accepting new HTLCs and wait for pending HTLCs to resolve
3. They negotiate the closing fee (or use the newer simple close protocol)
4. Both sign the closing transaction
5. The transaction is broadcast and confirmed on-chain

Because the closing transaction is a simple spend from a multisig output, it is compact: roughly 170 virtual bytes. At a fee rate of 5 sat/vB, that costs around 850 sats. There is no timelock delay, so both parties can spend their funds as soon as the transaction confirms.

Force Close

A force close occurs when one party broadcasts their latest commitment transaction without the other party's cooperation. This is the fallback mechanism when a channel partner goes offline, becomes unresponsive, or refuses to cooperate on a mutual close.

The process works as follows:

1. The broadcasting party publishes their most recent commitment transaction to the blockchain
2. The remote party's balance is paid out immediately to their address with no restrictions
3. The broadcaster's own balance is locked behind a CSV (CheckSequenceVerify) timelock, typically ranging from 144 to 2,016 blocks (roughly one day to two weeks)
4. Any pending HTLCs are resolved on-chain through additional transactions
5. After the timelock expires, the broadcaster can sweep their funds

Force closes are more expensive than cooperative closes for several reasons. The commitment transaction is larger because it includes timelock scripts and potentially multiple HTLC outputs. Each pending HTLC requires a separate on-chain transaction to resolve. The broadcaster also cannot choose an optimal fee rate in advance: the commitment transaction uses a pre-signed fee (though anchor outputs allow fee bumping via CPFP).

The timelock delay on the broadcaster's funds is not a punishment: it is a security mechanism. This window gives the counterparty time to check whether the broadcast state was the most recent one. If it was not, the counterparty can publish a justice transaction and claim all the funds.

Breach Close

A breach close happens when a channel partner broadcasts an old, revoked commitment transaction in an attempt to steal funds. For example, if Alice once owed Bob 500,000 sats but later paid him so that she now owes 200,000 sats, Alice might try to broadcast the old state where she still had the larger balance. This is the scenario the Lightning penalty mechanism is designed to prevent.

When a breach is detected, the resolution follows these steps:

1. The cheating party broadcasts a revoked commitment transaction
2. The honest party (or their watchtower) detects the revoked state on-chain
3. Using the revocation key obtained during a prior state update, the honest party constructs a penalty transaction
4. The penalty transaction sweeps the entire channel balance to the honest party
5. The cheating party loses all their funds in the channel

The revocation key is what makes this possible. Each time the channel state updates, both parties exchange revocation secrets for the previous state. These secrets, combined with the counterparty's own key material, allow constructing a revocation key that can spend all outputs from the revoked commitment transaction. The honest party must broadcast the penalty transaction before the cheater's timelock expires: this is why force-closed funds have a delay.

Comparing Channel Close Types

The three close types differ significantly in cost, speed, and outcome:

When Each Type Occurs

Cooperative Close Scenarios

Most channel closes should be cooperative. Common triggers include rebalancing channel capacity, reallocating funds to a different peer, closing unprofitable routing channels, or simply withdrawing funds on-chain. As long as both nodes are online and their software is functioning, the cooperative path is available.

Force Close Scenarios

Force closes happen when cooperation is impossible. Typical causes include a peer going permanently offline (hardware failure, node shutdown), a peer becoming unresponsive due to software bugs, a dispute over the channel state, or the need to resolve pending HTLCs that cannot settle off-chain. Force closes are undesirable but sometimes unavoidable: they are the safety net that ensures users can always recover their funds regardless of their counterparty's behavior.

Breach Close Scenarios

Breach closes are rare in practice because the penalty mechanism makes cheating economically irrational. A rational actor would never broadcast a revoked state when the downside is losing 100% of their channel funds. Breach attempts typically stem from software bugs that accidentally replay old state, restoring a node from an outdated backup, or deliberate fraud attempts against parties assumed to be offline. Running a watchtower service significantly reduces breach risk by monitoring the blockchain even when a node is offline.

Fee Implications

The fee difference between close types can be substantial, especially during periods of high fee market congestion:

• Cooperative closes let both parties negotiate a fee that reflects current mempool conditions, minimizing cost
• Force closes use a pre-committed fee rate that may be higher or lower than optimal. With anchor outputs, the broadcaster can bump the fee via CPFP, but this adds another transaction and more cost
• Breach closes require the honest party to pay for the penalty transaction on top of the commitment transaction. However, the honest party receives the entire channel balance, so the fee is typically worthwhile

During fee spikes, force close fees can exceed the value of small channels, effectively making those funds uneconomical to recover. This is one reason why channel management and maintaining good peer relationships matter for Lightning node operators. For a deeper look at how fees affect channel economics, see the Lightning channel management guide.

Why It Matters

Understanding channel close types is fundamental to operating on the Lightning Network. The close mechanism directly affects how quickly you can access your funds, how much you pay in on-chain fees, and whether you risk losing funds to a breach attempt. Node operators who understand these mechanics can make better decisions about peer selection, channel sizing, and backup strategies.

The penalty-based close model is also what distinguishes traditional Lightning channels from newer Layer 2 approaches. Protocols like Spark avoid the complexity of commitment transactions and penalty mechanisms entirely by using a different off-chain model. Instead of managing channel state with revocable commitment transactions, Spark uses virtual UTXOs and FROST threshold signatures, eliminating the need for force closes and the associated timelock delays. For a detailed comparison, see What Is Spark.

Risks and Considerations

Backup Risks

Restoring a Lightning node from an outdated backup can cause an accidental breach. If the restored node broadcasts an old commitment transaction, the counterparty will claim all funds via a penalty transaction. This is why static channel backups (SCBs) exist: they allow recovery by triggering a remote force close from the counterparty rather than broadcasting a potentially stale local state.

Watchtower Dependency

The breach close penalty only works if the honest party (or their watchtower) detects the revoked state before the cheater's timelock expires. If a node is offline and has no watchtower running, a cheater could successfully steal funds by broadcasting a revoked state and waiting out the timelock. Longer timelocks provide more safety margin but lock funds for longer during legitimate force closes. For more on this tradeoff, see how Lightning watchtowers work.

Fee Spiking and Flood-and-Loot

The time-bounded nature of breach detection creates a vulnerability: an attacker can force close many channels simultaneously, congesting the blockchain so that victims' penalty transactions cannot confirm in time. This flood-and-loot attack exploits finite block space and the time-limited dispute window. Mitigations include anchor outputs (which allow fee bumping), package relay improvements, and watchtower services that can respond quickly to on-chain events.

Dust Channels

During high fee periods, the cost of a force close transaction may exceed the value held in a small channel. These "dust channels" can become economically unrecoverable, effectively turning the locked funds into a loss. Operators should consider minimum channel sizes relative to expected on-chain fee environments.

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.