Canonical scientific claim: More words cannot repair weak generation, prevent backup theft or loss, protect against a compromised signer, or preserve forgotten recovery details; each requires a control aimed at that failure.
A longer backup only makes guessing harder. It does not stop someone from copying it, keep it safe from fire, or help you remember a missing passphrase.
Safety note: Do not test a real backup in a webpage, split it with an improvised scheme, or migrate funds solely from this educational comparison.
Once a seed is too large to guess, most wallet failures take a shorter route.
Match the control to the failure
| Failure | Do more seed words solve it? | What kind of control addresses it? |
|---|---|---|
| Someone photographs the complete backup | No | Keep the backup private; consider a well-managed passphrase or distributed signing policy |
| The only backup burns or disappears | No | Independent, durable backup copies |
| The generator had only a small hidden state | No | A defensible entropy source and generation process |
| A signing device is malicious | Usually no | Independent verification or independently controlled signers |
| The passphrase is forgotten or mistyped | No | An exact, tested recovery plan |
| Recovery software uses another format or path | No | Preserve wallet format and policy metadata |
A passphrase is not a checksum
BIP39 applies UTF-8 NFKD normalization and derives a different wallet for every distinct normalized passphrase. A case change or added space does not produce an error message; it produces another valid wallet that will usually appear empty. Two Unicode spellings that normalize to the same text are the same BIP39 input.
A passphrase can help when the words are exposed but the passphrase remains unknown. At that moment, the passphrase’s guessability and recoverability become the important limits. Calling it a “25th word” hides this tradeoff: it can be any supported string, it is not part of the mnemonic checksum, and losing it can lose the wallet.
Backup distribution is a different problem
SLIP39 uses threshold mnemonic shares so that a chosen number of shares can reconstruct a master secret. It is mainly a replacement for BIP39 and is largely incompatible with it. It changes who must cooperate and how recovery survives missing shares; it does not add uncertainty to an existing BIP39 phrase.
Improvising by cutting an ordinary phrase into pieces is not the same as a reviewed threshold scheme. It can weaken confidentiality for anyone who finds one piece while making recovery fail when another piece disappears.
Convenience can concentrate risk
BIP85 derives separate entropy outputs from one BIP32 root. That can reduce the number of independent backups, but every derived wallet still depends on the root. Simpler inventory and larger blast radius arrive together.
BIP93 codex32 is another approach to checksummed and threshold-aware BIP32 seeds. Its status is draft, so it belongs in advanced context rather than a default setup.
The Plenty question is not “How many mechanisms can fit?” It is “Which failure does each mechanism remove, and can the complete recovery still be performed years later?”
Evidence reviewed 2026-08-06
- BIP 39 — Mnemonic code for generating deterministic keysprimary specification · deployed
- BIP 32 — Hierarchical Deterministic Walletsprimary specification · deployed
- SLIP 39 — Shamir's Secret-Sharing for Mnemonic Codesprimary specification · final
- BIP 85 — Deterministic Entropy From BIP32 Keychainsprimary specification · deployed
- BIP 93 — codex32: Checksummed SSSS-aware BIP32 seedsdraft specification · draft