Electrum 2-of-3 Multisig Wallet Lost: Recovery With 2 of 3 Private Keys
IndeterminateHardware device was lost or destroyed — whether access was recovered is not documented.
In August 2019, a Bitcoin holder created a 2-of-3 multisig wallet using Electrum and transferred funds to it. The user subsequently lost access to the Electrum wallet file itself—the software instance or device containing the wallet definition. However, the user retained access to two of the three private keys, stored separately on hardware devices such as Trezors.
The core technical constraint is that Electrum's multisig implementation requires knowledge of all three public keys to construct the redeem script, which is necessary to create valid transaction signatures even when only two private keys are involved. Loss of the wallet file meant loss of the redeem script and the public key derivation data.
A Stack Exchange response confirmed that spending from the wallet was theoretically possible with only two private keys—multisig by definition requires only the threshold number of signatures. However, this required either: (1) recovery of the redeem script from an archive or backup of the original wallet file, or (2) extraction of the third public key from the blockchain if the multisig address had been used to send funds previously, making the redeem script visible on-chain.
The user's question received technical guidance but no documented resolution. The source does not indicate whether the wallet was recovered, whether the redeem script was reconstructed, or what ultimately happened to the funds. This case illustrates a common custody failure mode: key material alone is insufficient when wallet metadata—specifically the redeem script and all public keys—is not independently backed up alongside the keys themselves.
| Stress condition | Device loss |
| Custody system | Multisig (self-managed) |
| Outcome | Indeterminate |
| Documentation | Partial |
What determines whether device loss is permanent
When a device fails, burns, floods, or disappears, the Bitcoin remains on the blockchain, unchanged. What changes is whether any path to authorized access still exists. A seed phrase stored separately from the device preserves that path. A seed phrase stored with the device — or never recorded at all — eliminates it permanently.
The pattern observed across cases in this archive is consistent: recovery is possible when the seed phrase survived the event that took the device. It is not possible when it did not. The type of device, its cost, its brand, its security features — none of these factors determine the outcome. The seed phrase backup does.
Most device loss cases that result in permanent loss involve one of three failure modes: the seed phrase was never recorded at setup, the seed phrase was stored physically alongside the device and lost with it, or the seed phrase was stored in a location that became inaccessible during the same event (flood, fire, relocation). All three are detectable in advance. A backup test — confirming that the seed phrase can restore the wallet on a separate device — would have revealed the gap before the loss event.
A device loss case becomes unrecoverable the moment the backup path is also broken. The preventive action is simple in concept: record the seed phrase at setup, store it independently from the device, and test that it works. Most cases in this archive involved none of these three steps.