How to back up a Bitcoin or crypto seed phrase without trusting one person or location

A seed phrase is a single point of failure. If one person has it written down somewhere, that person — or whatever happens to that piece of paper — is your entire risk model. Threshold sharing fixes that.

10 min read · Updated 2026-05-25

Why a seed phrase is different from a password

A BIP39 seed phrase is the master key to a wallet. Whoever holds the phrase can recreate the wallet on any device and move every asset in it. There is no "forgot password" link, no provider to call, no recovery email. It is also irrevocable — there is no way to rotate a leaked seed without moving every coin to a new wallet.

That means a seed phrase backup has to satisfy two opposing requirements simultaneously:

• It must be recoverable in scenarios you can't predict (lost device, house fire, dead drive, death).
• It must not be recoverable by anyone who shouldn't have it — burglar, snooping family member, server breach, abusive partner, coerced helper.

A single copy fails the first test. A copy held by one trusted person fails the second. A copy backed up to a cloud account fails both, slowly, over time.

Why not just multisig?

Native multisignature wallets (e.g. 2-of-3 multisig on Bitcoin) are a good fit when you have the technical chops to manage multiple hardware wallets and the patience to pay slightly higher fees on every transaction. They're a different security model: signing requires the quorum, not just recovery. That's stronger.

But multisig has tradeoffs that make it the wrong tool for many holders:

• It changes how you transact every time, not just how you back up.
• It requires coordinated software and hardware compatibility across the keyholders.
• It's network-specific (a multisig wallet on Bitcoin isn't the same setup as on Ethereum, etc.).
• Recovery flow can be more brittle if any one signer's setup drifts.

Shamir-splitting a seed phrase gives you the backup property of multisig — no single point of failure — without changing how the wallet operates day to day. Use multisig if you want signing-time quorum and have the operational maturity. Use Shamir for backup if you want resilience without changing the wallet.

Picking a threshold for personal use

2-of-3

Three portions, any two recover. Survives loss of any single portion. Good for individuals with one or two trusted helpers.

3-of-5

Five portions, any three recover. Survives loss of two simultaneously (house fire and a helper unreachable). Good when your network of trustworthy holders is wider and you want belt-and-suspenders redundancy.

Why not 1-of-N?

A 1-of-N "split" isn't a split — it's N copies. Every holder has full access. You've multiplied the attack surface without distributing trust.

Why not N-of-N?

Maximum collusion resistance, zero fault tolerance. One lost portion loses the wallet. Almost never the right answer for backup.

Where the portions should go

The locations matter as much as the math. The goal is independent failure: any single bad event should be below threshold.

Locations that work well

• Home safe (fireproof, anchored). Survives most household incidents short of total loss.
• Bank safe-deposit box. Physically distant, professionally secured, but: not all jurisdictions protect contents as well as people assume — never store the only copy in one, and read your bank's terms.
• Trusted family member, in their safe. Geographic separation, but introduces the social-engineering / falling-out / death-of-helper risk. Mitigate with threshold.
• Trusted attorney or estate-planning firm. For very long-term custody (the "if I die" portion).
• Self-storage facility with climate control. For a metal backup plate in a sealed container — slow access, low collusion risk.

Locations that look fine but fail

• Cloud notes, email, or any synced device. Even encrypted, the operational lifetime is decades; the device-loss / account-compromise odds are high; and worst of all, you'll forget which devices have it.
• Two locations in the same building. Not two locations. One fire.
• Your hardware wallet's seed card in the wallet's box. Defeats the purpose entirely. If a thief takes the wallet, they take the recovery seed too.
• A photo on your phone "just to be safe." Cloud backup, OCR scanning, photo apps' "memories" features, malware. Don't.

Storage media: paper vs. metal vs. digital

Paper

Cheap, easy to print or write by hand. Fails to fire, flood, mildew, rodents. Fine for short-term or supplementary storage; suspect for primary custody on a multi-decade horizon.

Metal backup plates

Steel plates with stamped or engraved letters (Cryptosteel, Billfodl, generic punch-stamped washers). Survives fire and water. The right primary storage for a long-lived split.

Each plate stores one portion. Two-of-three becomes three plates in three locations. A burglar finding one plate sees a sequence of words that looks like a partial seed but reconstructs to nothing.

QR code on paper

Good middle ground. Easier to import back into shattr's decrypt tool than typing by hand, and removes transcription risk. Print on durable paper; laminate. Don't store the QR online.

Digital portions on a personal-vault device

If a holder really wants a digital copy, use a personal password manager with a hardware-key unlock and never sync the entry to a cloud account that's accessible without that key. The portion is mathematically useless alone, but you still don't want to make collection trivial.

Generating the split safely

The brief window when your unsplit seed phrase exists on a computer is the riskiest part of the whole exercise. Some habits that meaningfully reduce risk:

1. Use shattr's create-share tool — it runs in your browser, doesn't transmit the secret, and is SRI-pinned so the script can't be silently swapped.
2. Do it on a freshly booted, offline device if the value justifies it. Tails Live, a fresh Ubuntu USB, or a hardware-wallet vendor's air-gapped flow are all fine.
3. Close all other browser tabs and quit other apps while the secret is in memory.
4. Write or stamp the portions immediately. Don't leave them on disk. Don't print to a shared printer.
5. Restart or shut down the device when you're done. The unsplit phrase shouldn't outlive the splitting session.

Recovery rehearsal — once a year, minimum

A backup that's never been tested is hope, not a backup. Annually:

1. Retrieve the threshold number of portions.
2. Reconstruct the seed phrase using shattr's decrypt tool on an offline device.
3. Verify the seed matches your live wallet — e.g. by importing it into a watch-only wallet on the same device and confirming the first receive address matches.
4. Wipe the device.
5. Return the portions to their original locations.

If a portion is unreadable, illegible, or its holder has changed circumstances, treat it as a rotation event: regenerate fresh portions, redistribute, retire the old ones.

The estate-planning version

If part of your reason for splitting the seed is that someone needs to inherit the wallet, the rules tighten:

• At least one portion should be held by a fiduciary or attorney whose succession is itself well-defined.
• The recovery procedure (which portions to gather, what tool to use, how to verify) must be written down — and the document itself should not contain or reveal a portion.
• The procedure should be discoverable by your heirs even if they don't know the wallet exists. A sealed envelope with your will is a common pattern.
• You should rehearse the recovery with at least one of the eventual recipients during your lifetime, so the procedure has been touched by the people who'll need it.

What Shamir-splitting a seed does not protect against

• Compromised splitting environment. If malware is watching your screen when you split, it has the seed. Split offline when stakes are high.
• Compromised reconstruction. The same applies on recovery. Use a clean, ideally offline device.
• Coerced custodians. If a threshold of holders can be physically compelled, the math doesn't help. Choose holders whose risk profiles are uncorrelated.
• Bad math implementations. Use a reviewed library. shattr uses Adi Shamir's original construction over a finite field — the same one the academic literature has scrutinized for 40+ years — through a battle-tested library, SRI-pinned so you can prove which code ran.