Glossary / Lightning & layer 2
Cooperative close
- What is a cooperative close?
- A cooperative close ends a Lightning channel by agreement: both peers sign one transaction that pays each side its final balance, with no delay and no penalty risk.
A cooperative close is a short negotiation over two things: where each side wants to be paid, and who pays the miner fee. The modern path uses three message types, shutdown at type 38, then closing_complete at 40 and closing_sig at 41 under the option_simple_close rules. Your balance arrives as an ordinary spendable output as soon as the closing transaction confirms, with no waiting period.
How it works
A cooperative close runs in two stages, and the first stage is a promise to stop.
Either peer opens by sending shutdown, type 38, naming the scriptpubkey it wants its payout sent to. The sender may add no new HTLC after that, and the other side must answer with its own shutdown once nothing is left pending. BOLT 2 restricts that script to forms the network will relay: a 20 or 32 byte push behind OP_0, or, once option_shutdown_anysegwit is negotiated, OP_1 through OP_16 followed by a push of 2 to 40 bytes.
The second stage starts once no HTLCs remain on either commitment. Under option_simple_close, feature bits 60 and 61 in BOLT 9, each peer builds its own version of the closing transaction, takes the whole fee out of its own balance, and sends closing_complete, type 40. The other side signs what it was handed and returns closing_sig, type 41. Because the proposer pays, the argument over fee level has nowhere to go, which BOLT 2 states as the point of the design. Sending closing_complete again at a higher fee is how the close gets bumped, and BOLT 3 gives that transaction an input sequence of 0xFFFFFFFD, which the spec calls an RBF of the previous attempt.
The legacy path, closing_signed at type 39, still stands in the spec. There the funder names a fee plus a fee_range of min_fee_satoshis and max_fee_satoshis and the non-funder picks a number inside it, which settles in two messages if it picks the same value and three otherwise. With no range, each reply has to fall strictly between the last two offers, so the sides converge a satoshi at a time.
Where you see it
A cooperative close is what your wallet does when you press close and the peer answers: one transaction, no pending balance behind it.
BOLT 2 carries its own walkthrough. A and B exchange shutdown scripts, the pending HTLCs finish, and then A offers to pay 1,000 satoshis of fee while B independently offers 750. Each signs the other's version. A later changes its payout script and re-sends at 1,100 satoshis, and B bumps its own attempt to 850.
Small channels are where the rules bite. The side with less money may drop its own output, and must drop it if the amount would be dust. If fees would make both outputs dust, the closer can send an OP_RETURN script in place of an address, and its output value is set to zero so that side's funds go to fees and the transaction still relays. The spec warns that an output below 546 satoshis paid to a non-segwit script may never reach a miner, and that such a channel has to be force closed instead.
Cooperative close vs Force close
A cooperative close and a force close both end a channel with an on-chain transaction, and the difference is who waits.
In a cooperative close both outputs are plain payments, so each side can spend at the first confirmation and no penalty branch is ever in play. A force close publishes a commitment transaction instead, leaving your own balance behind a block delay agreed when the channel opened and giving every in-flight payment its own follow-up transaction. Our Phoenix review puts that wait at roughly 720 blocks, about five days, before force closed funds can be recovered.
A cooperative close needs the other node awake and willing to answer a shutdown. That is why the force close exists, and why a peer you cannot reach is a peer whose closing fee you do not control.