Wallet Version Changes and Your Recovery Checklist
Seed version numbers signal which derivation a wallet should follow, so version changes belong in recovery planning. Here is how to read the Electrum seed design.
The useful answer: a wallet's version history can change how a seed phrase must be read, so your recovery checklist should record which software generation produced the seed and how the phrase encodes its derivation path. Electrum's Seed Version System documentation explains why. Starting with version 2.0, Electrum seed phrases include a version number, whose purpose is to indicate which derivation should be followed in order to derive private keys and addresses (c03). That is the single most checklist-relevant fact: the phrase itself is meant to carry a hint about how to turn it into keys.
What the version number does
Electrum derives its private keys and addresses from a seed phrase made of natural language words (c02). From version 2.0 onward, a version number is embedded so recovery software knows which derivation to follow (c03). The version number is obtained by looking at the first bits of a hash (c05), and the master private key and the version number are both obtained by hashes of the UTF8 normalized seed phrase (c04).
The version number also serves as an integrity check: in order to be correct, a seed phrase must produce a registered version number (c06). In practice, that means a phrase can be checked for consistency against the version scheme before anyone tries to restore funds. For a recovery checklist, that is a verification step, not merely a cosmetic detail.
Why older and newer designs differ
Early versions of Electrum, before 2.0, used a bidirectional encoding between seed phrase and entropy (c07). That type of encoding requires a fixed wordlist (c08). The consequence is stated plainly in the documentation: future versions of Electrum must ship with the exact same wordlist, in order to be able to read old seed phrases (c09).
The newer design was meant to remove that dependency. In order to eliminate the dependency on a fixed wordlist, the master private key and the version number are both obtained by hashes of the UTF8 normalized seed phrase (c04). So the shift from pre-2.0 to 2.0 and higher is not just a software update; it is a change in how a phrase relates to the keys behind it.
A comparison worth keeping on file
The same source draws a parallel with BIP39, which was introduced two years after Electrum (c10). BIP39 seeds include a checksum, in order to help users figure out typing errors (c11). But the documentation says BIP39 suffers the same shortcomings as early Electrum seed phrases (c12). Following a recommendation, BIP39 authors decided to derive keys and addresses in a way that does not depend on the wordlist (c13). Yet BIP39 still requires the wordlist in order to compute its checksum, which the document calls plainly inconsistent, and says defeats the purpose of that recommendation (c14).
| Design trait | Electrum 2.0 and higher | BIP39, as described |
|---|---|---|
| Version number in phrase | Yes (c03) | No (c17) |
| Integrity check | Registered version number (c06) | Checksum (c11) |
| Wordlist needed for checksum | Not for derivation (c04) | Yes, per the document (c14) |
| Per-language wordlists | Not described here | Proposed (c15) |
The document adds that the problem is exacerbated by the fact that BIP39 proposes to create one wordlist per language (c15), and that this threatens the portability of BIP39 seed phrases (c16). Because BIP39 seed phrases do not include a version number (c17), the document notes that software should always know how to generate keys and addresses (c18).
A worked example for your checklist
Hypothetical: suppose your notes say a phrase was created in an Electrum release before 2.0, while the software you now run is 2.0 or higher. Your checklist should flag two separate questions: which wordlist the older phrase depended on (c08, c09), and whether the phrase carries a registered version number (c06). A phrase from the newer line should resolve its version from the first bits of a hash (c05), so a mismatch is a signal to stop and re-read the record, not to improvise.
Hypothetical: if a phrase produces no registered version number when checked against the Electrum 2.0 and higher scheme (c06), treat that as a failed integrity check for that scheme and confirm the phrase belongs to the pre-2.0 line instead, which used a different encoding (c07). Setting a rule like this in advance turns a stressful moment into a two-branch decision.
Short recovery checklist
- Record the wallet family and the software generation that created the phrase, noting whether it was before 2.0 or 2.0 and higher (c01, c03).
- Record whether the phrase is described as carrying a version number (c03) or not (c17).
- Note the language and wordlist assumption for any phrase, since early Electrum encoding required a fixed wordlist (c08) and BIP39 proposes one wordlist per language (c15).
- Keep a written test that checks for a registered version number before restoring (c06).
- Store the rule for handling phrases without a version number, since software should always know how to generate keys and addresses (c18).
What the source does not say
The document does not state which specific version numbers are registered, nor how many exist. It does not describe a recovery procedure, a user interface, or any testing results. It does not say whether any particular wallet implements the scheme correctly, and it gives no guidance on storage media, passphrases, or how many copies to keep. It does not quantify how often wordlist mismatches cause failed restores. The statements above describe the seed version design as documented; they are not an assessment of any specific software release.
Sources
Informational only. Not financial, legal or investment advice. Check the primary sources listed above before you act on anything here.