Bitcoin Multisig Wallet: 2-of-3 Setup Guide

Disclaimer: this guide is educational. It is not financial, legal or tax advice, and it cannot promise that any setup is safe. A multisig wallet fixes some risks and creates others. Test every step with a small amount first, and read the current documentation of the software and devices you use, because menus and options change.

TL;DR

• A multisig wallet needs M signatures out of N keys to spend. In a 2-of-3 wallet, any two of three keys can sign.
• The point is to remove the single point of failure: one lost or stolen key does not lose or leak the coins.
• The price is complexity. You must back up more than a seed: you also need the wallet descriptor (or the list of all public keys), and losing that can make recovery hard.
• It is usually worth considering for amounts you would be seriously hurt to lose, not for pocket money.
• Use open standards (BIP-67 key sorting, BIP-48 derivation paths, BIP-174 PSBT) so you are not locked into one vendor.
• Always test: receive a small amount, spend a small amount, and rehearse a recovery before you move the real balance.

Single-sig versus multisig

An ordinary ("single-signature") wallet is controlled by one private key, usually backed up as a seed phrase. Whoever holds that key controls the coins. That makes the key a single point of failure in two directions at once. If it is lost, the coins are lost. If it is stolen or copied, the coins are stolen.

A multisig wallet separates these two risks by requiring a threshold of keys. The key is not one secret but several, held on different devices and ideally in different places. Bitcoin Core's documentation describes the building block this way: a k-of-n policy in which any k out of the n provided keys must sign (Bitcoin Core, output descriptors).

What a 2-of-3 setup protects you from

Take a 2-of-3 wallet with keys on three separate devices, called A, B and C. The outcomes are easy to state:

The table is a description of the logic, not a guarantee. The protection only works if the keys are really independent: different devices, ideally from different manufacturers, backed up in different physical places, and not all handled by the same person on the same day in the same room.

When multisig is worth the effort

There is no universal threshold, and we do not give one. Think in terms of questions:

• How bad is losing it? If losing the whole balance would hurt you seriously, a single point of failure is worth removing.
• How long will you hold? Long-term storage rewards a setup you configure once and rarely touch.
• Can you handle the operations? Multisig adds steps to every spend, and more things to document. If you will not keep a clear written procedure, a well-made single-sig setup may be safer in practice.
• Does someone else need to be able to recover it? Multisig can make succession easier, because a trusted person can hold a key that cannot spend alone. We cover that angle in our guide to planning a bitcoin inheritance.

Be honest about the other side. More parts mean more ways to make a mistake. A multisig wallet that you cannot recover because you lost a descriptor is worse than a single-sig wallet you can recover. The protection is real only if the operational discipline is real.

The standards that keep you from vendor lock-in

Multisig used to be a patchwork of incompatible conventions. Three open standards make a setup portable across software and hardware, and you should know their names so you can check that your tools support them.

BIP-67: sorted public keys

A multisig script can list its keys in many orders, and each order produces a different address. BIP-67 defines a deterministic way to avoid that: compressed public keys are sorted lexicographically by their binary representation before the script is built, so the same set of keys and the same threshold always give the same address. The BIP's stated motivation is that wallets then only need the number of required signatures and the participants' master public keys to set up the account, and all will generate the same addresses. In descriptor language the same idea appears as sortedmulti.

BIP-48: where the keys come from

BIP-48 documents the derivation hierarchy used by multisig wallets: m / purpose' / coin_type' / account' / script_type' / change / address_index, with the purpose fixed at 48'. It covers two script types: nested SegWit (p2sh-p2wsh) with script level 1', and native SegWit (p2wsh) with 2'. It states that the recommended default for wallets is p2wsh, with the first-account mainnet path m/48'/0'/0'/2'. Why this matters to you: when you export a key from each device, you want all three exported on a compatible path, and you want the path written down.

BIP-174: partially signed transactions (PSBT)

BIP-174 defines a binary format that contains the information a signer needs to produce signatures and holds the signatures collected so far. Its abstract says the signer can be offline because all necessary information is provided in the transaction. This is what lets a coordinator program build a transaction, pass it to each hardware wallet in turn, and collect the signatures, without any device ever exposing its private key to the computer.

Descriptors: the wallet in one line

Bitcoin Core's descriptor language ties these pieces together. A 2-of-3 native SegWit multisig can be written, in generic form, as:

wsh(sortedmulti(2,[fingerprintA/48'/0'/0'/2']xpubA/<0;1>/*,[fingerprintB/48'/0'/0'/2']xpubB/<0;1>/*,[fingerprintC/48'/0'/0'/2']xpubC/<0;1>/*))

This is a template with placeholders, not a real wallet. Reading it left to right: wsh means native SegWit script hash, sortedmulti(2, ...) means two signatures required with keys sorted per BIP-67, and each key carries its origin in square brackets (master key fingerprint plus derivation path), followed by the extended public key and a path suffix. The Bitcoin Core documentation notes that key origin information, meaning the master key fingerprint and all derivation steps, should be included for proper support of hardware devices and external signers, and that a single multipath expression can specify both receiving and change addresses. It also notes that descriptors can carry an 8-character checksum to protect against typos and copy errors.

The practical value of this one line is large. It is the complete public description of the wallet. With the descriptor and any two of the three keys, a compatible wallet can rebuild the wallet and sign.

Choosing the three keys

The design principle is independence. Each key should fail in a different way, so that one cause cannot take out two keys.

• Three devices, ideally from three manufacturers. If a firmware flaw or supply-chain problem affects one model, the other two keys are unaffected. Check each device's compatibility with multisig and with the standards above in its own current documentation before you buy.
• Three storage places. A device and its seed backup should not sit together, and the three sets should not sit together either. Think home, a second location you control, and a third that someone you trust can reach in an emergency. Which places and which people is your decision.
• Fresh seeds, generated on the devices. Do not import an existing seed that has ever touched a networked computer. Never type a seed into a phone or computer to "test" it.
• Passphrases, if used, are a fourth thing to back up. A BIP-39 passphrase changes the keys derived from a seed. Sparrow's own FAQ explains that if a wrong passphrase is entered, a different seed is used and different addresses appear, which can make a wallet look empty. Plan where the passphrase is stored, separately from the seed.

Setup, step by step

The details of each screen depend on the software and devices you pick, and they change between versions, so this walk-through describes the stages and the checks, and points to the vendors' current instructions for the clicks. We did not test a particular device combination for this guide.

Step 1: choose a coordinator and read its multisig documentation

The coordinator is the program that creates the multisig wallet from the three public keys, shows receiving addresses and builds the transactions that the devices sign. Examples include Bitcoin Core with a descriptor wallet, or a desktop wallet that supports multisig and hardware devices. Open-source software is preferable here, because you can inspect it. Download it only from the official site, and verify the signature or checksum the project publishes.

Bitcoin Core's own documentation walks through a basic M-of-N flow using descriptor wallets and PSBTs, and it carries a warning worth repeating: the example is a quick start, each participant must maintain and back up two wallets (a signer and the multisig), and privacy best practice is not the default. It also says it is not recommended to use anything other than a Bitcoin Core descriptor wallet as the signer in that example, because other wallets, hardware or software, add safeguards against signing transactions that could lose funds. In other words, for real money, use hardware devices and their own safeguards, and use the Core flow to understand the mechanics.

Step 2: initialise each device separately

Set up device A, write its seed on the backup medium that device recommends, and store it. Then do the same for B and C, one at a time, in a private place. Do not photograph seeds. Do not store them in a password manager, a cloud drive or an email draft.

Write on each backup, in plain words, which device it belongs to, but not the owner's name, the amount, or the word "bitcoin". Record the device model and firmware version in your separate documentation.

Step 3: export the public key (xpub) from each device

From each device, export the extended public key for the multisig path, along with the master key fingerprint. The standard path for a first-account native SegWit multisig is the BIP-48 path shown above. An xpub does not let anyone spend, but it lets anyone who sees it derive all your addresses and track your balance, so treat it as private, not secret. Do not post it anywhere.

Step 4: create the multisig wallet in the coordinator

In the coordinator, create a new wallet of type multisig, threshold 2, three keys, script type native SegWit (p2wsh). Import the three exported keys. The coordinator will build the descriptor. Check these details:

• The threshold is 2 and the number of keys is 3.
• The script type matches the BIP-48 path you used (p2wsh, path level 2').
• All three fingerprints and derivation paths are present.

Step 5: verify the first address on every device

Ask the coordinator for a receiving address. Then confirm that address on the screen of each hardware device, using the device's own address verification feature, if it has one. Every device must display the same address. If one device shows a different address, stop: something in the setup differs, and you must find it before sending anything. This single check is the best protection against a malicious computer substituting an address.

Step 6: back up the wallet descriptor

This is the step people skip. Export the wallet configuration or descriptor from the coordinator and store several copies, not next to the seeds as the only thing you have, but alongside the device backups in each of the locations. The descriptor reveals all your public keys, so it is private information, though it cannot spend. We explain why it matters in the next section.

Step 7: test with a small amount

Send a small amount to the verified address. Wait for confirmations. Then create a spending transaction in the coordinator, a PSBT, and sign it with two devices. Broadcast it. Confirm the funds arrive. Only after this rehearsal should you move a meaningful amount.

Step 8: rehearse recovery

This is the test that shows whether your documentation works. With a fresh install of the coordinator on a different computer, and using only your written backups, import the descriptor and confirm it shows the same first address and the small remaining balance. If you can do this, you have a recoverable wallet. If you cannot, fix the documentation now, while little is at stake.

Why the descriptor backup matters

In a single-sig wallet, a seed plus a standard path is enough to recover. In a multisig wallet, the three seeds alone are not enough in the general case. To rebuild the addresses the wallet needs the other cosigners' public keys and the script structure: the threshold, the script type, the key order or sorting rule, and the derivation paths. If you lose both the descriptor and the knowledge of those details, you hold keys without knowing which address they control.

It is possible to recover by trial, because with standard choices (BIP-67 sorting, BIP-48 paths, p2wsh) there are only a few combinations, and the three public keys can be re-derived from the three seeds. But that is a stressful job to do after a loss, and it relies on you remembering which standard choices you made. Writing the descriptor down removes the guesswork. Treat the descriptor as the fourth backup item, equal in importance to the seeds.

Keep a one-page procedure with the backups: what the wallet is, the threshold, the script type, the paths, the software and version used, where the other backups are, and how to recover. Write it for a competent stranger. Do not put secrets on that page, and do not put names of people next to amounts.

Spending from a multisig wallet

A spend follows the PSBT flow described in BIP-174 and in Bitcoin Core's documentation:

1. Anyone with the wallet descriptor (the coordinator) creates an unsigned transaction.
2. The transaction is passed to the first device. Read the details on the device screen: the destination address, the amount and the fee. Confirm.
3. The partially signed transaction goes to the second device. Check the details again and confirm.
4. With two signatures collected, the transaction is finalised and broadcast.

Bitcoin Core's guide describes two signing flows, parallel (each signer signs the original and the results are combined) and daisy-chained (each signer signs in turn). It notes that parallel signing may be preferable when there are more signers. For a 2-of-3 wallet either works.

Checking the transaction on each device screen is the point of the whole exercise. A multisig wallet where you click through on a computer without reading the device display loses most of its benefit.

Common mistakes

• Not backing up the descriptor. The most common cause of avoidable recovery trouble.
• Keeping two keys in one place. A fire, a burglary or a flood then defeats the 2-of-3 design.
• Buying three identical devices and storing them together. It removes the manufacturer diversity and the location diversity at once.
• Skipping the address check on each device. This is what protects you from a compromised computer.
• Skipping the test. Send a small amount, spend a small amount, rehearse recovery. Every time.
• Using different derivation paths on different devices without writing it down. The wallet may still work today and be hard to rebuild later.
• Losing track of a passphrase. A forgotten passphrase leads to a different seed and an apparently empty wallet.
• Telling too many people. A multisig is a good defence against a single thief. It is not a defence against people who know where all the keys are.
• Forgetting to update. If you replace a device or move a backup, update the procedure the same day.

Replacing a key later

Keys can be lost or devices retired. In a multisig wallet you cannot simply swap one public key inside the existing address set: the addresses are derived from all three keys, so a new key means a new wallet with new addresses. The method is to create a new multisig wallet with the new set of keys, verify it as above, and then spend from the old wallet to the new one using the usual two signatures. Plan this as a normal maintenance operation, and do it while you still hold at least two good keys.

Privacy and the descriptor

A descriptor or a list of xpubs lets a holder see the wallet's addresses and balance. That is a privacy matter, not a theft matter. Where you store and transmit it should match that. Bitcoin Core's guide itself points out that privacy best practices are not the default in its simple example and that participants should take care to only use the signer for transactions related to the multisig. If privacy matters to you, think about how the coordinator connects to the network (your own node versus a public server) before you load the wallet.

Costs and trade-offs

Multisig has costs that single-sig does not. You need at least three devices instead of one. Each spend needs two device interactions. A multisig spend also carries more signature data than a single-signature spend, which can mean a higher transaction fee, so check current fee levels before you decide how often you will move coins. And the recovery documentation is a real job. These are the price for removing the single point of failure. For some people on some balances it is worth it, and for others it is not.

Multisig is also not the only way to reduce key risk. A single hardware wallet with a carefully stored seed, an optional passphrase and a tested recovery covers many cases. See our guides to hardware wallets and wallet security. If you are new to self-custody, read what Bitcoin is first and master a single-sig wallet before you move to multisig.

Limits of this guide

We read the primary documents cited here on 5 October 2026: BIP-67, BIP-48 and BIP-174 in the Bitcoin Improvement Proposals repository, Bitcoin Core's descriptor documentation and the Sparrow Wallet documentation index and FAQ. We did not test a specific multisig setup with specific devices for this guide, so it contains no device-specific screen instructions. We did not find a dedicated multisig page in the Sparrow documentation index we read, so we do not describe Sparrow's multisig screens. We include no affiliate links and make no recommendation of a particular manufacturer. Always check the vendor's current documentation for the steps on your own devices, and test with a small amount.

FAQ

Is 2-of-3 the best multisig setup?

It is the most common because it tolerates the loss of one key and the compromise of one key at the same time. Other thresholds exist, such as 3-of-5, which tolerate more failures at the price of more complexity. "Best" depends on your situation.

What if I lose the descriptor but still have all keys?

If you used standard choices (BIP-67 sorting, BIP-48 paths and native SegWit), recovery by reconstruction is usually possible but laborious, and depends on remembering those choices. This is why we recommend backing up the descriptor.

Can I use one seed for several keys?

You can, but you should not, because it defeats the purpose. The three keys should come from three independent seeds on three devices.

Do I need my own node?

No, but running your own node improves privacy and reduces trust in third-party servers. It is optional.

Does multisig make my coins safe from every risk?

No. It reduces the risk of a single key being lost or stolen. It does not protect against mistakes in setup, against several keys being compromised together, or against someone who learns where all the keys are.

Is this legal and tax advice?

No. If you have legal or tax questions about holding bitcoin in a particular way in your country, ask a qualified professional there.