Static Channel Backup

Overview

An LND SCB contains information about channels and peers and is encrypted for the node. During recovery, the restored node contacts peers and asks them to force-close channels, allowing the owner to recover settled on-chain funds.

An SCB does not restore channels to their former live operating state or reconstruct every latest commitment locally. It complements the wallet seed and must correspond to the affected node. Missing peer availability or unusual channel conditions can complicate recovery.

Operators should automatically copy updated channel backups to independent locations, preserve the node seed separately, and verify backup integrity. Recovery procedures should follow the implementation’s current guidance and avoid using stale channel databases incorrectly. Tests should confirm that backups belong to the intended node without exposing production secrets.

The scope of Static Channel Backup should identify the protected wallet, key, account, service, or business process; the triggering failure; who may declare the incident; which identity and entitlement evidence is required; and the recovery point and recovery time objectives that govern restoration.

For Static Channel Backup, important risks include fraudulent recovery requests, guardian collusion, unavailable shares, outdated backups, compromised cloud accounts, missing derivation metadata, untested procedures, and simultaneous loss of primary and backup systems. For Static Channel Backup, independent storage and periodic exercises reduce correlated failure but introduce their own custody obligations.

Evidence for Static Channel Backup should preserve incident time, affected identifiers, last known state, claimant and approver checks, backup or share version, actions performed, credentials revoked, assets verified, discrepancies found, and final owner acceptance. For Static Channel Backup, sensitive recovery material must not appear in the incident record.