The complete guide to Electrum wallet recovery

Electrum has been around since November 2011 — which makes it ancient by crypto standards. That longevity is both a blessing and a curse for recovery. A blessing because the wallet format is well-documented and the codebase is open source Python you can actually read. A curse because fifteen years of version changes means the wallet file sitting on someone’s hard drive could be in any one of half a dozen formats, each with different encryption schemes, derivation paths, and seed types. I’ve recovered Electrum wallets dating back to 2012, and every era has its own particular headaches.

This guide covers the full technical landscape of Electrum wallet recovery – from the internal structure of wallet files, through the encryption mechanisms across versions, to the derivation path nightmare that makes “my balance shows zero” the most common support request in Bitcoin.

How Electrum stores your keys

Electrum stores your wallet as a single, self-contained file. By default it’s called default_wallet (no extension), and it lives in a predictable location based on your OS:

Windows: C:\Users\<USER>\AppData\Roaming\Electrum\wallets\

macOS: ~/Library/Application Support/Electrum/wallets/

Linux: ~/.electrum/wallets/

The wallet file is JSON – human-readable, structured, and surprisingly clean. Open an unencrypted wallet in a text editor and you’ll see the entire data model: keystores, addresses, transaction history, labels, contacts, everything. The keystore object is the heart of recovery.


The seed field there – if the wallet is unencrypted or you can decrypt it, you have everything you need. The xprv (extended private key) can derive every child key the wallet has ever used. The seed_type tells you which derivation scheme was used, and derivation shows the root path.

For older wallets (pre-2.0), the structure is different. Instead of bip32, you’ll see type: "old" with mpk (master public key) fields. These use Electrum’s original proprietary key derivation, which predates both BIP32 and BIP39. More on that below.

Wallet files that contain imported private keys (not derived from a seed) use type: "imported" in the keystore, and those keys are stored directly. These wallets cannot be recovered from a seed phrase – the wallet file itself is your only backup. Lose it, and those keys are gone.

The two layers of Electrum encryption

Electrum has two independent encryption layers, and mixing them up is one of the most common recovery mistakes I encounter.

Layer 1: Keystore encryption (private keys and seed)

Your private keys and seed phrase are encrypted using AES-256-CBC. The encryption key is derived by running your password through two rounds of SHA-256 – that’s it. Not PBKDF2 with hundreds of thousands of iterations like MetaMask or others. Not scrypt. Just SHA256(SHA256(password)). This is why Electrum wallets are dramatically faster to brute-force than virtually any other modern wallet. A hashcat benchmark on even modest GPU hardware can test hundreds of thousands of password candidates per second against an Electrum wallet.

This layer protects the seed and private keys within the wallet file. When you enter your password to sign a transaction, Electrum briefly decrypts the private keys in memory, signs, and then discards the decrypted keys. The wallet file on disk always keeps the keys encrypted.

Layer 2: Whole-file encryption (ECIES)

Since version 2.8 (released around 2016), Electrum enables whole-file encryption by default. This uses Elliptic Curve Integrated Encryption Scheme (ECIES) – asymmetric encryption where the wallet file itself is encrypted using a public key derived from your password. The encrypted file looks like binary gibberish rather than JSON, and you need the password just to open it.

The critical difference: when whole-file encryption is active, the wallet won’t reveal any structure without the correct password. You can’t peek inside to see addresses, transactions, or even the wallet type. The entire JSON payload is wrapped in ECIES. When whole-file encryption is off (or wasn’t available in older versions), the JSON is readable but the xprv and seed fields contain AES-encrypted ciphertext.

This distinction matters for recovery because it changes your attack surface. With only keystore encryption, you can still identify the wallet type, see addresses, and confirm you have the right file before attempting brute-force. With whole-file encryption, you’re flying blind until you crack the password.

Electrum’s seed system – not BIP39, and that matters enormously

This is where most recovery headaches begin. Electrum uses its own proprietary seed format that is explicitly not BIP39-compatible. If someone tries to import an Electrum seed into a BIP39-only wallet (Exodus, Trust Wallet, most hardware wallets), it will either be rejected outright or generate completely wrong addresses.

The difference is technical but important. BIP39 takes your mnemonic words, maps them back to entropy using a fixed wordlist, adds a checksum, and then runs PBKDF2 with the passphrase “mnemonic” + optional extension word for 2048 iterations using HMAC-SHA512. Electrum 2.0+ does something superficially similar but critically different: it runs PBKDF2 for 2048 iterations using the passphrase “electrum” + optional extension word. Same iteration count, same HMAC-SHA512, completely different salt string. The resulting master key is entirely different even with the same 12 words.

There was also a bug in older Electrum versions (around issue #4566) related to Unicode normalization of the passphrase – specifically, Electrum would aggressively strip whitespace from BIP39 passphrases, including removing one space from two consecutive spaces. If someone set a passphrase with unusual spacing, this bug could make their wallet unrecoverable on newer versions that fixed the normalization.

Electrum seeds also embed a version number in the seed itself. The version is derived by hashing the seed phrase and checking if the first bits match a known prefix. This version indicates which derivation scheme to use:

• Seed version 01 — Standard wallet (legacy, pre-segwit)
• Seed version 100 — Segwit wallet (native segwit, bech32)
• Seed version 101 — 2FA wallet (with TrustedCoin cosigner)
• Seed version 102 — Segwit multisig

This is actually clever design – it eliminates the “which derivation path do I use?” guessing game that plagues BIP39. But it means Electrum seeds are a walled garden. They only work in Electrum (or software that explicitly supports the Electrum seed format, like Ian Coleman’s BIP39 tool which has an Electrum mode).

The three seed eras

Pre-2.0 seeds (Electrum 1.x, “old” format): These used a bidirectional encoding – the seed phrase could be converted back to a specific entropy value and vice versa. This required an exact, fixed wordlist. The derivation was Electrum’s own scheme (not BIP32), using paths like m/0/k for receiving addresses and m/1/k for change addresses. These wallets are identifiable by "seed_type": "old" in the wallet file. They’re rare now but I still see them from people who set up Bitcoin wallets in 2012-2013 and forgot about them.

Electrum 2.x seeds (2014+): Introduced BIP32 HD wallet structure with the Electrum seed version system. Standard wallets use derivation path m/0h with receiving addresses at m/0h/0/k and change at m/0h/1/k. Note this is NOT the BIP44 path (m/44'/0'/0'). This non-standard derivation is a constant source of confusion.

Electrum 3.x+ segwit seeds: When segwit support arrived, Electrum added new seed versions for native segwit wallets. These use derivation path m/0h as well – same root path, but the seed version prefix ensures the wallet knows to generate bech32 (bc1…) addresses instead of legacy (1…) addresses.

Derivation paths and the “empty wallet” problem

Derivation paths are the single most common reason people restore a seed and see zero balance. Every path component matters, and a single wrong number means completely different keys and addresses.

Here’s the derivation path landscape for Electrum:

Electrum native seeds (not BIP39):

• Legacy standard wallet: m/0h → receiving at m/0h/0/k, change at m/0h/1/k
• Segwit standard wallet: m/0h → receiving at m/0h/0/k, change at m/0h/1/k (same path, different address encoding)
• Old Electrum (pre-2.0): m/k for receiving, m/k with a separate key sequence for change

BIP39 seeds imported into Electrum:

• Legacy (P2PKH, addresses starting with 1): m/44'/0'/0'
• Wrapped segwit (P2SH-P2WPKH, addresses starting with 3): m/49'/0'/0'
• Native segwit (P2WPKH, addresses starting with bc1): m/84'/0'/0'
• Taproot (P2TR, addresses starting with bc1p): m/86'/0'/0'

The trap: if someone created a wallet in Trezor Suite (which uses BIP39 and m/84'/0'/0' for native segwit), then tries to restore in Electrum using an Electrum-type seed, the paths won’t match. Even if they correctly select “BIP39 seed” in Electrum’s options, they still need to choose the right script type (legacy vs. segwit vs. native segwit) and verify the derivation path matches the originating wallet.

And here’s where it gets really ugly: Electrum allows you to import BIP39 seeds but does NOT generate them. When creating a new wallet, Electrum always produces its own seed format. The BIP39 import option exists solely for cross-wallet compatibility. But Electrum will happily accept an invalid BIP39 seed (one with a wrong checksum word) – it displays a small “checksum failed” warning but doesn’t prevent you from proceeding. This has led to people creating wallets with misspelled seeds that look functional until they try to restore.

Practical fix for the empty wallet problem: If you’re restoring a seed and see zero balance, systematically try different combinations. First, determine if the seed is Electrum format or BIP39. If Electrum format, the derivation is automatic. If BIP39, you need to try each script type: native segwit first (most common for recent wallets), then wrapped segwit, then legacy. Electrum 4.x includes a “Detect Existing Accounts” button during BIP39 restoration that queries the server for transaction history across common derivation paths. Use it.

If the wallet had multiple accounts (common with hardware wallets using Trezor Suite), remember that Electrum doesn’t support multiple accounts per wallet file. You need to create a separate wallet for each account, incrementing the account index in the derivation path: m/84'/0'/0' for account 1, m/84'/0'/1' for account 2, and so on.

The gap limit and why your funds might be invisible

Even with the correct seed and derivation path, funds can appear missing because of the gap limit. Electrum generates addresses sequentially and stops scanning when it encounters 20 consecutive unused addresses (the default gap limit). If someone used address index 0-5, then jumped to index 30 (perhaps by using an API or another wallet), Electrum won’t discover addresses beyond index 25 because it hits the gap limit and stops looking.

The fix is straightforward: in Electrum’s console (View → Show Console), run:

wallet.change_gap_limit(50)

Or whatever number you need. Then trigger a resync. For extreme cases, I’ve set gap limits to 200+ for wallets that were used programmatically (e-commerce platforms, donation pages).

Version history and what breaks between upgrades

Electrum version upgrades have historically been destructive to backward compatibility. Once you open a wallet file in a newer version, it often upgrades the internal format, and older versions cannot read the upgraded file. This is explicitly documented but widely ignored.

The critical version transitions:

1.x → 2.0 (2014): Complete wallet format change. BIP32 HD wallet support replaced the old proprietary derivation. The upgrade process regenerates all addresses. Electrum 1.x cannot read 2.x wallet files, period. If someone needs to open a v1 wallet, they need to install Electrum 1.9.8 specifically.

2.x → 3.0 (2017): New server protocol, segwit support added. Wallet files got a new format revision. Segwit seed type introduced. The internal seed_version field in the wallet JSON tracks this — if you see seed_version: 13 or 14, it’s a v3-era wallet.

3.x → 4.0 (2020): Lightning Network support, PSBTs, significant internal restructuring. Lightning channels are stored in the wallet file, and if channels were open when the wallet was last used, recovering just the seed won’t recover Lightning channel state. The wallet file itself is critical for Lightning recovery.

4.x series (2020–present): Continued refinements. Version 4.1.0 removed the option to create legacy wallets through the normal UI (defaulting to native segwit). Version 4.5+ updated the storage version further. The wallet DB upgrade code handles migration from very old formats, but it’s not always smooth — there are edge cases in the upgrade path from v1.9.8 wallets that can trigger error messages suggesting you contact the developers.

The lesson: Before upgrading Electrum, always copy your wallet file to a separate location. If the upgrade breaks something, you can go back to the old version with the original file. And never, ever downgrade after an upgrade has touched the wallet file.

Password cracking and why Electrum is uniquely vulnerable

Electrum’s key derivation – just SHA256(SHA256(password)) – is one of the weakest in the entire cryptocurrency wallet ecosystem. There’s no salt, no PBKDF2, no scrypt, no argon2. Two rounds of SHA-256, and that’s your encryption key for AES-256-CBC.

For context: MetaMask uses 600,000 PBKDF2 iterations. Bitcoin Core uses ~100,000+. Electrum uses… two SHA-256 operations. On a modern GPU, hashcat can test billions of SHA-256 hashes per second. Even accounting for the AES decryption verification, Electrum password cracking is orders of magnitude faster than almost any other wallet.

Hashcat supports Electrum through three modes based on the wallet salt type:

• Mode 16600 – Electrum Wallet (Salt-Type 1-3): Covers the vast majority of wallets. The hash format looks like $electrum$1*<hex_salt>*<hex_data>.
• Mode 21700 – Electrum Wallet (Salt-Type 4): Newer wallet encryption format with ECIES whole-file encryption.
• Mode 21800 – Electrum Wallet (Salt-Type 5): Latest encryption variant.

To extract the hash, use electrum2john.py from the John the Ripper project.

btcrecover is the other go-to tool, and arguably more practical for most recovery scenarios because it supports token-based password building. You specify components you remember (“I know it started with ‘Bitcoin’ and ended with some numbers and maybe an exclamation mark”) and it constructs all permutations. For Electrum specifically, btcrecover supports both the encrypted wallet file and direct seed recovery for cases where you have a partial seed phrase with missing or uncertain words.

Corrupted wallet files

Wallet file corruption in Electrum takes several forms, and the recovery approach depends on what broke – if you have any specific case you can contact us at david@walletrecoveryservice.com and we will try to find the answer for you.

The “v1.9.8 bug” wallets: There’s a specific class of corrupted wallets from Electrum version 1.9.8 where entering an incorrect seed during restoration created a wallet file that looked valid but had no actual key material. The wallet DB code in modern Electrum has a special check for this: it looks for wallets with no master keys and a v6 seed version, and warns the user. These wallets contain no recoverable funds.

Lightning channel state corruption: If a wallet with open Lightning channels gets corrupted, restoring from seed alone will NOT recover the Lightning funds. Lightning channels are stateful – the latest channel state (commitment transactions, revocation keys) is only in the wallet file. Electrum includes a channel backup mechanism (SCBs – Static Channel Backups), but these only allow force-closing channels, not resuming them. If you have a corrupted wallet with Lightning funds, the priority is recovering the wallet file itself, not just the seed.

Backup strategy: Electrum has a built-in backup function at File → Save Backup (or Save Copy in older versions). This saves a complete copy of the wallet file. The backup is still encrypted with your password, so you need both the backup file and the password to restore. For maximum safety, export the seed phrase on paper AND keep wallet file backups (especially if using Lightning or imported keys).

The Electrum Android wallet

Electrum for Android is built on the Kivy framework (introduced in version 2.6) and uses the same wallet file format as desktop Electrum. The seed types, encryption, and derivation paths are identical. A wallet file created on Android can be opened on desktop and vice versa.

The Android-specific challenge is file access. On non-rooted Android devices, Electrum’s wallet files are stored in the app’s private internal storage at:

/data/data/org.electrum.electrum/files/data/wallets/

You cannot access this path through a normal file manager or over USB – Android’s sandboxing prevents it. This is by design (to prevent other apps from stealing wallet files), but it creates a real recovery problem if the app crashes or gets accidentally uninstalled.

There is no iOS version of Electrum. Period. If someone claims to be running Electrum on an iPhone, they’re using a fake app – and there have been multiple scam Electrum clones on the App Store over the years that steal funds.

The overwritten and deleted wallet file problem

Electrum wallet files are normal files on the filesystem. This makes them both easier to back up and easier to accidentally delete.

Scenario 1: Wallet file deleted

If the wallet file was deleted (accidentally, through uninstallation, or by malware), contact WalletRecoveryService.com for professional data recovery or send us an email at david@walletrecoveryservice.com . The wallet file is typically small (a few hundred KB for a standard wallet, potentially several MB for wallets with extensive Lightning channel history), which means it’s often recoverable from disk even after deletion – IF the disk hasn’t been heavily written to since.

On SSDs, the TRIM window applies – stop using the drive immediately. On HDDs, you have more time but every write operation risks overwriting the wallet file’s sectors.

Scenario 2: Wallet overwritten during restoration

This is an Electrum-specific trap. When you restore from seed in Electrum and choose the same wallet file name as an existing file, Electrum overwrites the old file. The documentation mentions this, but it’s easy to miss in a panic. If you have a wallet file with imported private keys (not derived from seed) and you overwrite it by restoring a different seed to the same filename, those imported keys are gone unless you had a separate backup.

Always use a different filename when restoring: restored_wallet, recovery_test, anything other than the name of an existing wallet file.

Scenario 3: Wallet file on a failed drive

Electrum’s wallet file is a single, self-contained file. If you can recover that one file from a failed drive – through professional data recovery, disk imaging, or file carving – walletrecoveryservice.com can help and assist with the process – you have everything needed. You don’t need to recover the entire Electrum installation, configuration, or blockchain headers. Just the wallet file and your password (or seed phrase).

The phishing attack vector – a unique Electrum problem

Electrum has a notorious vulnerability that doesn’t exist in most other wallets, and it’s directly relevant to recovery because it causes the very situations that need recovering from.

In December 2018, it was discovered that Electrum servers could send arbitrary error messages to the client, which Electrum would display as HTML-rendered text. Attackers set up malicious Electrum servers that, when a user broadcasted a transaction, would return a fake “update required” error with a link to a phishing site hosting a modified Electrum binary. Users who downloaded and installed the fake update would have their seeds or wallet passwords stolen.

This attack was particularly devastating because the phishing message appeared within Electrum’s own interface, making it look official. Thousands of Bitcoin were stolen before the vulnerability was patched. The fix was released in Electrum 3.3.3, which stopped rendering HTML in server messages.

Why this matters for recovery: Many users who lost funds to this attack still have their original wallet files with the original seeds – the attacker’s version stole the keys and moved the funds, but the legitimate wallet still exists. If someone comes to me with “I had Bitcoin in Electrum and it just disappeared in 2018-2019,” the phishing attack is always one of the first things I check. The recovery in that case isn’t technical — the funds were stolen, not lost. But it’s important to diagnose correctly so the user doesn’t waste time and money on password cracking for a wallet that was emptied by an attacker.

Multisig and 2FA wallet recovery

Electrum supports multi-signature wallets and a 2FA option through TrustedCoin, and both add complexity to recovery.

Multi-signature wallets in Electrum are identified by the wallet type field: "wallet_type": "2of3" or similar. The wallet file contains multiple keystores (x1/, x2/, etc.), each representing one cosigner. To spend from a multisig wallet, you need the threshold number of keys. If you have the wallet file with all cosigner keystores, recovery proceeds normally. If you only have one cosigner’s seed and need the other cosigner(s), you need the other key holders’ cooperation.

2FA wallets use TrustedCoin as a cosigning service. These are essentially 2-of-3 multisig wallets where TrustedCoin holds one key and the user holds two. Recovery requires either: (a) two of the three seeds, or (b) one seed plus the TrustedCoin service being operational and the user being authenticated. If TrustedCoin shuts down, users can still spend using their two local seeds – but they need both. The 2FA recovery key that Electrum displays during wallet creation (and that most people never write down) is the third seed, and it’s essential for recovering without TrustedCoin.

Recovery techniques that actually work in practice

After years of recovering Electrum wallets, here are the scenarios I handle most frequently and how I approach them.

Scenario 1: Have seed phrase, just need to restore

Open Electrum, File → New/Restore. Choose “Standard wallet” → “I already have a seed.” Enter the seed. If it’s an Electrum seed, Electrum will auto-detect the seed type and derivation. If it’s a BIP39 seed (from a hardware wallet or another software wallet), click Options → select “BIP39 seed” BEFORE entering the words. Choose the correct script type and verify the derivation path. Set a new password.

If the balance shows zero: try different script types (native segwit, wrapped segwit, legacy). If using BIP39, click “Detect Existing Accounts” to scan for history. Increase the gap limit if addresses beyond the 20th were used.

Scenario 2: Have wallet file and password

Simply open Electrum and point it to the wallet file. If the file is on a USB drive or non-default location, use File → Open and browse to it. Once opened, you can view your seed at Wallet → Seed (requires password), export private keys, or just transact normally.

Scenario 3: Have wallet file, forgot password, have seed phrase

Ignore the password entirely. Create a new wallet from the seed phrase (as in Scenario 1). The seed generates the same keys regardless of what password was set on the old wallet file. Set a new password on the new wallet.

Scenario 4: Have wallet file, forgot password, no seed phrase

This is brute-force territory. Contact professional recovery expert like walletrecoveryservice.com or extract the hash with electrum2john.py, and feed it to hashcat (mode 16600, 21700, or 21800 depending on salt type) or btcrecover.

Scenario 5: Old Electrum v1.x wallet

Don’t try to open a v1 wallet directly in Electrum 4.x – the upgrade path can fail for certain edge cases, and if it does, you’ll want to have the original file untouched. Contact us via email david@walletrecoveryservice.com, we have been dealing with cases like that for a long time.

Scenario 6: Electrum seed doesn’t work in another wallet

If trying to import an Electrum seed into a non-Electrum wallet (Trezor, Ledger, Exodus, etc.), it won’t work because those wallets expect BIP39 format. You can restore in Electrum and sweep/send funds to the target wallet.

Scenario 7: BIP39 seed from hardware wallet shows wrong addresses in Electrum

You probably selected the wrong script type or derivation path. For Trezor wallets: native segwit is m/84'/0'/0', legacy is m/44'/0'/0', wrapped segwit is m/49'/0'/0'. For multiple accounts, increment the last hardened index. Electrum must be set to BIP39 mode (Options → BIP39 seed) before entering the words.

Scenario 8: Android wallet, app won’t open

If the phone is rooted, navigate to /data/data/org.electrum.electrum/files/data/wallets/ and copy the wallet file. If neither works and you have the seed phrase, restore on desktop. If you don’t have the seed and the phone isn’t rooted, your last option is a professional Android data extraction service that can image the device’s storage.

Tools every Electrum recovery specialist should have

• electrum2john.py – Hash extraction from John the Ripper’s Jumbo edition. Works on all Electrum wallet formats.
• hashcat – Modes 16600, 21700, 21800. Fast GPU-based password cracking.
• btcrecover – Token-based password recovery and seed recovery (for partial/uncertain seed phrases).
• Ian Coleman’s BIP39 tool – Run offline only. Has Electrum seed mode for deriving keys and addresses from Electrum-format seeds.

What separates recoverable wallets from lost ones

The Electrum ecosystem is more forgiving than most because the wallet file is a self-contained, portable, well-documented JSON file that can be opened in any text editor (if not whole-file encrypted) and processed by well-supported open source tools. The encryption, while providing adequate protection for most users, is dramatically weaker than industry standards – which is bad for security but excellent for recovery.

The wallets I can’t recover share one of two characteristics: the user lost both the seed phrase AND the wallet file (nothing to work with), or the user lost the seed phrase, has the wallet file, and set a truly strong password (15+ random characters) against which brute-force is computationally infeasible even with Electrum’s weak key derivation.

Everything else – wrong derivation paths, format incompatibilities, corrupted files, old versions, Android extraction – is solvable with the right custom tools and knowledge.

The single most important thing you can do right now: go to Wallet → Seed in your Electrum installation, write those 12 words on paper, and put that paper somewhere safe. Your wallet file can be corrupted, deleted, encrypted, or lost. But twelve words on paper, stored securely, will always get your Bitcoin back.

Got questions? Drop ’em in the mail at david@walletrecoveryservice.com