Lightning wallets and inheritance

Why Lightning is different

An ordinary bitcoin wallet is a seed phrase: restore it anywhere and the coins are there. A Lightning wallet is a seed phrase plus the current state of each payment channel, which changes with every payment. The seed alone recovers what’s on-chain, plus whatever a partner eventually closes back to you. For the channel balances, the recovering side has to ask the channel partner to close the channel at the latest state, which works only if that partner is online and honest, and even then the money only arrives once the partner’s closing transaction confirms.

For an heir who has never heard of a channel, that’s a lot. Which is why this page’s first piece of advice is about amounts.

Keep it small

Lightning wallets hold the bitcoin you spend, not the bitcoin you leave behind. Move anything inheritance-sized to an on-chain wallet with a proper plan; the methods compared start there. What’s left in Lightning should be an amount nobody would grieve over if a channel never closed.

Wallet by wallet

• Custodial apps (Wallet of Satoshi, Strike, Cash App, Blink and similar). The company holds the bitcoin; your app is a login. Heirs claim through the company with the estate documents, like an exchange account. Wallet of Satoshi now also has a self-custody mode, and its help pages draw the line: unlike a custodial wallet where the company “can help restore access, in self-custody you are the only one who controls your Bitcoin” (Wallet of Satoshi). Put the app, which mode, and its email address on the inventory.
• Phoenix (ACINQ). A 12-word seed; “If you lose the recovery phrase, your funds are lost” (ACINQ). Channel state is backed up, encrypted, to ACINQ’s servers, so reinstalling the app and entering the seed normally brings everything back (Phoenix FAQ); if that fails, the channels are closed and the funds return on-chain after a delay of up to about a week. For heirs: the seed and the name “Phoenix” are enough.
• Breez, Zeus and similar self-custodial apps store channel state in a cloud backup (Google Drive, iCloud) or on their own servers. The heir needs the seed and access to that backup, which means the deceased’s cloud account. Write down which it is.
• Your own node (LND, Core Lightning). The hardest case. LND’s seed recovers on-chain funds “as well as all funds from channels your peers force close on you after your node goes offline”; for the rest you need the static channel backup file, channel.backup, which asks peers to force-close at the latest state (LND docs, disaster recovery). Core Lightning is explicit that the master secret is “necessary, but insufficient, to recover any in-channel funds” and keeps an emergency.recover file for the same purpose (Core Lightning docs).

What goes wrong with a dead node

Peers aren’t obliged to close a channel because the other side went quiet; many leave it open for years. Until someone closes it, the money is stuck. With the backup file, an heir (or the technical helper named in your letter) can trigger the closes, and for peers that have disappeared there are rescue tools, with a warning worth quoting: “most cases where users actually lost funds it was due to them running commands they did not understand in a rush of panic” (chantools). This is specialist work. If you run a node, name a specialist.

What to write down

• Which app or node software, and that it’s Lightning.
• The seed, stored like any other (where).
• For apps with cloud backups: which cloud account, and how to get into it (emergency access).
• For your own node: where the channel backup file is kept and kept current (it changes every time you open a channel), where the node runs, and who can operate it.
• Roughly how much is in channels, so nobody spends a week recovering twenty euros.
• The instruction to close channels and move everything on-chain, rather than keep the node running.

Next: The rehearsal: testing your plan with your heirs.