Shamir backup refers to using Shamir's Secret Sharing to split a recovery secret into multiple pieces (shares) so that some subset of those pieces can reconstruct the original seed phrase or recovery secret. The cryptographic method dates to Adi Shamir's 1979 paper on secret sharing (the classic reference) and is information-theoretically sound: fewer than the threshold of shares reveal essentially no information about the secret (Shamir, 1979).
SLIP‑39 is a specific standard that encodes Shamir-style shares into human-readable word lists and metadata so hardware wallets and companion apps can create, transport, and restore split backups in a consistent way. See the SLIP‑0039 specification for the technical details (SLIP‑0039 spec).
I believe this approach is best described as a distributed backup system (not a change to how private keys are derived). It helps with physical redundancy and recoverability, but (importantly) it does not replace multi-signature security models.
Short version: you choose n shares and a threshold k; any k shares will rebuild the secret. Longer version: SLIP‑39 encodes the secret into multiple word-based shares, optionally organized into groups with per-group thresholds (useful for family/business splits). Each share contains checksum and metadata so restoration can be automated by compatible hardware wallet software.
An example: create 5 shares with a 3‑of‑5 threshold. You can distribute those five shares across locations (home safe, safety deposit box, lawyer, trusted friend, waterproof steel plate). If any three are available, the original seed can be reconstructed. Which three? Any three. (Neat, right?)
Technical references and details are in the SLIP‑39 spec linked above; the canonical BIP‑39 standard for 12/24-word seed phrases is at the Bitcoin BIPs repository (BIP‑39 spec).
How to set up a Shamir backup will differ by hardware wallet and companion app. Follow device documentation first. That said, the common, device-agnostic steps look like this:
And always practice a dry-run restore. But do not test restores with real funds unless you understand the process.
| Feature | SLIP‑39 (Shamir backup) | BIP‑39 24‑word seed phrase |
|---|---|---|
| Redundancy / Partial loss tolerance | Yes — choose k-of-n or group thresholds | No — single phrase needed |
| Human-readability | Word-based shares with checksum | Word-based recovery phrase |
| Interoperability | Requires SLIP‑39-aware wallet for restore | Widely supported (BIP‑39 standard) |
| Complexity for user | Higher (planning, distribution) | Lower (single phrase to secure) |
| Replaces multisig? | No — backup technique only | No — single-sig backup |
| Passphrase compatibility | Implementation-dependent — verify device docs | Standardized passphrase option (BIP‑39) |
Sources: SLIP‑39 spec and BIP‑39 spec (SLIP‑0039, BIP‑39).
Which should you choose? That depends on your threat model (see next sections). I’ve used both approaches in testing and they serve different workflows.
But remember: Shamir reduces single-point-of-failure risk for backups. It does not reduce attack risk from malware or phishing during normal transactions.
Short answer: Shamir splits one private key into recoverable pieces. Multisig distributes signing authority across multiple independent private keys. They solve different problems.
In my testing, people often confuse the two. Which is right depends on whether you're protecting against loss (use Shamir) or protecting against unilateral theft (use multisig).
If your hardware wallet dies, SLIP‑39 shares let you rebuild the original recovery secret on a compatible device or recovery tool, provided you have the threshold number of shares and the correct passphrase (if used). Step-by-step restore recommendations:
Test this process before you need it. If the company behind a wallet disappears, you can still restore on any compatible open implementation—provided the spec is public (see company-failure-recovery).
Who SLIP‑39 is best for:
Who should look elsewhere:
In my experience, SLIP‑39 shines when you have clear physical-security controls and can commit to tested backup locations.
Q: Can I recover my crypto if the hardware wallet breaks?
A: Yes — if you have the required SLIP‑39 shares (and passphrase, if used). Test restoring to a blank wallet ahead of time. See device-broken and restore-recovery.
Q: What happens if the company behind my wallet goes bankrupt?
A: SLIP‑39 is an open specification; as long as you can find a compatible implementation to process the shares, you can recover. Keep copies of the spec and test tools offline. See company-failure-recovery.
Q: Is Bluetooth safe for backup setup?
A: Bluetooth is a convenience layer for some companion apps. Avoid transmitting seed material or shares over wireless links. Use wired or air-gapped methods where possible (see connectivity-usb-bluetooth-nfc and air-gapped).
Q: Can I use a BIP‑39 passphrase with SLIP‑39?
A: That depends on the implementation. Mixing methods without understanding how the passphrase is applied can render shares useless. Always consult device documentation and test a recovery.
Shamir backup (SLIP‑39) is a practical, cryptographically sound option for creating distributed backups of a single recovery secret. It trades setup complexity for redundancy and loss resilience. But it is not a replacement for multisig or for careful operational security.
If you want to learn more, start with these pages: seed-phrase-management, metal-backup-plates, and multisig-setup. In my testing, the single best habit is to test a full restore before placing funds into long-term storage. Do that, and you’ll avoid most of the common mistakes people make.
Want a guided how-to for a specific hardware wallet model? Check the model-specific setup guides in the collection (see ledger-models and model-compare).