SLIP-39

For a BIP 32 wallet backup, the master secret is its input seed, not its extended private root. The encrypted master secret (EMS) is created first, then split into shares. Calculations use GF(256) byte by byte; the specification stores the secret at f(255) and, for thresholds of at least 2, a verification digest at f(254). [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes] [BIP 32 — Hierarchical Deterministic Wallets]

Each required group's member threshold must first be met, followed by the group threshold. Example: 2 of 3 groups, each with 2 of 3 members. Two shares from A and two from B suffice; three from A and one from B do not, despite also being four. A basic 2-of-3 scheme uses one group. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes]

The wordlist has 1024 English words and is not translated with the interface. A 128-bit secret produces 20-word shares, a 256-bit secret 33-word shares. A share also contains an identifier, extendable flag, iteration exponent, indices and thresholds. Combination checks matching metadata and unique member indices; two copies of one share are not two members. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes]

The last three words form RS1024, which guarantees detection of errors affecting at most three words. They establish neither share provenance nor holder authorization; the specification recommends against automatic correction. A reconstruction digest helps detect an incorrect set. Its 32-bit check is why the ideal claim of zero below-threshold leakage should not be applied to SLIP-39 without qualification. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes]

Encryption uses four Feistel rounds with PBKDF2-HMAC-SHA256, each with 2500×2^e iterations. The specification permits printable ASCII 32–126 and uses an empty string when no passphrase is supplied. A correct passphrase cannot be directly verified: another produces another master secret. Valid shares therefore do not confirm recovery of the intended wallet; verify its known addresses. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes]

BIP 39 has a different wordlist, checksum and phrase-to-seed conversion. Splitting its words across papers creates neither SLIP-39 nor its threshold protection. Preserving the same wallet during migration would require preserving the correct BIP 32 seed and derivation context; merely recoding the original entropy into different words does not guarantee this. Verify the particular supported procedure. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes] [BIP 39 — Mnemonic code for generating deterministic keys]

An extendable flag of 1 omits the identifier from the encryption salt. This permits resharing the same EMS with a new identifier without knowing the passphrase. Trezor describes extending a compatible single-share backup into multiple shares. A new set does not invalidate the old one: anyone holding a sufficient original combination can still recover the same secret. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes] [Trezor — Multi-share Backup]

SLIP-39 reconstructs one secret during recovery; it creates neither Multisig nor on-chain approval for every transaction. Distribution must limit both correlated loss and an attacker acquiring a sufficient combination. Test recovery on a trusted device, preserve the passphrase and wallet context, and verify compatibility using the reference implementation and test vectors. Share count alone is insufficient. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes] [Trezor — python-shamir-mnemonic reference implementation]