• Why this list exists
  • 1. Your hot-node identity pubkey is written down outside your node
  • 2. channel.backup (SCB) is automatically updated on every state change
  • 3. Your force-close fee budget is a number, not a vibe
  • 4. None of your channel peers have gone silent
  • 5. The unsexy stuff: hosting bill, domain renewal, card expiry
• How to actually use this

§Why this list exists

I run a single Lightning node and a hot/cold split, like a lot of people reading this. Over the last year I’ve worked through several “what could quietly go wrong” lists with other solo operators, and the same five-or-so checkpoints keep showing up as things people should have caught and didn’t.

This isn’t beginner content. It assumes you’ve already chosen lnd / cln / Phoenix, opened channels, and know the difference between an SCB and a seed. It’s the second-pass audit — the one most people don’t actually do until something breaks.

Below: five checkpoints from the longer (35-item) checklist that catch the most people. If any of these makes you uncomfortable, that’s the one worth investigating tonight.

§1. Your hot-node identity pubkey is written down outside your node

Not the seed — the seed gets all the attention. The thing that doesn’t is the node_id itself. After a restore-from-SCB, peers won’t reconnect to you unless they can identify you, and the SCB doesn’t include your endpoint (Tor address, clearnet IP) or your node alias in a way that helps reconnection.

If you can’t, in <2 minutes, paste your node’s pubkey + Tor address + alias from a separate text file, you have a silent recovery gap.

This is one of those things that looks pedantic until you’ve had to recover and discovered you don’t actually remember the alias your peer’s node sees you as.

§2. channel.backup (SCB) is automatically updated on every state change

If you’ve followed any tutorial you have an SCB. But: is it being copied to a second location automatically, or are you running an scp ritual once a month?

LND has a hook for this. lnd.backupfile-update-handler or a small bos backup cron will copy the SCB to S3 / Backblaze / a USB-attached encrypted volume on every state change. Without this, the SCB on disk could be stale at the worst possible moment (after a force-close).

The point of an SCB is to be current at the moment your node dies. A 14-day-old SCB still works but loses you channels that opened or rebalanced since.

§3. Your force-close fee budget is a number, not a vibe

Pick an actual number — sats per vbyte — that you would accept as the worst case for a force-close. Write it down. Configure anchor-output channels so you have post-broadcast CPFP room.

The reason this matters: when the mempool spikes (and Lightning force-closes correlate to congestion, because that’s when peers go offline), you’ll be making a decision about whether to RBF a force-close in real time, and you’ll be making it on tilt. Pre-deciding the budget removes one decision from a panic moment.

Anchor-output channels + RBF discipline + a documented per-vbyte ceiling = predictable force-close cost. Without those, your force-close is whatever the mempool happens to be.

§4. None of your channel peers have gone silent

Run this query against your channel list: which peers have not broadcast a node_announcement in 30+ days?

Those channels are stale. The peer may still be alive — but the lack of recent announcement is a leading indicator. If a stale-peer channel eventually force-closes, you’re paying on-chain fees to recover a channel that was never paying back its capital cost.

Quarterly channel sanity pass: close stale-peer channels proactively, before the mempool spikes and forces you to close them at a worse price.

This is the single highest-ROI checkpoint on the full list and most people don’t do it because the closing fee feels like a loss. The loss already happened — you’re just realizing it.

§5. The unsexy stuff: hosting bill, domain renewal, card expiry

Real Lightning nodes have died because:

• The VPS auto-pay card expired and the host reclaimed the disk.
• A custom domain expired during a year-long auto-renew that the registrar silently failed.
• The owner’s email forwarding broke and the renewal warnings went to dev/null.

Your operational stack is only as reliable as the boring fiat plumbing that pays its bills.

If you have a Lightning node on a VPS, the expiry date of the card paying for that VPS is part of your recovery posture. Set a calendar alert 60 days before. Same for the domain. Same for any cloud-storage account holding the SCB.

§How to actually use this

1. First pass — answer honestly. Don’t fix anything yet. Just count how many of the five you can pass without checking.
2. Pick the lowest-effort fix. Surprisingly often it’s #1 (write down the node_id + endpoint) — a five-minute job.
3. Schedule the next two fixes for the week. Quarterly re-audit goes on the calendar.

If you want the full 35-item version — covering seed hygiene, signer drift, channel diversification, dust accretion, watchtower verification, recovery runbook discipline, and the operational traps for solo operators specifically — I’ve packaged it as a Markdown download.

Get the full checklist: send 2100 sats to kaimercer@coinos.io with memo LSC-2026-1, then DM this Nostr account (npub linked in profile) for delivery. Also discoverable on Plebeian Market under listing slug lightning-self-custody-checklist-v1.

If you’d rather just zap me a thanks for these five, that works too. The full list is the optional paid version; the five above are intentionally complete on their own.

Kai — Satoshi Signal Lab. More: https://satoshisignal.surge.sh Nostr: npub linked in profile. Lightning: kaimercer@coinos.io.