Multisig Wallet for One Person: What 2 of 3 Really Costs

A multisig wallet for one person usually means 2 of 3: three keys you hold, any two of which can spend. It removes your single seed phrase as a single point of failure and adds a new one, the wallet configuration, which two surviving seeds alone cannot reconstruct.

On this page: a 2 of 3 traced step by step through Coinkite’s own airgap documentation with the failure point named at each stage, the descriptor arithmetic that comes to nine things in three places, the release dates of three coordinators read on 6 October 2026, and six dated public accounts of what actually went wrong.

What does a 2 of 3 multisig wallet actually protect against?

Four things, and it is worth being precise about which four. A thief who finds one seed backup gets nothing. A fire that takes one backup leaves you with two. Somebody standing over you with one device cannot sign on their own. And a flaw in one manufacturer leaves the other two keys intact, which is why Sparrow’s best practices page tells you to use hardware wallets from multiple vendors, ensuring that a vulnerability in one vendor does not completely compromise the setup.

That fourth one stopped being theoretical this summer. On 1 August 2026 Coinkite published a security advisory saying seeds generated on a Coldcard Mk2 or Mk3 running firmware 4.0.1 through 4.1.9 carried roughly 40 bits of entropy instead of 128, and that Mk4, Mk5 and Q seeds made before the fixed releases carried about 72. Anyone who had built a 2 of 3 out of three Coldcards on affected firmware had three weak keys, not one. A quorum does not help when the same bug sits in every seat. The advisory itself is covered in the Coldcard Mk3 write up.

What 2 of 3 does not do: protect you from signing a payment to an address you never checked, or from losing the file that describes the wallet. Trezor’s own page says plainly that multisig setups are complex and that there is a higher risk of errors that could result in lost access. That is the company selling you the second and third device, a level of candour the affiliate review with the discount code never quite reaches.

Why are two of your three seeds not enough to recover?

Because a seed phrase is a private key, and a multisig wallet is a rule about public keys. The rule lives in the wallet configuration, also called the output descriptor: the quorum, all three extended public keys with their fingerprints, the derivation path and the script type. Coldcard’s multisig documentation states the condition exactly: Multisig wallets can be reconstructed from the seed words, but the M of N policy, co-signer XFP/XPUBS, derivation path and address type must be known.

Scope matters here, and the two halves of Coinkite’s own site do not phrase it the same way. Coldcard’s own 2 of 3 guide takes the stricter line: without the configuration your three seed phrases alone can’t reconstruct the vault, and you would have to redo the export and creation steps by hand. Both are true at different scopes, and the case that actually bites is neither. With only two of your three seeds the third public key is gone for good, and that is the exact scenario a 2 of 3 was bought to survive. Trezor says it from the other direction: you need the extended public key for every key in your keyset, not just the keys required to sign. The descriptor is the other half of the backup, and it is the half nobody stamps into steel.

Two standards exist so none of this has to be guesswork. BIP 48, Multi Script Hierarchy for Multi-Sig Wallets, marked Deployed, fixes a standard six level path for multisig wallets: purpose, then coin type, then account, then script type, then change, then address index. Script type two means native segwit, which gives the recommended default path, written m/48h/0h/0h/2h with h marking each hardened level. BIP 129, Bitcoin Secure Multisig Setup, names the risk out loud: it exists to settle whether the configuration is correct and not tampered with, warns that an attacker who can modify the multisig configuration can steal or hold funds for ransom by duping the user into sending funds to the wrong address, and requires each signer to persist the descriptor record in its storage and match its own key exactly rather than by fingerprint, which it notes is trivial to spoof.

How do you build a 2 of 3 multisig wallet step by step?

The airgapped version, traced through Coinkite’s published 2 of 3 guide and its airgap multisig documentation, with the failure point named at each step. No step here asks you to type a recovery phrase into software.

• Export three public keys. On each device: Settings, Multisig Wallets, Export XPUB, writing a ccxp file to a MicroSD card. Failure point: a different account number on one device, which quietly produces a wallet whose third key you cannot find again.
• Create the wallet on one device. Multisig Wallets, Create Airgapped, native segwit, 2 of 3, then save the export file. Failure point: accepting the defaults without reading the confirmation screen, the only place the quorum is shown before it is fixed.
• Register it on the other two. Import from File on each remaining device. Failure point: skipping this, which leaves a device holding a key that does not recognise the wallet.
• Load the coordinator. In Sparrow: File, Import Wallet, Coldcard Multisig, Import File. It holds no private keys, only the descriptor, which is why losing it unbacked is the problem above.
• Verify, rehearse, then fund. Compare receiving address zero on all three device screens and in the coordinator, character for character. Coinkite puts it in one line for anyone holding an amount whose loss would be materially harmful: Test recovery of the multisig wallet before depositing funds.

Then back up the descriptor once alongside each seed backup. Sparrow says keep the devices and their backups in different locations; Trezor says back up XPUBs in a secure, offline location alongside your wallet backups. Do that arithmetic before you start, because nobody else will. A single signature wallet asks you to keep two things alive, a device and a seed backup. A 2 of 3 asks for three devices, three seed backups and the descriptor, and taking both pieces of guidance seriously makes that last item three copies too. Nine things, in three places, for as long as you hold the coins. That number appears on none of the pages ranking for this query.

What do people who set this up report going wrong?

Six dated public accounts, five from the Sparrow Wallet issue tracker and one from a Bitcointalk thread, picked because each names the quorum, the devices and the error. They are testimony, not evidence: a bug report is one person’s account of their own setup, and none of them measures how often this happens.

• October 2025, the descriptor with no fingerprints. Five friends on a 3 of 5 found nobody could sign: every cosigner’s Sparrow answered No open wallet can sign. The extended public keys in the descriptor each had eight zeroes where the master fingerprints belonged. Issue 1856, closed.
• February 2026, the cable pulled mid signature. On a 3 of 5 wallet, one Ledger Nano S Plus keystore refused to sign ever again after a USB disconnection during signing, returning Signature fail with a blank device screen. Firmware updates and a hardware swap changed nothing; rebuilding the wallet from the identical public keys fixed it. Issue 1940.
• September 2026, the passphrase never asked for. Sparrow 2.5.4 with Jade firmware 1.0.41 prompted for the PIN but never the BIP39 passphrase when signing multisig, so the device unlocked to the wrong wallet. Single signature worked fine. Issue 2072. That device is reviewed in the Blockstream Jade write up.
• August 2026, the order of the keys. An open report that exported descriptors do not preserve the order the cosigners were entered in. The reporter’s reason for caring is the one this page keeps hitting: it makes inheritance documentation hard to write. Issue 2054, still open.
• February 2025, a request for descriptor backup. A feature request for descriptor backup tooling inside the wallet, which is a user saying out loud that the second half of the backup is currently their own problem. Issue 1640, closed without the feature.
• November 2023 to March 2024, four months of forum help. A holder who believed they had built a 3 of 3 in Electrum in 2021 found two cosigners were not what they thought, and restoring from the seed phrases produced empty wallets. The coins moved in the end. Bitcointalk thread 5472462.

The pattern is consistent, and not reassuring in the way the ranking pages imply. Not one is a cryptography failure and not one is a stolen key. All six are configuration, derivation or device path: wrong fingerprints, wrong derivation, wrong order, wrong assumption about what had been backed up. That agrees with the official guidance, which is that the policy and every public key must be known and recorded. Where the accounts part from the marketing is on who multisig is for: Sparrow places it at what it calls the expert stage. The honest range is that five of the six were recovered, four of those only because somebody still held every public key, and the sixth took four months.

Which multisig coordinator software is still maintained?

The coordinator holds the descriptor, watches the addresses and builds the transactions. It never holds a key, which makes it easy to treat as disposable, right up to the day you need it and find the project has not shipped in two years. Release histories read on 6 October 2026:

All three are alive. Electrum and Nunchuk also coordinate multisig, but their release dates were not checked on the day this was published, so treat the table as verified here and the others as not. One thing the comparison pages skip: the app that came with your device probably cannot do this at all. Trezor states that Trezor Suite does not directly support managing multisig wallets and points you at Electrum, Sparrow or Casa. Ledger publishes instructions for connecting a Ledger to Sparrow rather than offering multisig in its own app. So a 2 of 3 is not three devices. It is three devices plus a fourth piece of software, from a fourth maker, that you now also depend on.

What happens to a multisig wallet when you die?

This is the question that turns a clever setup into a liability, and the one the institutional pages ranking for this query are least interested in, because their answer is a company. Your heirs need two of the three seed backups, the descriptor, and enough instruction to know what either of those is. Two seeds in a safe and no descriptor is not an inheritance. It is a jigsaw with a missing piece and no edges.

The standard that helps is BIP 129, whose descriptor record carries the version, the descriptor or template, the path restrictions and the wallet’s first address. That last field is the part an heir can use: it lets them confirm the file they found rebuilds the right wallet before touching anything. Nunchuk, which builds a commercial service on this exact problem, describes the wallet configuration file as the beneficiary’s sovereign backup and uses a dedicated inheritance key with an on chain timelock so the quorum changes on a date you choose. Whether a paid service suits your situation is not something this page can answer. The honest version of the self managed answer is the open issue above: somebody is finding it hard to document which key is which, because the export does not preserve the order they were entered in. Either way the instructions have to be written for somebody who has never heard of a derivation path, and tested by that person while you are still around to answer questions. A rehearsal you fail is cheap. One your heirs fail is not. Speak to a qualified professional about the estate side; everything here is mechanics only.

So who is a 2 of 3 actually for?

On the evidence above: somebody whose real worry is a single backup being found, destroyed or coerced, who will keep nine artefacts alive across three locations for years, who rehearses a recovery before funding and again whenever anything changes, and whose written instructions a non technical person has already tested. Sparrow puts that at the expert stage, for holders where losing it might have a considerable impact on your future. If any of those four is a maybe, the gap is not courage, it is maintenance. A well kept single signature setup with a backup you have actually restored from beats a 2 of 3 you have never tested, and there is no prize for the more complicated diagram. Still working out what you are protecting against? The cold storage explainer and the storage method comparison are the better starting point, and the recovery phrase guide covers the half of the backup everybody already knows about.

Frequently asked questions

This article is educational and is not financial advice. Nothing here is a recommendation to buy, sell or hold anything, and nothing here is ever a reason to enter a recovery phrase anywhere. Speak to a qualified professional about your own situation. You are responsible for your own security decisions.