Static Channel Backup (SCB)

What Is a Static Channel Backup?

A static channel backup (SCB) is a compact file that records the minimum information needed to reconnect with former Lightning channel peers and trigger cooperative force-closes after a node loses its channel database. Introduced in LND v0.6-beta in 2019, SCB addresses a critical risk in Lightning node operation: if the database storing current channel state is destroyed (hardware failure, corruption, accidental deletion), the node operator could permanently lose access to funds locked in open channels.

The word "static" is key. Unlike a full database backup that would need updating after every payment, an SCB only changes when a channel is opened or closed. It does not track individual payments, routing events, or balance changes. This simplicity is both its strength (easy to maintain, small file size, infrequent updates) and its limitation (recovery always means closing every channel, not resuming them).

Think of an SCB like an emergency contact list for your Lightning channels. It tells your node who your channel partners are, where to find them on the network, and which on-chain transaction funded each channel. With that information plus your seed phrase, your node can reach out to each peer and ask them to close the channel cooperatively, returning your funds to an on-chain address you control.

How It Works

SCB recovery relies on the Data Loss Protection (DLP) protocol, defined in the BOLT #2 specification. DLP extends the standard channel_reestablish handshake with additional fields that allow a fallen-behind node to safely recover funds without risking a penalty transaction.

What the Backup Contains

Each channel entry in an SCB file stores a specific set of static metadata:

• Funding outpoint: the on-chain UTXO (transaction ID and output index) that created the channel, serving as a unique channel identifier
• Remote node public key: the identity key of the channel peer, used to reconnect
• Peer addresses: IP or Tor addresses previously used to reach the peer
• Key derivation paths: information needed to re-derive the local signing keys from the seed phrase
• Channel configuration: CSV delay values and remote public keys needed to reconstruct output scripts
• ShaChain root descriptor: key information for deriving the revocation chain root

Critically, the backup does not contain current balances, the latest commitment transaction, in-flight HTLCs, or payment history. This is why SCB cannot restore a channel to its working state.

The Recovery Process

When a node operator loses their channel database and needs to recover, the process follows five steps:

1. Initialize a fresh LND node using the original 24-word seed phrase, triggering a chain rescan to recover on-chain funds
2. Import the SCB file, which creates "channel shells" in the database containing only the information required to initiate the DLP protocol
3. The node connects to each former channel peer using the stored addresses and identity keys
4. Upon connection, the channel_reestablish handshake triggers DLP: the remote peer detects the local node has lost state and initiates a force-close
5. Once the force-close transaction confirms on-chain and the CSV timelock expires, the recovering node sweeps funds using keys derived from the commitment point received during the DLP handshake

# Restore channels from backup file
lncli restorechanbackup --multi_file /path/to/channel.backup

# Or restore from hex-encoded backup data
lncli restorechanbackup --multi_backup <hex_encoded_backup>

The full recovery typically takes one to two weeks. Peers may take a day or two to come online, and the CSV timelock on commitment outputs (commonly 144 blocks, roughly one day, but up to 2016 blocks, roughly two weeks) must expire before funds can be swept.

The Data Loss Protection Protocol

DLP is the safety mechanism that makes SCB recovery possible without risking fund loss. When two peers reconnect, they exchange channel_reestablish messages containing their expected commitment numbers. If one peer detects the other has fallen behind:

1. The non-fallen-behind peer verifies the other's state using your_last_per_commitment_secret
2. It sends its current my_current_per_commitment_point, which the recovering node needs to derive keys for sweeping funds
3. The non-fallen-behind peer then force-closes the channel using its latest commitment transaction

The protocol ensures the non-fallen-behind peer does not broadcast an old commitment transaction that could be penalized. It also provides the recovering node with the cryptographic material needed to claim its output from the force-close transaction.

Backup Practices

When to Update

The SCB file (stored at ~/.lnd/data/chain/bitcoin/mainnet/channel.backup by default in LND) is atomically updated every time a channel opens or closes. Because the backup is static, it does not change with individual payments or routing events. The backup only needs to be copied when the file changes.

Where to Store

The backup file is encrypted with ChaCha20-Poly1305 using a key derived from the node's seed, so it is safe to store on cloud services like Google Drive, Dropbox, or iCloud without exposing channel information. Best practices include:

• Store on a physically separate medium from the node (external drive, different machine, or cloud storage)
• Keep multiple copies in different locations for redundancy
• Automate backup copying using file watchers or LND's streaming RPC

Automating Backups

LND provides a SubscribeChanBackups streaming RPC endpoint that pushes updated backup data every time a channel opens or closes. This allows applications to automatically copy the latest backup without polling the filesystem:

# Export current backup manually
lncli exportchanbackup --all --output_file /backup/channel.backup

# Monitor for changes and auto-copy (Linux)
inotifywait -m -e modify channel.backup | while read; do
  cp channel.backup /backup/channel.backup
done

Regardless of method, both the SCB file and the 24-word seed phrase are required for recovery. One without the other is useless.

Cross-Implementation Comparison

While SCB is most closely associated with LND, other Lightning implementations have similar recovery mechanisms:

Core Lightning prefers real-time database replication over static backups, with emergency.recover serving as a last-resort fallback. Eclair updates its backup on every state change, providing more current recovery data but requiring more frequent backup operations. All three implementations rely on the same underlying DLP protocol for fund recovery.

Use Cases

Hardware Failure Recovery

The primary use case for SCB is recovering funds after a node's storage device fails. A Lightning node operator running LND on a Raspberry Pi, for example, faces real risk of SD card corruption. With a recent SCB stored offsite, the operator can set up a new node, restore the wallet from seed, import the backup, and recover all settled channel funds.

Node Migration

While not the recommended migration method (a clean database transfer is preferable), SCB serves as a safety net when migrating a node to new hardware. If the database migration fails or becomes corrupted, the SCB provides a fallback recovery path.

Disaster Recovery Planning

Any operation running Lightning infrastructure should include SCB as part of its disaster recovery plan. For Lightning service providers managing channels on behalf of users, automated SCB storage is a minimum operational requirement for safeguarding funds.

Risks and Considerations

Channels Are Closed, Not Restored

SCB recovery force-closes every channel. All routing capacity, inbound liquidity, and channel relationships are destroyed. Rebuilding channels takes time and incurs on-chain fees for each new channel opening. For nodes with carefully managed liquidity and established routing positions, this represents a significant operational cost beyond the funds at risk.

Peer Must Be Online

Recovery depends on channel peers being online and responding to the DLP protocol. If a peer has permanently gone offline (abandoned node, lost keys), the funds in that channel may be inaccessible through standard SCB recovery. LND's chantools utility provides an scbforceclose command that can force-close without peer cooperation when the backup includes CloseTxInputs data (available since late 2024), but this requires the backup to have been created with the --backupclosetxinputs flag enabled.

In-Flight HTLCs Are Lost

Any HTLCs that were pending at the time of data loss cannot be recovered through SCB. Only the settled channel balance (the to_local output in the commitment transaction) is recoverable. For nodes routing significant payment volume, the amount locked in in-flight HTLCs at any given moment could be non-trivial.

Never Restore an Old Database

A common and dangerous mistake is restoring a stale copy of the LND channel database instead of using SCB. If the restored database contains an outdated commitment transaction and the node broadcasts it, the channel peer (or a watchtower) can issue a justice transaction that seizes all funds in the channel as a penalty. SCB avoids this entirely by never broadcasting a commitment transaction directly: it asks the peer to force-close using their latest state.

Both Parties Cannot Lose State

The DLP protocol requires at least one party to have current channel state. If both peers lose their databases simultaneously, neither can safely force-close the channel, and funds may be permanently locked. This scenario is unlikely for independent nodes but could affect infrastructure sharing a single cloud provider or data center.

Why It Matters

Self-custodial Lightning operation means accepting responsibility for fund safety. Without SCB, a hard drive failure could mean permanent loss of every satoshi locked in Lightning channels. SCB transforms this catastrophic risk into a recoverable inconvenience: channels are lost, but funds are not.

For the broader Lightning ecosystem, SCB and the DLP protocol represent a practical tradeoff between full state backup complexity and user-friendly recovery. Full channel state backups are dangerous (broadcasting an old state triggers penalties), while SCB is safe by design because it delegates the force-close to the peer who holds current state.

Modern Layer 2 protocols like Spark approach the backup problem differently. By using FROST threshold signatures and a stateless virtual UTXO model, Spark eliminates the need for users to maintain local channel databases entirely, removing the class of risks that SCB was designed to mitigate. For a deeper comparison of Lightning channel management challenges, see the Lightning channel management guide.

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.