Browse documentation
Live For technical

Electrum wallet engine

How Distribrute supports encrypted Electrum v1/v2 and 2.8+ BIE1 wallet files without sending a spendable wallet to operators.

Last reviewed Jul 22, 2026

Where it fits

Distribrute supports password recovery for compatible encrypted Electrum wallet files in both custodial and non-custodial recovery. The file is often named default_wallet and may have no extension.

The engine recognizes two storage families:

  • Legacy Electrum v1/v2: Python-dictionary or JSON wallets with a password-encrypted old seed, extended private key, multisig cosigner key, or imported private key.
  • Electrum 2.8+ BIE1: whole-file storage encryption using Electrum’s BIE1 ECIES container, including reviewed standard, SegWit, multisig, and imported-key layouts.

Compatibility is checked before a case is accepted. An Electrum account name, receiving address, seed phrase, or hardware-wallet PIN is not a substitute for the original encrypted wallet file.

Two safe test pieces

The engine parses the wallet and selects the correct format automatically. Operators never need the full wallet or the public reference used for final verification.

Wallet storageOperator modeSafe test pieceDeliberately omitted
Legacy v1/v216600One 16-byte IV and one 16-byte ciphertext block from the encrypted seed, xprv, or imported keyThe rest of the encrypted secret, master public key or xpub, stored addresses, and all other wallet records
Electrum 2.8+ BIE172000The per-encryption 33-byte ephemeral public key and the first 96 ciphertext bytesThe rest of the encrypted wallet, full-file HMAC, xpub, private keys, complete address set, balances, and history

Neither artifact contains enough wallet material to reconstruct a seed, extended private key, or spendable wallet. A password found on an operator machine is therefore necessary to unlock the owner’s wallet but is not sufficient to move funds by itself.

The BIE1 metadata limit

The BIE1 safe test piece is intentionally only one short encrypted segment. After testing the correct password, an operator can decrypt that segment and may see the opening of the compressed wallet JSON. In the reviewed Electrum 4.8 layouts that opening is non-sensitive format metadata. In some older Electrum files through 4.0, it can include a prefix of the first wallet address.

The segment does not reach the xpub, seed, private keys, complete address set, balance, or transaction history. This limited format-specific disclosure is reviewed with the wallet owner; it is why the general safe-test-piece claim is “no spendable wallet,” not “no metadata of any kind.”

Candidate checking and ground truth

Both operator checks can produce a possible match that still requires stronger confirmation:

  • A legacy operator check recognizes the expected structure of one decrypted block. Full-wallet verification decrypts the selected field and checks the derived public key or address against the wallet’s own public reference.
  • A BIE1 operator check validates the beginning of the encrypted wallet structure. Custodial verification checks the candidate against the full-file HMAC, which is definitive.
  • In a non-custodial case, the owner keeps the full wallet. A safe-piece match remains probable until an authorized human confirms the candidate against that real wallet during the guided local recovery. A probable match alone cannot mark the case recovered or activate finder credit.

This separation lets the fleet search the same password space in either custody mode while keeping the full wallet inside the high-trust or owner-controlled boundary.

Addresses, balances, and settlement

Electrum support does not remove the success-funding risk described in Operator rewards and settlement. Some legacy files contain public references that can help with case review, while BIE1 encrypts the wallet contents as a whole. Distribrute may therefore be unable to establish the complete address set or current spendable balance before the password is found.

A correct password can open a valid but empty wallet, a wallet whose funds were already spent, or a multisignature wallet still missing another required cosigner. No funded recovery and completed settlement means no operator payout.

Compatibility limits

  • The wallet must contain a supported password-encrypted secret; unencrypted and watch-only files do not present a recoverable password lock.
  • BIE2 / XPUB_PASSWORD hardware-wallet storage is outside the current engine.
  • Unknown serialization variants, damaged files, and files above the current parser bound require case-specific review and may be rejected.
  • Recovering one encrypted multisig cosigner does not recreate any other missing cosigner.
  • A compatible wallet does not guarantee that the proposed candidate search will find its password.

For the general operator boundary, continue to Safe test pieces, End-to-end recovery, or the Trust model.