Shutdown script

Each side of a closing channel names its own destination, and the closing transaction pays both of them there. BOLT 2 gives that message type 38 and accepts only witness version 0 scripts unless the peers negotiated feature bits 26 and 27. Anyone moving Lightning funds back to cold storage should check that destination before closing, not afterwards.

How it works

A shutdown script travels inside a BOLT 2 message of type 38, which carries the channel id, a two byte length, and then the script bytes themselves.

Either peer can send that message, and once no updates are outstanding the other must answer with a shutdown of its own. From that point the channel is winding down: no update_add_htlc may follow a shutdown, and a node should refuse to route any HTLC arriving afterwards. It may be sent before channel_ready, so a channel whose funding transaction is still confirming can be abandoned early.

The specification is narrow about what the script may be. Two forms are always legal: OP_0 and a 20 byte push, a pay to witness public key hash output, or OP_0 and a 32 byte push, pay to witness script hash. Witness versions 1 through 16, followed by a push of 2 to 40 bytes, are legal only where option_shutdown_anysegwit was negotiated, feature bits 26 and 27, so a Taproot payout depends on your peer supporting it. A third form came with option_simple_close, bits 60 and 61: OP_RETURN plus a push of 6 to 75 bytes, or the OP_PUSHDATA1 variant for 76 to 80 bytes, the ceiling being that an OP_RETURN script is standard on Bitcoin only up to 83 bytes. It exists where your share is too small to be worth an output, and the amount must then be zero, so it goes to miners as fee.

A node can also pin its destination when the channel opens, in the upfront_shutdown_script TLV record, type 0, of open_channel and accept_channel, feature bits 4 and 5. If both peers advertised it and a non-zero-length script was given, a later shutdown naming anything else must fail the connection. BOLT 2 is candid about what that buys: it calls the pre-commitment "a weak commitment (a malevolent implementation tends to ignore specifications like this one!)" worth an incremental improvement, because changing the destination afterwards needs your peer's cooperation.

Where you see it

Shutdown scripts belong to whoever owns the channel, which is not always you.

Among the 41 wallets reviewed here, compare Phoenix, rated 4.0, which runs a real self-contained Lightning node on the handset, with Wallet of Satoshi, rated 2.7 and flagged caution for its custodial mode. Phoenix's channels are yours, so a cooperative close puts an address you control into the shutdown message. In Wallet of Satoshi's custodial mode, withdrawn from the United States and the European Union, the channels are the company's, the scripts name its addresses, and what you hold is a claim rather than a key.

The second place it surfaces is a close that quietly fails. Old nodes can still send non-segwit shutdown scripts, and BOLT 2 notes that a closing transaction whose non-segwit output is below 546 satoshis, possible when dust_limit_satoshis was set lower, will likely never reach miners. No funds are at risk, but the channel has to be force-closed instead of settled. Under option_simple_close a fresh closing_complete overrides the previous one, so fee and output script can both be revised, unless the upfront variant froze the destination at channel open.

Shutdown script vs force close

A shutdown script decides where money lands only in a cooperative close.

A force close skips the negotiation: you publish the latest commitment transaction, and its outputs pay keys derived from the basepoints exchanged when the channel opened, not an address you nominated. The script you set carefully has no effect on the one exit that needs no permission from your peer. Set it for the close you intend, and keep a channel backup for the close you do not.