Recover a 2-of-3 Bitcoin multisig wallet after losing one signer using two surviving keys, the original descriptor, address checks, and a new quorum.
You can recover a 2-of-3 Bitcoin multisig wallet after losing one signer if two valid signers remain and you still have the wallet policy or descriptor. Reconstruct the wallet in a compatible coordinator, verify that it derives the original addresses, sign a transaction with the two remaining keys, and move the balance to a newly created policy.
Do not wipe devices or import seeds into unfamiliar software while investigating the loss. A seed restores only one signer; the full wallet also depends on the quorum, extended public keys, fingerprints, derivation paths, key order, and script type. Recovery is complete only after the expected addresses appear and a transaction signed by the surviving quorum confirms.
Confirm that two signers and the wallet policy still survive
Start by identifying the missing component: one hardware signer, one seed backup, the original coordinator, or a recovery location. Confirm that two independent signing keys remain accessible and that neither has been exposed. Record one known receive address and one funded transaction from the original wallet so the reconstructed policy can be checked before signing.
The available recovery package should identify the script type, quorum, extended public keys, master fingerprints, derivation paths, and wallet descriptor or configuration file. It should also explain where each signer is stored and which two-signature combinations are allowed. This is the operational layer that complements a Bitcoin hardware-wallet backup; a single-device restoration cannot recreate a multisig policy by itself.
| Failure event | Recovery action | Evidence required before moving funds |
|---|---|---|
| One signer is lost | Rebuild with the two surviving signers | Correct addresses and signatures from both devices |
| Original coordinator is unavailable | Import the policy into a compatible replacement | Matching descriptor, balance, inputs, and change |
| One recovery location cannot be reached | Use signers stored in the other locations | The accessible keys still meet the quorum |
| A hardware device failed | Restore its seed only on approved replacement hardware | Matching fingerprint and derivation path |
| An heir or executor takes over | Reconstruct the policy from the handoff record | Authorized operator can verify and move the funds |
Assemble a recovery package that describes the wallet
The descriptor is the most useful portable record because it describes the scripts and key derivation rules needed to reproduce the wallet. If the coordinator exports a configuration file instead, verify that it contains the same public information. Keep a readable copy for an executor and a machine-readable copy for import, but never place private keys or seed words in the policy record.
Unchained’s wallet-configuration breakdown explains why the two surviving seeds are not sufficient by themselves: rebuilding the original addresses also requires the third signer’s public key and the policy that combines all three signers. Check the export against the following fields before relying on it.
| Configuration field | Required value for a 2-of-3 recovery | Failure signal |
|---|---|---|
| Quorum and script type | Original 2-of-3 policy and the same P2SH, P2SH-P2WSH, P2WSH, or P2TR format | Rebuilt addresses use a different prefix or script |
| Extended public keys | All three original xpubs or equivalent extended public keys, including the missing signer | Only the two surviving signers appear |
| Fingerprints and paths | Original master fingerprint and derivation path for every signer | A device derives a different xpub or fingerprint |
| Key order and descriptor | Original ordering rules, descriptor text, and checksum when available | Coordinator changes the derived receive addresses |
An xpub is public spending-policy data, not a seed, but it exposes wallet addresses and transaction history. Store the configuration privately and separately from any two signer backups so one location cannot reveal the wallet and supply a spending quorum.
Policy visibility is where Nunchuk users see practical value. In a June 2026 Iron Hand comment, one user described its interface as cleaner than alternatives they had tried and highlighted the inheritance workflow, while warning that key distribution still required independent research. That experience supports using the interface to organize the policy, not treating it as recovery proof; export the record and complete a coordinator-independent spend.
Record each signer’s device name, master fingerprint, derivation path, and storage location. A label such as “office key” is not enough if the replacement operator cannot distinguish it from another device. The inventory should say whether the signer is active, a geographic backup, or held by a trusted person, and it should identify who can authorize access.
Separate the policy record from the signer secrets. Storing two seeds beside the descriptor creates a complete quorum in one place and defeats the geographic protection of 2-of-3 multisig. The multisig wallet comparison explains the coordinator choices; this guide focuses on reconstructing and retiring an existing policy after one component disappears.
Reconstruct the wallet and match its original addresses
Use the original wallet history, a block explorer, or a known watch-only record to identify the expected receive addresses and unspent outputs. Compare at least two addresses with the reconstructed coordinator. Do not proceed merely because a familiar wallet name or approximate balance appears; a wrong derivation path can produce a valid but unrelated wallet.
Create a recovery transaction that uses the two surviving signers and sends the balance to a fresh wallet policy. Review the destination, fee, change output, policy, and inputs on both hardware displays before approving it. The hardware-wallet security comparison is relevant here because key isolation does not replace transaction review or policy verification.
Do not send the recovery transaction back into the damaged policy. Build a new wallet with newly verified backups, then transfer a small amount first when time and fee conditions permit. If either surviving signer cannot reproduce the recorded fingerprint or the coordinator cannot combine both signatures, stop rather than trying alternate derivation paths against the full balance.
Sign the exit transaction with the two surviving signers
Treat the missing signer as permanently unavailable until its physical state is known. Do not delete it remotely, announce the seed publicly, or reuse the damaged policy for future deposits. Bring the two surviving devices and the public recovery package into a clean working environment without placing both seed backups beside the same computer.
The storage format changes how practical this recovery is. A Passport user in a June 2024 multisig recovery comment found QR-based signing easier for family members and kept both printed and SD-card descriptor copies with the authorized backups. That is one operator’s workflow rather than a universal rule, but it identifies the required outcome: the surviving signers must read the policy data and complete the PSBT without the original computer.
Recreate the wallet on a clean computer or separate operating-system profile. Compare at least two receive addresses with the original record before loading the UTXOs. A matching wallet name or balance is insufficient; the derived addresses and descriptor checksum provide stronger evidence that the correct policy was restored.
Build and sign the exit transaction with the two available devices. The need for a provider-independent path became concrete when a three-year Casa customer encountered web-signature errors and delayed support, then used Sovereign Recovery to move the funds in a March 2024 recovery account. Casa later described the interface bug as resolved, so the report is not evidence of current failure; it shows how a customer-controlled quorum can provide an exit when the normal dashboard is unavailable.
Replace an unavailable multisig coordinator
Coordinator failure is different from signer loss. The keys may be safe while the software that assembles transactions is unavailable, incompatible, or no longer maintained. Import the descriptor or wallet configuration into a replacement coordinator that supports the same script type and hardware devices, then verify addresses before attempting a spend.
Do not assume that every coordinator interprets an export identically. An Unchained vault user imported a Caravan configuration into Sparrow and verified receiving, but initially could not spend because the keystores remained watch-only; the user later identified key import and derivation-path handling as the missing steps in a December 2022 recovery account. A matching balance therefore does not prove that both surviving devices can sign.
Create the transaction in the replacement coordinator and inspect it on each signer. Partially signed Bitcoin transactions should move between systems without changing the intended inputs or outputs. If the replacement tool rewrites the transaction, compare the new proposal from the beginning instead of signing based on the earlier review.
Replace a failed signing device without changing the policy
When the private backup still exists but its hardware device has failed, restore that signer into an approved replacement device and confirm its fingerprint before connecting it to the wallet. This recovers one key, not the complete multisig policy. Never enter the recovery words into a website, browser extension, general computer, or photographed note; recent wallet theft incidents show why the recovery channel is part of the security boundary.
If the restored fingerprint differs, stop. Common causes include the wrong seed, a missing passphrase, or a different account path. Guessing until one address looks familiar can create a wallet that appears functional but cannot join the original quorum. The recovery record should identify whether a passphrase is required without storing that passphrase beside the seed.
After moving the balance, decide whether the replacement device will remain in the new policy. Wipe any temporary device according to the manufacturer’s process. The recovery record should identify the device model, firmware version, pair of signers used, transaction ID, and any correction made to the stored derivation or policy information.
Transfer control to an heir or authorized executor
An inheritance plan fails if only the original owner understands the labels. Give the written procedure to the intended executor without revealing enough secrets to spend today. Ask the executor to identify the wallet policy, locate the permitted recovery contacts, explain which two signers form a quorum, and describe how the destination address will be independently verified.
Resolve ambiguous language before the executor handles the real balance. “Use the backup key” is unclear when several devices exist, while “contact the provider” is incomplete when the account owner is deceased or the service is unavailable. The Bitcoin inheritance planning guide provides the broader handoff context; this recovery process identifies the policy and signing data the executor actually needs.
When the owner is still able to prepare the handoff, do not make the heir’s first transaction a full-balance recovery. Use a small output under the same operating model and verify that the executor can identify the policy, destination, and required signers without seeing unnecessary secrets.
Move the balance and retire the damaged policy
Once the recovery transaction confirms, stop using receive addresses from the damaged policy. Replacing a multisig key means creating a new wallet with the two safe keys and a newly generated third key, then transferring every old output; it does not modify the key inside the existing policy. Create a new signer inventory, preserve the new descriptor checksum, update every watch-only wallet and replace any whitelisted deposit address. If the missing signer might have been copied rather than destroyed, do not include it in the replacement quorum.
Reconcile the complete original balance, including small UTXOs that high fees may make inconvenient to move. Document any output intentionally left behind and the reason. Check the destination transaction independently before destroying old recovery materials, because a confirmed partial move does not prove that every wallet branch was recovered.
The final record should state which signer was unavailable, which coordinator was used, which pair signed, whether addresses matched, and where the transaction confirmed. Delete sensitive temporary files after retaining the minimum audit evidence. Never place seed words, PINs, or passphrases in the recovery record.
Conclusion
A 2-of-3 wallet remains recoverable after one signer is lost when the other two keys and the public policy data can recreate the original addresses and authorize a transaction. Verify the descriptor, fingerprints, derivation paths, inputs, destination, and change before signing with the surviving quorum.
Move the funds to a new policy rather than continuing to receive into the damaged quorum. Replace the missing signer, distribute the new backups independently, and complete a low-value recovery check before treating the replacement vault as long-term storage.
Frequently asked questions
Does each multisig seed restore the complete wallet?
No. One seed restores one signer. The complete wallet also needs the public keys, derivation paths, script policy, and quorum information required to derive the multisig addresses.
Can two remaining keys recover a 2-of-3 multisig wallet?
Yes, if both keys belong to the original policy and the coordinator has the correct descriptor or equivalent public policy data. Confirm the derived addresses before signing.
Is a watch-only restoration enough to recover the funds?
No. It proves that the policy can be reconstructed and monitored, but the funds remain unrecovered until the required quorum signs a valid transaction and it confirms on the Bitcoin network.
Should all funds be moved after one signer is lost?
Yes, after verifying the recovery path with a small amount when practical. The old policy has reduced redundancy and may include a signer whose exposure is unknown.
Should the original descriptor be kept after recovery?
Keep a protected archival copy until every original output has been reconciled and the recovery transaction is confirmed. Do not reuse the descriptor as the active policy for new deposits.
Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Cryptocurrency and digital asset markets carry significant risk. Always do your own research before making decisions.
