Lightning Static Channel Backups: What Wallet Recovery Needs

A Lightning static channel backup is not a second seed phrase or a snapshot that necessarily reopens your old channels. For LND, the seed supplies key material and the SCB supplies channel-recovery information; the documented recovery path normally brings settled channel funds back on-chain with peer cooperation. Identify your wallet implementation before treating any backup file as sufficient.

Write a recovery inventory while the wallet still works

Suppose a fictional operator, Ada, keeps a paper recovery phrase and a file called backup on the same laptop as her node. That sounds like two backups, but a failed laptop could remove the file along with the working node. Worse, its name does not establish which application created it or which channels it covers. A useful inventory records the origin and purpose of each item without copying secrets into the inventory itself.

• Wallet application, implementation, network and version, with a link to its own recovery instructions.
• Where the recovery secret and any separately required secret are stored securely; record locations rather than the secret values.
• Type of channel backup or state-storage system and when it last successfully updated.
• Which open channels the backup covers, where that can be checked through the wallet, and how an off-device copy is maintained.
• What recovery is intended to produce: on-chain funds, resumed channels through a supported state system, or access to a custodial account.

This inventory is also a boundary against inappropriate advice. A custodial login does not automatically give you a personal channel.backup file to restore. An LDK-based mobile wallet is not an LND node merely because both send Lightning payments. Keep the general Lightning overview for context, then choose recovery documentation for the exact system you used.

What each item contributes to an LND recovery

The LND recovery documentation distinguishes on-chain recovery from channel recovery. It describes aezeed as a different seed format from BIP39, despite their shared English word list. The SCB is encrypted using seed-derived material and does not work as an independent replacement for the seed. A file successfully opening on your computer is not evidence that it can recover a different node’s channels.

For ordinary SCB recovery, the goal is recovery of settled funds, not a reconstruction of every pending payment. Pending HTLCs need particular attention rather than being counted as recovered because the seed was accepted. Keep a list of unresolved payments and old channel references as evidence for the operator helping you. Do not promise a recipient that such an operation has failed simply because your node became unavailable.

Static does not mean you can ignore new channels

Lightning Labs’ planning-for-failure guide describes maintaining a separate copy of channel backup information as channels are added. The practical question is whether your preserved backup covers the channels you currently have. A copy created before a later channel was opened cannot be assumed to contain that channel just because it has the right filename.

Check the destination of an automated backup as carefully as the automation itself. A successful export into a folder on the failing drive does not solve device loss. A sync task showing no error does not prove that you can access its destination after losing the laptop. Review those access dependencies without placing your phrase, backup contents or passwords into a public support ticket.

Do not confuse an SCB with a periodically copied live channel database. Channel state changes during operation. Starting a stale database can be dangerous, and a simple calendar timestamp is insufficient to establish its safety. Preserve recovered files without launching competing copies of the node. Whether an available database can assist recovery is a question for the implementation’s documented procedure and, where needed, specialist review.

Choose the recovery branch before replacing the installation

The Lightning Labs disaster-recovery guide presents channel recovery as a last resort, warns that channels will close, and requires the old node to remain stopped in the recovery process. It is a different operation from moving a healthy installation to new hardware. A slow startup or a lost mobile connection alone does not establish that destructive recovery is necessary.

1. Determine whether the original node is genuinely lost or whether its connectivity, storage or application problem can be diagnosed without replacing state.
2. Preserve available original data and identify the correct recovery-secret format and matching backup through official documentation.
3. Separate a planned migration from emergency recovery. Do not run old and recovered node instances concurrently.
4. Read the expected recovery outcome and the cases requiring peer cooperation before invoking a recovery function.
5. Track each channel and resulting on-chain transaction through to its actual outcome, retaining unresolved entries for support.

Peer availability can affect the ordinary recovery path. Current LND documentation also discusses advanced last-resort material for cases where a peer is unavailable; it warns about severe stale-state risks. That is not an invitation to extract and broadcast transactions yourself. If the normal path cannot proceed, retain evidence and seek implementation-specific help instead of treating an online recovery command as a harmless balance-refresh tool.

Other Lightning wallets use different backup systems

Core Lightning’s backup guide separately identifies its root secret, static channel-recovery file and database. Its recovery file is named emergency.recover, rather than LND’s channel.backup. The guide warns against relying on old database snapshots. These are examples of why translating filenames between implementations or importing a seed into a random Bitcoin wallet does not constitute a complete channel-recovery plan.

ZEUS documents a different arrangement for its LDK Node wallet: channel state is stored through VSS, and the seed alone recovers on-chain funds in another compatible wallet without supplying that state. Its instructions prohibit simultaneous use of the wallet on multiple devices. Check that the instructions concern your selected ZEUS wallet type, rather than applying an embedded-node guide to a remote connection.

Make preparedness checks different from an actual recovery

You can improve an inventory without triggering channel closure: confirm the backup destination is accessible, check that the stored item is the documented file type, and review whether recent channel changes were captured. Do not experiment with live funds by starting an old node image. Ask the wallet maintainer which non-destructive verification method it supports, rather than assuming that every Restore button is a safe rehearsal.

Return to Ada’s example. Her first correction is not to force-close a channel; it is to identify the file, remove the single-device dependency and document the correct recovery branch. If the device has already failed, she preserves the recovered files and explains what is missing before taking action. This separates preparation from emergency decisions and gives support a clear account of what can actually be recovered.

When recovery produces on-chain BTC, review the actual spendable result before creating a further transfer. Moving Lightning funds on-chain describes that distinct destination, while simple swap is a separate order process with its own supported inputs. Neither a new swap order nor an explorer balance can replace the missing secrets or channel records required by your wallet’s recovery method.