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 storage | Operator mode | Safe test piece | Deliberately omitted |
|---|---|---|---|
| Legacy v1/v2 | 16600 | One 16-byte IV and one 16-byte ciphertext block from the encrypted seed, xprv, or imported key | The rest of the encrypted secret, master public key or xpub, stored addresses, and all other wallet records |
| Electrum 2.8+ BIE1 | 72000 | The per-encryption 33-byte ephemeral public key and the first 96 ciphertext bytes | The 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_PASSWORDhardware-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.