Roughly 2.3 to 3.7 million bitcoin, worth hundreds of billions of dollars at current prices, sit in wallets nobody can open anymore. Chainalysis and Ledger Academy both point to the same root cause: a single lost or destroyed seed phrase. A River Financial study puts the damage from self-custody mismanagement alone at around 1.6 million BTC, more than the Mt. Gox and FTX collapses combined. A 2026 Oobit-based survey found that 35% of US crypto holders have lost access to a wallet at least once, and 31% of those people never got their funds back.

The pattern behind almost every one of those losses is the same: one 12 or 24-word phrase, written on one piece of paper, stored in one place. Lose it, and the funds are gone. Someone finds it, and the funds are also gone. Shamir Secret Sharing fixes that single point of failure by splitting a seed into multiple shares, so that no single share (and no single location) can recover or destroy the wallet on its own. This tutorial walks through the math, the tools, and a full 12-step setup using SLIP-39, the Shamir standard built by SatoshiLabs and shipped natively on current Trezor hardware.

Budget about 60 to 90 minutes for a first pass through the full walkthrough, most of it spent carefully transcribing and re-verifying shares rather than running code. You will need a spare afternoon, not a spare five minutes, because rushing the transcription and verification steps is exactly how backups fail years later when you actually need them.

Why a Single Seed Phrase Is a Single Point of Failure

A standard BIP-39 recovery phrase is convenient precisely because it is one artifact. Twelve or twenty-four words, drawn from a fixed 2048-word list, recreate your entire wallet. That convenience is also the flaw. Whoever holds the phrase holds the funds, full stop. Fireproof safes, steel plates, and safety deposit boxes reduce the odds of losing that one phrase, but they do not remove the underlying design problem: one artifact, one point of failure, no middle ground between “recoverable” and “gone.”

The numbers on the theft side are just as ugly as the loss side. TRM Labs attributed roughly 80% of the $2.1 billion in crypto stolen during the first half of 2025 to private-key exploits and front-end compromises. Scam Sniffer data cited by DeepStrike shows wallet-drainer phishing pulled in $494 million across more than 332,000 wallets in 2024, dropping to $83.85 million across 106,106 wallets in 2025 as more users adopted hardware wallets and better operational habits. Losses tied to the 2022 LastPass breach have separately topped $435 million, including roughly $150 million lost by Ripple co-founder Chris Larsen, all traced back to encrypted vaults that contained seed phrases.

Inheritance is the quieter half of the problem. Estate-planning analyses attribute a meaningful chunk of that 2.3 to 3.7 million lost BTC to owners who died without telling anyone where their seed phrase was, or how to use it. A single phrase in a drawer does nothing for an heir who does not know it exists. Shamir Secret Sharing addresses both failure modes at once: it survives the loss of some shares, and it lets you distribute recovery authority across people and places without giving any one of them full control.

Cold-storage statistics cited across recent industry reports put the picture in blunter terms: somewhere between 24% and 30% of crypto users report losing access to funds at least once, and an estimated 15% to 20% of all mined bitcoin sits dormant or lost, much of it tied back to a single point of recovery failure rather than a hack. None of that requires an attacker at all, just a fire, a move, a forgotten hiding spot, or a person who never told anyone else where the paper was kept.

What Is Shamir Secret Sharing? The Cryptography Behind SLIP-39

Shamir’s Secret Sharing (SSS) is a threshold cryptography scheme published by Adi Shamir in 1979, long before Bitcoin existed. The SLIP-39 specification adapts it specifically for backing up hierarchical deterministic wallets. According to the official specification maintained by SatoshiLabs, “Shamir’s secret-sharing (SSS) is a cryptographic mechanism describing how to split a secret into N unique parts, where any T of them are required to reconstruct the secret.” That threshold, written as T-of-N, is the entire point: you decide in advance how many shares exist and how many are needed to recover the wallet.

The math has a property most backup schemes lack: anything below the threshold reveals zero information about the original secret. Two shares out of a 3-of-5 scheme are not “40% of a seed phrase.” They are mathematically useless on their own. SatoshiLabs describes the underlying mechanism directly: “SSS splits a master secret into unique parts which can be distributed among participants.” Each part, called a share, is itself encoded as a mnemonic phrase, typically 20 words for 128-bit security or 33 words for 256-bit security, drawn from a dedicated 1024-word SLIP-39 wordlist that is separate from the standard BIP-39 list.

Trezor, the hardware wallet maker that authored the standard, frames it plainly in its own documentation: “SLIP-0039 describes a way to securely back up a secret value using Shamir’s Secret Sharing scheme.” Read the full SLIP-0039 documentation here. Each share also carries embedded metadata, including a group index, the threshold value, and a checksum, so a wallet or recovery tool can tell instantly whether shares belong together and how many more are needed. That metadata is what separates SLIP-39 from a home-brewed splitting scheme scrawled across index cards.

SLIP-39 vs BIP-39 vs SeedXOR: What Actually Changes

People often confuse SLIP-39 with SeedXOR, a simpler splitting trick supported on some hardware wallets. SeedXOR takes a seed and mathematically combines it with random data to produce multiple full-length BIP-39 phrases, all of which are needed to reconstruct the original. That is an N-of-N scheme: lose one part, and the wallet is gone forever, exactly the failure mode you were trying to escape. SLIP-39 supports genuine threshold recovery, where you can lose or expose some shares and still keep the wallet safe.

PropertyBIP-39SeedXORSLIP-39 (Shamir)
Recovery modelSingle phraseN-of-N (need all parts)T-of-N (need only threshold)
Wordlist size2048 words2048 words (BIP-39)1024 words (SLIP-39-specific)
Typical phrase length12 or 24 words12-24 words per part20 words (128-bit) or 33 words (256-bit)
Loses one part, still recoverable?No, that is the whole seedNoYes, up to N-minus-T parts
Leaks info below threshold?N/A, single secretPossible with poor implementationsZero information, provably
Native hardware supportAll major walletsA few models (Coldcard, Passport)Trezor Safe 7/5/3, Model T

The derivation path differs too. A BIP-39 mnemonic runs through PBKDF2-HMAC-SHA512 with 2048 iterations to produce a 512-bit seed before any keys get derived. SLIP-39 implementations typically feed the recovered 128 or 256-bit entropy directly into BIP-32/BIP-44 derivation, skipping that PBKDF2 step. Practically, that means a SLIP-39 share is not simply “a chunk of your BIP-39 phrase.” It is a different encoding of a related but distinct secret, and mixing the two formats in your notes is one of the fastest ways to lock yourself out. More on that in the pitfalls section below.

Prerequisites: Hardware, Software, and Versions You’ll Need

You do not need specialized hardware to follow this tutorial, though a hardware wallet with native SLIP-39 support makes the whole process safer. Here is what to gather before Step 1:

  • A computer you trust, ideally one you can temporarily air-gap (disconnect from the internet) while generating shares
  • Python 3.9 or newer installed and on your PATH
  • pip, or a virtual environment tool such as venv or Poetry
  • The shamir-mnemonic Python package (Trezor’s reference implementation of SLIP-0039), installing the latest version from PyPI rather than pinning an old number
  • Optional: a Trezor Model T, Trezor Safe 3, Trezor Safe 5, or Trezor Safe 7 running firmware 2.7.2 or newer, which support native Shamir Backup
  • 5+ sheets of paper or steel backup plates, one per share, plus a permanent marker
  • A wallet that can import SLIP-39 shares for recovery testing, such as Electrum, Sparrow Wallet, or BlueWallet

One hardware note worth flagging before you buy anything: Ledger, Coldcard, BitBox02, and Foundation Passport do not support SLIP-39 natively as of 2026. Keystone 3 Pro and Cypherock’s X1 Wallet use Shamir-style threshold schemes of their own, but they are not strictly SLIP-39 compatible, so shares generated on one device family will not import cleanly into another. If you already own a non-Trezor hardware wallet, you can still follow this tutorial using the software tools in Step 4 onward, generating shares independently of any single vendor’s firmware.

The 12-Step Walkthrough: Splitting a Bitcoin Seed With SLIP-39

Step 1: Decide what you are protecting against. Write down, honestly, the two failure modes you fear most: losing access (fire, theft of a single share, your own memory) or someone else gaining unauthorized access. A scheme tuned for disaster survival looks different from one tuned for theft resistance, and most people need a bit of both.

2-of-3 vs 3-of-5: Which Threshold Fits Your Holdings

Step 2: Pick your threshold scheme. Security guides converge on two default patterns. 2-of-3 is described as the minimal viable threshold: you tolerate losing one share, and an attacker needs to compromise two separate locations. 3-of-5 is the most common recommendation for larger holdings, tolerating two lost or compromised shares while forcing an attacker to breach three distinct locations. For a first setup, 2-of-3 is easier to manage. Move to 3-of-5 once your holdings justify the extra logistics.

Step 3: Prepare an air-gapped environment. Disconnect the machine you will use from Wi-Fi and any network cable. If you have a spare laptop, boot it from a live Linux USB instead of using your daily driver. This is the single most important operational step in the whole tutorial, since the entropy for your shares will pass through this machine’s memory.

Step 4: Install the Shamir-Mnemonic toolchain. On the air-gapped machine, install Trezor’s reference Python implementation of SLIP-0039:

python3 -m venv shamir-env
source shamir-env/bin/activate
pip3 install shamir-mnemonic[cli]
python3 -c "import shamir_mnemonic; print(shamir_mnemonic.__file__)"

You can find the source and documentation for this library on its GitHub repository and on PyPI. Always install the latest published release rather than an old pinned version, since the SLIP-39 reference tooling is actively maintained.

Step 5: Generate 128 bits (or 256 bits) of fresh entropy. Do not reuse an existing BIP-39 phrase’s entropy casually here. Generate new master secret entropy specifically for this Shamir setup, or convert from an existing wallet’s seed deliberately and carefully. For a new wallet, generate randomness directly:

import secrets

# 128-bit master secret (use 32 bytes for 256-bit / higher security)
master_secret = secrets.token_bytes(16)
print(master_secret.hex())

Step 6: Split the secret into shares using your chosen threshold. This example creates a single group with a 3-of-5 threshold, the most commonly recommended configuration for meaningful holdings:

from shamir_mnemonic import generate_mnemonics

# One group, 3-of-5 threshold, group threshold 1-of-1
groups = generate_mnemonics(
    group_threshold=1,
    groups=[(3, 5)],
    master_secret=master_secret,
    passphrase=b"",
    iteration_exponent=1,
)

for i, share in enumerate(groups[0], start=1):
    print(f"Share {i}: {share}")

Step 7: Write down each share on its own physical medium. Do not photograph them, do not paste them into a notes app, and do not email them to yourself “just for now.” Each 20-word share should go on its own steel plate or paper, clearly labeled with a share number but not labeled in a way that reveals the threshold to anyone who finds one plate (“Share 2 of 5” is fine on the back where it is not casually visible, but avoid writing “Bitcoin backup” on the front).

Step 8: Verify each share was transcribed correctly. Typos in a 20-word share are the single most common reason recovery fails later. Re-enter each share from your written copy and confirm it matches the generated output exactly, character for character, before you clear the master secret from memory.

Step 9: Test recovery immediately, before you distribute anything. Combine only your threshold number of shares (not all five) to confirm the math works and you recover the original secret:

from shamir_mnemonic import combine_mnemonics

# Use exactly 3 of the 5 shares generated above
test_shares = [groups[0][0], groups[0][2], groups[0][4]]
recovered = combine_mnemonics(test_shares, passphrase=b"")

assert recovered == master_secret
print("Recovery verified: master secret matches.")

Step 10: Import the recovered secret into your spending wallet. If you generated a fresh master secret, derive your actual receive addresses from it in Electrum, Sparrow, or your hardware wallet before moving any funds. If you split an existing wallet’s seed, confirm the derived addresses match the wallet you already use.

Step 11: Distribute the shares to their storage locations. This step is covered in detail further down, but the short version: no two shares in the same building, and no single trusted person holds more than one share unless you have a specific reason.

Step 12: Wipe the air-gapped environment. Once shares are written, verified, and distributed, securely erase the virtual environment and any temporary files, and if you booted from a live USB, simply do not save state. Reboot into your normal, networked machine only after the master secret and full plaintext shares no longer exist anywhere digital.

Setting Up Native Shamir Backup on a Trezor Hardware Wallet

If you own current Trezor hardware, you can skip most of the manual Python work above and let the device generate and display shares directly on its trusted screen, which is generally the safer path for anyone not comfortable auditing Python code themselves. Trezor’s SLIP-39 support currently spans the Model T, Safe 3, Safe 5, and Safe 7, running firmware 2.7.2 or newer (current core firmware as of publication is in the 2.12.x line). Devices with older firmware do not support Shamir Backup and need an update first.

During initial setup, or when creating a new wallet on the device, choose “Shamir Backup” instead of the default single-phrase option when prompted (Trezor Safe 3 units manufactured from June 2024 onward actually default to SLIP-39 single-share backup rather than BIP-39). Set your total share count and threshold on the device screen, then transcribe each 20-word share as the device displays it, one at a time, confirming each word on-screen before moving to the next share. The device never displays all shares simultaneously, which limits exposure if someone is looking over your shoulder during setup. Trezor Suite documents this flow directly if you want screenshots alongside your setup: Trezor’s SLIP-0039 documentation.

Verifying Your Shares Actually Work Before You Rely on Them

A backup you have never tested is a hope, not a backup. Before you consider the job done, run a full dry-run recovery on a different, wiped device or a fresh air-gapped environment, using only your threshold number of shares. On a Trezor device, this means using the “Recovery” flow and entering exactly the threshold count of shares, then confirming the recovered wallet’s public receive address matches what you expect. In software, re-run the combine_mnemonics call shown in Step 9 with a fresh Python environment weeks or months after generation, not immediately after, to catch any transcription drift from storage or memory.

Test with the minimum threshold, not all shares. If your scheme is 3-of-5 and you only ever test recovery with all five shares present, you have not actually proven the threshold property works, and a future recovery attempt with exactly three shares could fail on an edge case you never exercised.

Building a Complete Shamir Backup Kit: A Working Project

Pulling the pieces above together, here is a small, self-contained project you can keep on an air-gapped machine or a USB drive dedicated to backup operations. It wraps generation, verification, and a printable inheritance record into one script.

#!/usr/bin/env python3
"""shamir_kit.py -- generate, verify, and document a SLIP-39 backup."""
import secrets
import sys
from shamir_mnemonic import generate_mnemonics, combine_mnemonics

def build_backup(group_threshold_shares=(3, 5), bits=128):
    entropy_bytes = bits // 8
    master_secret = secrets.token_bytes(entropy_bytes)
    threshold, total = group_threshold_shares

    groups = generate_mnemonics(
        group_threshold=1,
        groups=[(threshold, total)],
        master_secret=master_secret,
        passphrase=b"",
        iteration_exponent=1,
    )
    shares = groups[0]

    # Self-test: recover using only the threshold count of shares
    check = combine_mnemonics(shares[:threshold], passphrase=b"")
    if check != master_secret:
        print("FATAL: self-test failed, do not use these shares.")
        sys.exit(1)

    print(f"Generated {total} shares, threshold {threshold}-of-{total}.")
    for idx, share in enumerate(shares, start=1):
        print(f"\n--- SHARE {idx} of {total} ---")
        print(share)

    print("\nSelf-test passed: threshold shares reconstruct the secret.")
    print("Write each share on separate physical media before closing this session.")

if __name__ == "__main__":
    build_backup(group_threshold_shares=(3, 5), bits=128)

Pair the script with a plain-text inheritance record, stored separately from any single share and given to an attorney or executor, describing only the scheme and locations, never the words themselves:

INHERITANCE INSTRUCTIONS (no seed words included)
Scheme: SLIP-39 Shamir Backup, 3-of-5 threshold
Share 1: Home safe, [address]
Share 2: Bank safety deposit box, [institution, branch]
Share 3: Attorney [name, firm], sealed envelope
Share 4: Trusted relative [name], sealed envelope
Share 5: Second bank safety deposit box, [institution, branch]
Recovery tool: shamir-mnemonic (pip3 install shamir-mnemonic[cli])
              or Trezor Safe 5 "Recover Wallet" flow
Any 3 of the 5 shares above reconstruct full wallet access.

That combination, a tested generation script plus a location-only inheritance note, closes the gap that estate-planning commentary blames for “tens of millions of dollars” in unrecovered crypto inheritance. It also mirrors what industry products are now shipping: Block’s Bitkey added its own inheritance mechanism in 2025, an early sign that mainstream wallet makers now treat unplanned crypto inheritance as a real, common failure rather than an edge case.

SLIP-39 Tools Compared: CLI, GUI, and Wallet Support

The Python code shown above covers the core workflow, but it is not the only option, and the right tool depends on how comfortable you are with a terminal versus a graphical interface. A handful of open-source projects now implement SLIP-39 independently of any single hardware vendor, which matters if you want to verify your backup with more than one piece of software before trusting it with real funds.

ToolInterfaceBest for
shamir-mnemonic (Trezor reference)Python library / CLIScripting, automation, auditing the reference implementation directly
python-slip39 (slip39 package)CLI and optional GUIUsers who want a graphical share-generation flow without a hardware wallet
Ian Coleman’s bip39 tool (offline HTML)Web page, run fully offlineOne-off checks and cross-referencing shares generated elsewhere
Trezor Suite (Model T / Safe 3 / Safe 5 / Safe 7)Hardware device screenNon-technical users who want generation to happen entirely on a trusted screen
Electrum, Sparrow, BlueWalletDesktop / mobile walletImporting recovered shares to check derived addresses and spend funds

Ian Coleman’s well-known BIP-39 tool, hosted on GitHub, also ships a SLIP-39 mode. Download the standalone HTML file from the project’s releases and open it with your browser fully offline, never load the hosted web version when you are handling a real master secret. It is a useful cross-check: generate shares with the Python library, then verify the same master secret reproduces the same shares (given identical entropy and settings) using a second, independently written implementation. Two tools agreeing on the output gives you more confidence than trusting a single codebase blindly, especially if you are new to auditing cryptographic code yourself.

On the wallet-import side, Electrum, Sparrow Wallet, and BlueWallet can all import SLIP-39 shares directly, letting you check that recovered addresses match a wallet you already use without touching a hardware device at all. This is a convenient way to run the dry-run recovery drill described earlier in a disposable, watch-only context before you ever expose a real spending key.

Common Pitfalls When Splitting a Seed Phrase

  • Mixing BIP-39 and SLIP-39 wordlists. The two standards use different word lists (2048 words vs 1024 words) and are not interchangeable. Writing a SLIP-39 share and later trying to import it as a BIP-39 phrase, or vice versa, will simply fail or, worse, generate a wallet with no funds in it.
  • Testing recovery with more than the threshold. Combining all five shares of a 3-of-5 scheme “just to check” tells you nothing about whether the actual threshold count works.
  • Storing two shares in the same location “for convenience.” A single house fire, flood, or burglary should never be able to compromise more than one share.
  • Giving one trusted person multiple shares. This silently converts your 3-of-5 scheme into something closer to 2-of-3, and that person alone may now hold enough shares to move funds.
  • Skipping the transcription check in Step 8. A single mistyped word in a 20-word share renders that share useless, and you often will not discover it until you desperately need it.
  • Generating shares on a networked machine. Entropy and intermediate secrets pass through system memory, and malware or a compromised browser extension is a realistic threat vector during generation.

Troubleshooting Shamir Backup and Recovery Problems

Even a well-planned Shamir setup runs into friction. Here are the issues that come up most often, and how to resolve each one.

  • “combine_mnemonics raises a checksum error.” Almost always a transcription typo. Re-enter the share character by character against your written copy, paying close attention to similar-looking SLIP-39 words.
  • “My hardware wallet doesn’t offer a Shamir Backup option.” Confirm firmware is 2.7.2 or newer on a Trezor Model T, Safe 3, Safe 5, or Safe 7. Older firmware, or non-Trezor devices such as Ledger, Coldcard, or BitBox02, do not expose this feature natively.
  • “I have three shares but recovery still fails.” Check that all three shares belong to the same group and the same generation session. Shares from two different Shamir setups will not combine into anything meaningful.
  • “pip install shamir-mnemonic[cli] fails on my system.” Confirm Python 3.9+ is active in your virtual environment and that pip itself is current (pip3 install --upgrade pip) before retrying.
  • “Electrum won’t import my SLIP-39 shares.” Confirm you are entering shares in the wallet’s SLIP-39 import flow specifically, not the standard BIP-39 seed field. The two entry points are separate in most wallets that support both formats.
  • “I forgot which threshold I used.” Each SLIP-39 share encodes its own group and threshold metadata in the words themselves, so entering just one correct share into recovery software will usually tell you how many total are needed, without needing to guess.
  • “One of my trusted share-holders is unreachable.” This is exactly why the threshold should be less than the total share count. A 3-of-5 scheme survives one unreachable or lost share without issue. If you set N equal to your threshold (an N-of-N scheme), you have effectively rebuilt the single-point-of-failure problem you started with.
  • “The derived addresses after recovery don’t match my old wallet.” Double-check the derivation path and passphrase used during generation. An empty passphrase (the default in the code above) must stay empty during recovery. A passphrase used at generation time must be re-entered identically during recovery, since SLIP-39 treats the passphrase as part of the secret derivation.
  • “generate_mnemonics throws a ValueError on group_threshold.” For a single-group setup, group_threshold must be 1 and the groups list should contain exactly one (threshold, total) tuple. Multi-group setups require more careful configuration and are worth testing extensively before real funds are involved.

Choosing a Threshold Scheme for Your Holdings

There is no universally correct threshold, only a tradeoff between convenience and resilience that should track how much you actually hold and how many trusted parties you have access to.

SchemeTolerates losingAttacker needs to compromiseBest suited for
2-of-31 share2 locationsIndividuals with moderate holdings, first-time setup
2-of-42 shares2 locationsSimple family setups wanting extra redundancy
3-of-52 shares3 locationsLarger personal holdings, the most common recommendation
Grouped thresholds (e.g. founders + counsel + board)Varies by groupMultiple independent constituenciesCorporate treasuries and multi-party custody

For most individual holders, 2-of-3 is the pragmatic starting point: enough redundancy to survive one lost or destroyed share, without the logistics of managing five separate storage locations. Move to 3-of-5 once the value at stake justifies the extra coordination, and reserve grouped, multi-constituency schemes for organizational treasuries where no single department should hold unilateral recovery power.

Where to Physically Store Each Share

Security guides consistently recommend a minimum of two geographically separate physical locations for any seed backup, and Shamir shares raise that bar further since the whole point is resilience against a single localized event. A workable 2-of-3 layout: one share at home in a fireproof safe stamped onto a steel plate, one share in a bank safety deposit box at a different institution, and one share held by a trusted relative or attorney in a different city. For a 3-of-5 setup, extend that pattern across five distinct locations, and try to keep at least one storage point roughly 100 miles or more from your primary residence, far enough that a regional disaster such as a wildfire or hurricane cannot plausibly reach two locations at once.

Steel plates, not paper, should hold any share you expect to survive years of storage. Paper degrades, and house fires routinely reach temperatures well past what paper survives, while stamped steel plates are rated to survive far higher heat. This matters more for Shamir shares than a single BIP-39 phrase precisely because losing more shares than your threshold allows defeats the entire scheme.

Advanced Tips: Group Thresholds and Combining Shamir With Multisig

Once the basic 12-step flow feels routine, two more advanced patterns are worth knowing.

Combining Shamir Backup With Multisig

SLIP-39 protects the backup of a single key. A multisig wallet, by contrast, requires multiple independent keys to sign a transaction in the first place. The two are not competitors. They solve different layers of the same problem, and pairing them gives you the strongest practical setup available to an individual. A common pattern is a 2-of-3 multisig wallet where each of the three signing keys is separately backed up with its own 2-of-3 Shamir scheme, meaning an attacker would need to reconstruct multiple independent keys, each itself protected by a threshold backup, to move funds. This adds real operational complexity, so it is best reserved for holdings large enough to justify the overhead. Readers building a full self-custody setup from scratch may want to start with our self-custody crypto wallet setup walkthrough before layering Shamir and multisig on top.

Grouped thresholds go a step further for organizations. SLIP-39 natively supports configurations such as “any 2 of 3 constituencies, where constituency A requires 2-of-3 internal shares, constituency B requires 1-of-1, and constituency C requires 3-of-5.” That flexibility exists mainly for corporate treasuries and DAOs distributing recovery authority across founders, legal counsel, and a board, and it is generally overkill for personal holdings, where a flat 2-of-3 or 3-of-5 scheme is easier to manage correctly.

Whichever scheme you land on, practice the recovery flow with a small, disposable test wallet before you ever apply it to real funds, and repeat that drill periodically. Historical research on threshold signatures, discussed at the Stanford Blockchain Conference, opens with a line worth keeping in mind for anyone building on this cryptography: “The first secret sharing scheme was introduced by Shamir and it’s called Shamir’s secret sharing scheme.” That foundation predates Bitcoin by decades and has held up because the underlying math is simple enough to verify by hand if needed. You can review that full talk transcript at Bitcoin Transcripts. For readers who have not yet hardened the basics, our guides on hardware wallet security and cold storage setup cover the foundational layer this tutorial builds on, and our quantum-proof Bitcoin wallet guide is worth reading if you are planning a backup meant to last decades. See also the broader cryptocurrency coverage on this site, and our companion piece on offline seed phrase backup for the non-Shamir baseline this technique improves on.

Frequently Asked Questions

Is Shamir Secret Sharing the same as a multisig wallet?
No. Multisig requires multiple independent keys to sign a single transaction, enforced by the wallet software or script itself. Shamir Secret Sharing splits the backup of one key into multiple shares. They can be combined, but they solve different problems.

Can I convert an existing BIP-39 seed phrase into SLIP-39 shares?
Yes, using tools such as the python-shamir-bip39 fork or a Trezor device’s wallet recovery and re-backup flow, though the process treats your existing entropy as the master secret going into a new Shamir split. Test the recovered wallet address matches your original wallet before relying on it.

How many words does a SLIP-39 share contain?
20 words for 128-bit security, or 33 words for 256-bit security, drawn from a dedicated 1024-word SLIP-39 wordlist that differs from the standard BIP-39 list.

Which hardware wallets support SLIP-39 natively in 2026?
Trezor Model T, Trezor Safe 3, Trezor Safe 5, and Trezor Safe 7, running firmware 2.7.2 or newer. Ledger, Coldcard, BitBox02, and Foundation Passport do not support SLIP-39 natively, though Keystone 3 Pro and Cypherock’s X1 Wallet offer their own Shamir-style alternatives.

What happens if I lose more shares than my threshold allows?
The wallet becomes permanently unrecoverable, the same outcome as losing a single BIP-39 phrase. This is why the threshold should always be set meaningfully below the total share count, never equal to it.

Can someone with two shares of a 3-of-5 scheme recover any part of my wallet?
No. Shamir’s Secret Sharing is designed so that fewer than the threshold number of shares reveal zero information about the underlying secret, a property that is mathematically proven rather than merely obfuscated.

Do I need a passphrase in addition to Shamir shares?
It is optional and adds an extra layer, but it also adds a single point of failure if you forget it or fail to record it as carefully as the shares themselves. Most individual users are better served by a well-distributed threshold scheme than by adding a passphrase on top of it.

Is SLIP-39 open source and independently auditable?
Yes. The specification is published on GitHub by SatoshiLabs, and the reference Python implementation, shamir-mnemonic, is open source and available on PyPI for anyone to inspect or audit before trusting it with real funds.