SLIP39 Backup Recovery: What Enough Shares Cannot Prove

Funding: CypherpunkGuide may earn referral fees through linked buying guides. This article has no direct affiliate purchase links. No wallet vendor sponsored the experiment.

SLIP39 is a standard for encoding a secret backup as word-based shares. A passphrase is an additional secret string, separate from those shares, that can be required for the wallet you intend to recover.

Two recovery cards remain from a three-card backup. That can be enough for a 2-of-3 scheme. It still leaves questions: do the cards belong together, is another group required, and does opening the intended wallet require a passphrase?

On October 6, 2026, I ran 45 official test vectors, inputs supplied with known expected results, and 32 additional checks using public dummy data. All 77 matched their expected outcomes. That includes deliberate refusals and two cases that returned a different value without reporting a passphrase error. It is not a count of 77 successful wallet recoveries.

The experiment uses the SLIP39 reference implementation. It does not test a hardware wallet, locate bitcoin, or sign a transaction. For the broader distinction between receiving funds, signing, and restoring access, start with the self-custody checks.

Count complete groups, not just cards

#

A SLIP39 backup can require both a minimum number of shares within a group and a minimum number of complete groups. A share is one encoded part of the backup, usually written as words. A threshold is the number required at that level.

The SLIP39 specification defines this two-level arrangement. Our grouped test backup required two of three groups. The first two groups each required two of their three shares; the last group required its single share. Two cards from the first group completed only one group. They did not satisfy the whole backup.

All 15 minimal valid combinations in that test backup restored the expected value. The two incomplete examples were refused. In a separate, simple 2-of-3 test backup, each of the three possible pairs worked. Submitting one share twice did not create a second distinct share.

These shares reconstruct one underlying secret. They are not separate signing keys in a conventional Bitcoin multisig wallet. The multisig recovery experiment addresses that different problem. Neither method is automatically the right choice for every holder.

A correct share set does not check the passphrase

#

The SLIP39 design does not validate whether a passphrase is the one you intended. In our two deliberately wrong-passphrase cases, share recovery and decryption completed, but the recovered bytes differed from the expected public value.

The implementation first reconstructed the encrypted master secret, or EMS: the encrypted value represented by the shares. The passphrase was then used to derive the unencrypted result. Trezor’s firmware documentation likewise separates share recovery from passphrase-dependent derivation.

The difference matters when interpreting a reassuring completion message. In this experiment, successful processing alone was insufficient. We could detect the mismatch because the dummy value was known in advance. We did not derive addresses or inspect wallet balances. An empty wallet in a real recovery needs further investigation; this result alone does not identify its cause.

This is not a passphrase-search tool. The separate password-recovery article discusses a different class of problem.

A new backup can leave the old route open

#

Creating another backup of the same underlying secret can leave earlier recovery material usable. Our test recovered the same expected value from a prior single-share backup, a prior 2-of-3 backup, and a newly generated 2-of-3 backup.

Here, “prior” means generated earlier in our test. All three used the extendable format and the same identifier, 42. This is not a test of an older SLIP39 format or a device’s upgrade procedure.

Trezor’s upgrade guidance separately states that creating an additional backup for an eligible existing wallet does not invalidate the original. Its interface and eligibility conditions are product-specific. Our mathematical example does not test those conditions.

For privacy and access control, inventory earlier backup sets as well as the newest one. Additional shares should not be mistaken for revocation of material that has already leaked. This article is not an instruction to destroy a backup, reset a device, or move funds.

What the 77 checks established

#

The checks distinguish a matching result, a different result, and a refusal. The case-by-case results preserve all 77 observations.

The last two rows need care. We deliberately reused metadata to create the same opening words in independently split sets. That one mixture failed a consistency check; it does not establish the failure rate or behavior of every possible mixture. Opening words are not proof of the wallet’s identity.

The excess-input refusal is a constraint of this implementation’s recovery function. It expects a threshold-sized selection. It does not mean holding all three shares prevents recovery: each two-share subset already passed.

The reproduction package pins the official implementation, inputs, and results. It uses deterministic test randomness and public values only. Never use its shares for funds, or adapt it to accept your real recovery words. The upstream README explicitly warns that this implementation is not hardened for sensitive secrets. Running it offline does not turn it into a safe production recovery tool.

The official vectors were checked against their expected master-secret bytes; their BIP32 extended private keys were not tested. Device compatibility, address discovery, signing, and human recovery procedures remain outside this experiment.

Check the plan without collecting the secret

#

A useful recovery inventory records which conditions have been checked, without collecting the recovery words themselves. The blank checklist has status fields rather than spaces for shares, passphrases, people, or storage addresses.

Check the backup format and documented recovery compatibility; the required shares and groups; whether a separate passphrase is needed; and whether earlier backups remain valid. Also consider whether one incident could remove several storage locations at once. Keep even this inventory private where its contents could reveal your security arrangements.

Use your provider’s documented checking process for the relevant product. Do not erase working material to complete this checklist. A file-restoration check can establish that stored files are readable; it cannot establish that those files satisfy a particular wallet’s recovery conditions.

Key takeaways

#

Questions about the result

#

Can I combine cards because their first words match?

#

Matching opening words are only a preliminary metadata check. They do not replace complete share validation, successful reconstruction, and the conditions needed for your intended wallet. Our same-prefix mixture passed decoding and then failed the recovery consistency check.

Does the 3-share refusal mean I should discard one share?

#

No. It describes an input requirement of the tested recovery function. All three two-share combinations succeeded. It is not a reason to discard recovery material or assume that a device’s interface behaves the same way.

Does this establish an inheritance plan?

#

No. It checks public test data against one implementation. It does not establish who can find and use the materials, legal authority, or continuity after the owner’s death.

Sources and saved copies

#

The repository’s saved copy supports its warning about sensitive secrets. It is not a saved copy of the exact experiment commit. That version and its file hashes are included in the reproduction package.