sparrow-wallet.app Independent guide Buy bitcoin to self-custody

Multisig · reviewed 2026-08-10

Sparrow Wallet multisig: read the warning before you read the guide

Multisig replaces a single point of failure with a quorum: several keys exist, and only some of them are needed to spend. Sparrow implements it properly, with output descriptors and full PSBT collaboration. It is also more than twice as much to get wrong, and the most common multisig loss has nothing to do with an attacker.

Buy bitcoin to move into your own quorum

  • k-of-n multisig
  • Hardware co-signers
  • PSBT collaboration
  • Output descriptors
  • No miniscript editor

Unofficial

Who should use multisig, and who should not

Here is the verdict first, because burying it would be dishonest. If you are holding a modest amount, a single hardware wallet with a backup you have actually tested is safer than a badly-managed 2-of-3. Complexity is itself a failure mode. A quorum you do not fully understand, whose descriptor you never printed, whose third key lives in a drawer you will forget about, is not three times as secure — it is three times as many things that can quietly stop working.

We are not arguing against multisig. We are arguing against adopting it as a badge. The honest test is whether you can answer four questions without looking anything up: where each key is, what the script type is, where the descriptor is stored, and when you last proved you could spend from the wallet using only your backups. If any answer is vague, fix the single-signature setup first.

Multisig is the right call when

  • The balance is large enough that losing one device, or having one seed found, would be a genuine disaster rather than an annoyance.
  • You want geographic separation — keys in different buildings, cities or countries — so that a fire, a burglary or a raid cannot reach a spending quorum.
  • Funds are shared: a business treasury, a family holding, a partnership where no single person should be able to move money alone.
  • You are building an inheritance plan and want a trusted third party to hold a key that is useless on its own.
  • You distrust any single hardware manufacturer enough to want the quorum spread across three of them.

Stay with a single signature when

  • You are new to self-custody. Learn to make and verify one backup before you make three.
  • The amount is what you would keep in a current account. The overhead is not free and the risk it removes is small here.
  • You spend from the wallet often. Every spend needs two devices and two approvals, and friction makes people take shortcuts.
  • Nobody else would be able to reconstruct your setup if you were not around. A multisig that only you can operate is an inheritance problem disguised as a security upgrade.

If a passphrase-protected single-signature wallet on a good device covers your threat model, that is a legitimate answer and you can stop here. Read the threat model page and the hardware wallet comparison instead.

Before you start, have these ready

Devices
Three signers, ideally three different vendors.
Sparrow
A verified install — see download and verify.
Media
A microSD card for airgapped signers, or a cable for connected ones.
Paper
Three seed backups and somewhere to print the descriptor.
Time
An unhurried evening. Do not do this between meetings.

The primitive

What a quorum actually is

A multisig wallet is defined by a rule baked into the Bitcoin script that locks the coins: k signatures out of n possible keys are required to spend. The network enforces that rule. It is not a policy your wallet software promises to follow, and no company can override it.

The reason 2-of-3 is the default sensible choice is that it is the smallest quorum which protects against two genuinely different failures at once.

Theft of one device. An attacker who steals a signer, or finds one seed phrase, gets exactly one key. One key signs nothing. They need a second, in a different place, which is a completely different burglary.

Loss of one device. A drive fails, a house floods, a seed card goes missing. You still have two keys, which is a spending quorum, so you move the funds to a fresh wallet and rebuild. Nothing was lost but an afternoon.

2-of-2 gets you the first property and destroys the second, which is why it is almost never the right answer for personal savings. Note also what 2-of-3 does not give you: it is not a backup scheme for a badly stored descriptor, and it does not protect you if all three keys sit in the same building.

Key A — home safe signed Key B — office signed Key C — trusted third party not needed PSBT 2-of-3 quorum Spend authorised Any two signatures move the funds. One lost device is survivable.
Two signatures out of three authorise the spend. The third key can be lost or stolen without ending the wallet — provided it is not stored beside one of the others.

Quorum options compared

Assessment by this site. Sparrow supports k-of-n multisig on the common script types.
QuorumProtects againstNeeded to spendVerdict
1-of-1 (single signature)NothingOne device, one seedSimplest. One stolen seed empties it; one lost backup ends it.
2-of-2Theft of one deviceBoth devices, both backupsAdds theft resistance and removes loss resistance. Rarely the right answer.
2-of-3Theft of one device and loss of one deviceAny two of threeThe sensible default. Survives one failure of either kind.
3-of-5Theft of up to two, loss of up to twoAny three of fiveFor shared or institutional custody. Five backups to manage is a real cost.

Step by step

Creating a 2-of-3 multisig wallet in Sparrow

Nine steps, in order, with the verification work included rather than left as an exercise. Do the whole thing on a wallet with no money in it first if this is your first attempt.

  1. Decide the quorum and where the keys will physically live

    Before you touch the software, write down on paper which three devices you will use and where each one will be stored. Two devices in the same drawer is a 2-of-3 on paper and a 1-of-1 in reality. Different vendors is better than three of the same model, because then no single manufacturer or firmware bug is a common failure point.

  2. Collect an extended public key from each of the three devices

    An xpub is an extended public key: it lets Sparrow derive every receive address for that key and watch them, but it cannot spend anything. Export one from each signer — over USB, or as a file or QR code from an airgapped device. Note the derivation path shown alongside each xpub. Keep the three exports distinguishable; a mislabelled keystore is the most common cause of a wallet that will not sign.

  3. Create the multisig wallet and choose the script type

    In Sparrow create a new wallet and set the policy to multi signature with a threshold of 2 and a total of 3 cosigners. Choose the script type once and do not change it later: native segwit (P2WSH) is the normal modern choice, and every co-signer must agree on it. A wallet built with the wrong script type will generate addresses that none of your recovery attempts will find.

  4. Import each keystore in turn

    Add keystore 1, 2 and 3 from the three xpubs you exported, giving each a label that names the physical device and its location. Confirm that the master fingerprint and derivation path Sparrow shows for each keystore match what the device itself reported. When all three are in, Sparrow can build the wallet and begin scanning for history.

  5. Register the wallet on the devices that need it

    Some signers must be taught about the quorum before they will sign for it. Export the wallet configuration from Sparrow and load it onto the device — on a Coldcard this is a file written to the microSD card, and on a Ledger it is a wallet policy registration confirmed on the device screen. Devices that need this and have not been given it will simply refuse to sign, which is correct behaviour and reads like a bug.

  6. Verify a receive address independently on more than one device

    Generate the first receive address in Sparrow, then display and confirm that same address on at least two of the three signing devices. This is the step people skip and it is the one that proves the whole construction: if two independent devices, each holding a different key, derive the identical address, then the quorum you saved really is the quorum you think it is. If one device shows a different address, stop and re-check the keystores before any coins move.

  7. Save the output descriptor and back it up with every seed

    Export the wallet's output descriptor — the compact text string that records the script type, the threshold, all three extended public keys and their derivation paths. Print it. Store a copy with each of the three seed backups, so that whichever backup a future you finds first, the descriptor is next to it. This is not optional metadata; read the warning below before you continue.

  8. Test with a small deposit, then test a full spend

    Send a trivial amount in — enough to be worth a fee, small enough that losing it is a lesson rather than a loss. Confirm it appears. Then build a transaction sending it back out, sign with two of the three devices, finalise and broadcast. Do this with each pair of devices in turn if you have the patience: 1+2, 1+3, 2+3. Only once all three pairs have successfully spent do you know you have a working 2-of-3 rather than an accidental 3-of-3.

  9. Fund it properly, and write the recovery instructions down

    Now move the real balance in. Then write a plain-language page describing what this wallet is, which devices hold which key, where the descriptor is, and what software to install — addressed to someone who has never used Bitcoin. Store it with the backups. See seed and passphrase setup for how to make those backups durable.

Signing: how a PSBT moves between co-signers

A PSBT is a Partially Signed Bitcoin Transaction — a standard container holding an unsigned or part-signed transaction plus everything a signer needs to inspect it. Sparrow supports PSBTs from the ground up, which is what makes multisig practical across devices and across distance.

  1. Sparrow builds the unsigned PSBT

    You select coins, set the destination and amount, and pick a fee rate in the transaction editor. Sparrow produces a PSBT that is complete except for signatures. At this point it is harmless: it moves nothing and reveals no keys.

  2. Signer one adds a signature

    Over USB, Sparrow pushes the PSBT to a connected device and receives the signature back. For an airgapped signer, Sparrow writes the PSBT to an SD card or shows it as an animated QR stream, the device signs offline, and the partially signed result comes back the same way. Verify the destination address and amount on the device's own screen, not on your monitor.

  3. Signer two adds the second signature

    Repeat with the second device. The PSBT now carries two signatures, which is the threshold. The third key is untouched and stays where it is.

  4. Sparrow combines and finalises

    Sparrow merges the signatures it has collected and finalises the PSBT into a complete, valid transaction. If a signature is missing or a signer produced one for the wrong policy, this is where it becomes obvious, and nothing has been broadcast yet.

  5. Broadcast

    Sparrow sends the finished transaction to the network through whichever server you configured. Broadcasting through your own node also avoids handing a third party the link between your transaction and your IP address.

The co-signer who is somewhere else

Distance is the whole point of multisig, so the flow is built for it. After you have added your own signature, save the partially signed PSBT as a file and send it to your co-signer over any channel — email, a messaging app, a shared drive. It contains no private keys.

They open the file in their own copy of Sparrow, with the same multisig wallet loaded so their device recognises the policy, and sign with their key. They send the file back, you combine, finalise and broadcast.

One discipline: the remote signer must check the destination address and amount on their own device screen and, ideally, confirm the payment details with you through a different channel than the one that delivered the file. A PSBT is not secret, but that also means anyone who intercepts it can see what you are doing — and a co-signer who signs whatever arrives is not adding much security.

Source: sparrowwallet.com — features, PSBT support and multisig

Multisig questions people actually ask

Does Sparrow Wallet support multisig?

Yes. Multisig is a first-class feature, not an add-on. Sparrow creates k-of-n multisig wallets on the common script types, imports keystores from hardware devices, software seeds or watch-only xpubs, exports and imports output descriptors, and handles the whole PSBT collaboration flow between co-signers.

Is 2-of-3 multisig actually safer than one hardware wallet?

Against theft and single-device failure, yes. Against your own mistakes, often no. A 2-of-3 has three seeds, a descriptor, three storage locations and a signing procedure to remember, and every one of those is a thing to get wrong. For a modest balance, one well-chosen hardware wallet with a backup you have actually tested is the safer real-world choice. Multisig earns its complexity when the amount is large enough that a single stolen or destroyed device would be a disaster.

Can I recover a multisig wallet from the seed phrases alone?

Not reliably, and you should plan on "no". To rebuild the wallet you need the quorum configuration as well: the script type, the derivation paths and all of the extended public keys. That is exactly what the output descriptor records. People have lost access while holding three perfectly good seed phrases because nobody wrote the descriptor down. Back it up with every seed.

Does Sparrow support miniscript?

Sparrow's multisig is built on output descriptors, and what you set up in the interface is plain k-of-n multisig — a threshold and a set of keys. There is no policy editor for writing arbitrary miniscript spending conditions such as timelocked recovery branches or decaying quorums. If your plan depends on that kind of policy, Sparrow is not the tool to author it in.

How does a co-signer in another city sign the transaction?

By file. Sparrow saves the unsigned PSBT, you send that file over any channel you like, they open it in their own copy of Sparrow with the same wallet loaded as a watch-only or partially-signed wallet, sign with their device and send the file back. A PSBT contains no private keys, so an intercepted PSBT costs you privacy rather than money — but verify the transaction details independently before anyone signs.

Can I mix hardware wallets from different manufacturers in one quorum?

Yes, and you should. Mixing vendors means a firmware flaw, a supply-chain problem or a company disappearing affects one key rather than all of them. Sparrow does not care which brand each keystore came from, as long as every co-signer agrees on the script type and derivation.

Which hardware wallet is easiest for multisig with Sparrow?

Coldcard, Blockstream Jade, BitBox02, Foundation Passport, Keystone and SeedSigner all handle multisig comfortably. Ledger works but adds a policy registration step that trips people up, and NFC smartcards such as Tapsigner are not designed as multisig co-signers. Details are on the hardware wallet page.

Device-specific friction

Coldcard: the SD-card multisig flow

Coldcard is the device most multisig documentation is written around, and the reason is that it treats the SD card as the primary interface rather than a fallback. The flow has two halves worth naming separately.

First, export: the Coldcard writes its extended public key and derivation details to the microSD card as a file, which you import into Sparrow as one of the three keystores. No cable, no driver, no pairing.

Second, registration: once the wallet exists in Sparrow, you export the multisig wallet configuration back onto the card and import it on the Coldcard itself. The device stores the quorum, and from then on it can display the multisig receive addresses for verification and will sign PSBTs for that wallet. Skip this and the Coldcard has no idea the wallet exists.

After that, spending is card-shuttling: Sparrow writes the unsigned PSBT to the card, the Coldcard signs it, you carry the file back. The device never touches your computer.

Ledger: where multisig gets awkward

Ledger devices sign multisig transactions, but only for a wallet policy they have been told about. Registration is a separate, explicit step performed over USB and confirmed on the device, and it is where most Ledger multisig setups stall.

Two things make it harder than it sounds. The device asks you to review the policy — the script type, the derivation and the co-signer keys — on a screen small enough that genuinely checking it is tedious, and people click through instead of reading. And if the registration is lost or the policy is later reconstructed slightly differently, the device declines to sign with an error that does not obviously mean "your policy does not match".

It is entirely usable, and plenty of people run a Ledger as one leg of a 2-of-3. But if you are choosing hardware now and multisig is the goal, a Coldcard, Jade, Passport, Keystone or BitBox02 will cost you fewer evenings. Comparison on the hardware wallet page.

Miniscript, honestly

This gets searched a lot, so here is a straight answer. Sparrow's multisig is built on output descriptors — the standard text format that records a wallet's script type, keys and derivation paths, and which is what you back up and re-import to reconstruct a wallet in any compatible software.

Descriptors and miniscript are related ideas, and that is where the confusion comes from. But the practical multisig people set up in Sparrow is plain k-of-n: a threshold, a set of keys, one script type. There is no policy editor in the interface for authoring arbitrary miniscript spending conditions — no timelocked recovery branch you compose by hand, no decaying quorum that becomes easier to spend from after a year, no or-of-and combinations of different key sets.

If your plan genuinely requires that, you need tooling built for it, and you should be honest with yourself about whether you will still understand your own policy in five years. For the overwhelming majority of people the answer is a 2-of-3, which is a rule simple enough to explain to an executor in one sentence. That is a feature.

The annual drill

A multisig wallet that has never been recovered is a hypothesis, not a backup. Once a year, put an hour aside and prove it, using nothing you would not still have after a fire.

  • Start from the backups only. Do not open the existing wallet file, do not use the configured devices as a shortcut, and do not look anything up on the computer.
  • Rebuild the wallet from the printed descriptor and two of the three seeds, on a fresh install of Sparrow if you can.
  • Do it on a wallet with a trivial balance, or restore as watch-only from the descriptor first and check that the addresses and history match what you expect.
  • Complete a full spend with two keys. A recovery that stops at "the balance showed up" has not tested signing, which is the half that fails.
  • Note what confused you and fix the documentation, not your memory. Then check that the third key still exists and still works — an unused key silently failing is exactly the situation a drill is for.

Put it in the calendar on a date you will not move. The people who lose multisig wallets are almost never the ones who did this.

Close-up of a hardware wallet device used as one signer in a multisig quorum

Label everything, immediately

Sparrow lets you label every transaction, input and output. In a multisig wallet this stops being cosmetic: when you or an heir opens this wallet in three years, labels are the only record of which deposit came from where and which device signed what. Write them as you go, because you will not reconstruct them later.

Related reading on this site