Lesson 5 — Backup architectures: paper, metal, SLIP-39, and the redundancy/disclosure trade-off
How seeds actually die: fire, flood, time, theft, accidental disclosure. Today: the realistic backup options, what 'metal-fire-flood' actually means, and where SLIP-39 fits.
A seed that exists only in your head is one head injury away from being gone. A seed written on paper survives a fall and a long memory gap, but not a house fire or a flood. A seed stamped into metal survives most disasters but is a single object that can be stolen wholesale. Real backups are about layering — accepting that no single medium handles every failure mode, and designing the layer cake intentionally.
Single-paper backups fail in five predictable ways: fire (paper burns at around 230°C / 450°F, well below the point where metal seeds suffer), water (ink runs, paper rots), time (cheap paper yellows and crumbles over decades), accidental disclosure (a guest sees it on the desk), and deliberate theft. None of these are exotic. They are the everyday accidents that make 'I had the seed but I don't have it now' the second-most-common form of self-custody loss after forgetting the passphrase.
Metal backups solve fire, water, and time directly. The realistic options divide into two groups. Stamped or punched plates — where you physically strike the letters into a stainless or titanium plate — have no proprietary lock-in and are the most disaster-tolerant. Pre-assembled kits (tile-based, screw-based, threaded-rod systems) are faster to assemble but introduce proprietary parts and assembly errors. Either approach works. The non-negotiable property is that the recovery shouldn't depend on a specific vendor's continued existence — if the vendor disappears, you should still be able to read your own seed.
Multiple-location backups address theft and disclosure. The conventional rule is '3 copies, 2 media, 1 offsite' — three independent copies (so any one being lost or destroyed isn't terminal), at least two different storage media (so a flaw in one medium doesn't affect all copies), and at least one geographically separated (so a single fire, flood, or burglary can't take all three). Applied to seeds, this might be: one metal backup at home, one paper backup in a different room (for redundancy of medium), one metal backup at a relative's house or in a deposit box.
But more copies means more exposure. A seed in five locations is statistically harder to lose but easier to find. The trade-off is intrinsic. SLIP-39 Shamir Secret Sharing offers one way out: split the seed into M-of-N shares such that any M shares can reconstruct the seed but fewer than M reveal nothing. A 3-of-5 SLIP-39 backup gives you redundancy (any 3 of 5 shares survive) and exposure control (fewer than 3 shares are cryptographically useless). The cost is operational: SLIP-39 isn't supported by every wallet (Trezor Model T supports it natively; other wallets vary), and the shares are not interchangeable with BIP-39 mnemonics.
Multisig is sometimes presented as an alternative to fancy backups, and at the wallet level it is — a 2-of-3 multisig wallet has no single secret to lose. But every multisig wallet still has seeds for each signer, and each of those seeds still needs a backup. Multisig changes the failure mode (loss of one seed isn't terminal) but doesn't eliminate backup architecture. We cover multisig itself in Lesson 6.
Anti-patterns to avoid completely: photos of the seed (every modern phone backs them up to a cloud service that has been hacked at scale), plain-text storage in a password manager (the manager's database is a single point of failure for everything in it), email-to-yourself (inbox compromises are common), 'I'll just remember it' (memories fail predictably under stress), and printing the seed on a wifi-connected printer (many printers cache print jobs in NVRAM that has been demonstrated to leak).
Example
Jameson Lopp's seed-storage stress tests — public, repeatable experiments where dozens of metal backup products were subjected to fire (1100°C / 2000°F), corrosion (acid baths, salt water), crushing, and combined attacks — provide the closest thing to data on which storage media survive which threats. The headline finding is that stamped/punched stainless and titanium plates outperform almost every pre-assembled kit on multi-threat survival, and that 'fireproof' marketing language is unreliable. The whole exercise is a useful corrective to assuming any particular product is invincible: the test results are the only evidence that matters.
Common mistakes
- Relying on a single paper copy. The single-point-of-failure problem isn't theft; it's a kitchen fire or a flooded basement.
- Photographing the seed 'just to back it up.' Every modern phone auto-uploads photos to a cloud service whose history of compromise is public record.
- Storing in a password manager only. If the manager is your only backup and the device with it dies, the seed dies with it.
- Using proprietary metal kits whose recovery depends on the vendor staying in business or shipping a tool — read your own seed from your own backup with no proprietary parts and you sidestep the problem entirely.
- Believing that more copies are always better. Past 3 copies in 2 media with 1 offsite, you're adding exposure faster than reducing risk.
- Confusing SLIP-39 with BIP-39. They're different schemes; shares from one are not seeds from the other.
Check your understanding
Your seed is currently written on a single sheet of paper kept in your home office desk drawer. Which single change reduces your risk the most?
Key terms covered
Sources & further reading
- PrimarySLIP-39 — Shamir's Secret-Sharing for Mnemonic Codes
Specification for splitting a seed into M-of-N reconstructable shares.
- SecondaryJameson Lopp — Metal Bitcoin Seed Storage Stress Test
Public stress-test results comparing metal backup products under fire, corrosion, and crushing.
- SecondaryGlacier Protocol — Backup and storage discipline
Open-source protocol documenting multi-location, multi-medium backup procedures.
We prioritise primary sources. Where a topic moves quickly (regulation, security incidents), we re-check sources on the cadence shown by the page's "Next review" date.