Bitcoin Security

Multisig Xpub Verification: Security Guide

Jan 29, 2024 · 17 min read · Updated Latest correction
Two hands compare matching three-hole translucent acrylic cards over a walnut desk.

A multisig wallet spreads control of your bitcoin over several keys, usually on separate hardware wallets, so that no single lost or stolen device can cost you everything. Coordinator software on your computer builds the wallet from each device’s extended public key (xpub), a read-only key, and calculates the wallet’s receiving addresses from all of them together. Whose keys end up in the wallet depends on the xpubs it receives at setup.

If malware on that computer swaps one of those xpubs for its own, you end up with a wallet in which an attacker holds one of the keys you believe are yours, and nothing looks wrong. The defence is to check every key where malware can’t reach it: on each hardware wallet’s own screen. This guide shows how in eight steps, then covers the mistakes that undo the check and what to do when something doesn’t match.

Two 2-of-3 wallets side by side. The one you meant to build holds your keys 1, 2 and 3. The one malware built while you set it up holds keys 1 and 2 and an attacker's key. Day to day both work the same: keys 1 and 2 sign, so nothing looks wrong, but in the swapped one key 3 no longer counts. If you lose one key, meaning its device and its backup are both gone, your own wallet still spends with the other two, but in the swapped one losing key 1 or 2 leaves a single key that needs the attacker's to spend. If the attacker gets one of your keys, from a stolen device or a found seed, they still can't spend from your own wallet, but in the swapped one key 1 or 2 plus theirs make two. If malware swaps two xpubs, the attacker can spend alone.
A swapped xpub hides until something goes wrong. The wallet spends normally with keys 1 and 2, but key 3 no longer counts: lose key 1 or 2 and you’re stuck, and the attacker needs only one of them. That’s why each key is checked on its own device.

Step-by-Step Guide

Work through the eight steps for every hardware wallet in the setup before any money goes in. Steps 3 and 5 compare keys, Step 6 is the check that malware on your computer can’t fake (the same address and the same policy, such as 2 of 3, on every device), Step 7 proves that each device can sign, and Step 8 keeps the wallet recoverable if a seed is ever lost.

Step 1: Initialize each hardware wallet independently. Before creating the multisig wallet, ensure each hardware device has been initialized with its own unique seed phrase in a secure, offline environment. Power on the device, follow the manufacturer’s setup wizard, and record the seed phrase on a durable medium such as a steel plate. Never generate seeds on a computer or use pre-generated seeds from any source.

Step 2: Export xpubs directly from each hardware device. Find the device’s extended public key export function; the menu varies by maker, so follow the maker’s own guide. The device’s own screen should show the full xpub string and, next to it, the derivation path it comes from (for example m/48'/0'/0'/2', the standard BIP 48 path for native SegWit multisig). The path isn’t part of the xpub string itself.

Step 3: Record the xpub and master fingerprint from the device display. Write down the xpub exactly as it appears on the hardware wallet’s trusted screen (a phone photo can end up in a cloud backup). Note the master key fingerprint — an 8-character hexadecimal identifier worked out from each seed (and its passphrase, if you use one). This fingerprint serves as a quick cross-reference to confirm which device produced which xpub during future verification rounds, but it can’t prove that the xpub next to it is genuine: malware can show your fingerprint beside its own key.

Step 4: Import xpubs into your multisig coordinator software. Using a coordinator application such as Sparrow Wallet, Electrum, or Nunchuk, create a new multisig wallet and import each xpub. The software will display the imported xpubs along with their derivation paths and fingerprints. At this stage, do not yet send any funds to the wallet.

Step 5: Cross-verify each xpub on its corresponding hardware device. For each hardware wallet, use the device’s “show xpub” feature to confirm that the xpub displayed in your coordinator software matches exactly what the hardware device shows on its own secure screen. Compare the whole string, character by character. Matching ends aren’t enough: the first 16 or so characters only encode labels (key type, depth, position and a tag of the parent key) that malware can copy, and the last 8 can be forced to match with enough computing power. Compare keys written in the same format: some devices and apps write a native SegWit multisig key as a Zpub, and the Zpub and xpub of the same key differ in almost every character. A match here still leaves one gap, because malware can show you your genuine xpub while building the wallet with its own. Step 6 closes it.

Two xpubs shown in full. The first is on your hardware wallet's screen: key 1 at the path m/48'/0'/0'/2', starting xpub6DkFAXWQ2dHxq2vatrt9. The second is on your computer after malware swapped it: an attacker's key with your labels copied, starting xpub6DkFAXWQ2dHxpq8KUj67. The first 16 characters are identical, because they only label the key: its type, depth, position and a tag of the key above it, which malware can copy for free. The rest is the key itself and differs. Making the last 8 characters match as well takes a lot of computing, but it can be done. Compare every character, then check that every device shows the same first address.
A matching start proves nothing. An xpub opens with labels that anyone can copy, so a swapped key can look right at a glance. Compare every character, then let the devices check the address in Step 6.

Step 6: Generate and verify a receive address. First make sure every device knows the whole wallet: on Coldcard, Passport and Keystone you load the descriptor once, which is called registering it, while a Trezor receives the other keys from the coordinator with each request (the multisig in practice lesson shows how for each device). Then generate the first receive address in the coordinator and display it on each hardware device with its “verify address” feature for multisig. Each device works the address out itself from the keys it was given, so every one of them must show the same address as the coordinator. A device whose own key is missing from the wallet refuses: a Coldcard won’t register such a wallet, and a Trezor won’t show its address. That’s how the device whose xpub was swapped out gives the attack away, so check on all of them. Matching addresses don’t catch everything, though: malware that keeps all your keys but adds one of its own, or lowers the threshold, still gets the same address on every device. So also check that each device shows the policy you chose, such as 2 of 3, when you register the wallet or show the address.

Step 6 on the wallet malware built from keys 1 and 2 and the attacker's key. The coordinator on your computer shows its first address. Device 1, whose key is in the wallet, works the address out itself and shows the same one, so it looks fine; so does device 2. Device 3, whose key was swapped out, can't find its own key and refuses, and that exposes the swap. Check the address on all three devices: a Coldcard won't register such a wallet and a Trezor won't show its address.
The device that was swapped out is the one that objects. Devices 1 and 2 agree with the coordinator, because their keys are still in the wallet. Only device 3 refuses, so a check on two devices can miss the swap.

Step 7: Perform a test transaction. Send a small amount of bitcoin to the verified receive address. Then initiate a spend from the multisig wallet, signing with the required number of devices. In a 2-of-3, a spend uses only two devices, so make a second small spend with a different pair to test the third. This end-to-end test confirms that the wallet is fully operational and that each hardware device can correctly participate in transaction signing. Only after this successful test should you deposit larger amounts.

A grid of four checks against three problems. The problems: a mix-up (the wrong device, seed or passphrase), a swapped key (malware put its own xpub in) and a device that can't sign (a firmware bug or a wrong setting). Step 3, the fingerprints match: catches a mix-up, but not a swapped key, because malware can copy your fingerprint, and not a device that can't sign. Step 5, the whole xpub matches on the device and in the coordinator: catches a mix-up, but a swapped key only sometimes, because malware can show your genuine xpub on the computer's screen. Step 6, the same first receive address on every device: catches a mix-up and a swapped key, because each device works the address out itself. Step 7, a small test spend signed by two of the three devices: catches a device that can't sign, but only for the two that sign; it catches a mix-up or a swapped key only if that device is one of the two that sign. Step 6 catches a swapped key before any money goes in; only a spend shows that a device can sign, so test each one.
Each step catches a different problem. The fingerprint catches mix-ups, the address on every device catches a swapped key before any money goes in, even if malware fakes the computer’s screen, and only a spend proves that a device can sign.

Step 8: Back up the wallet descriptor and configuration file. Export the multisig wallet descriptor (a BSMS file, the BIP 129 standard, or a descriptor export such as Bitcoin Core’s JSON listdescriptors output) and store a copy with each seed phrase backup. This descriptor contains all xpubs, derivation paths, the script type and the quorum threshold. If one seed is ever lost, that key’s xpub can’t be recalculated from the others, and without the descriptor the remaining seeds can sign but can’t find your coins.

Seed C of a 2-of-3 wallet is lost. Seed A gives xpub A and seed B gives xpub B, but xpub C can't be worked out from either of them. Without the descriptor, seeds A and B can sign, but your coins can't be found, because the addresses need all three xpubs. With a copy of the descriptor, which records 2 of 3, native SegWit, the path m/48'/0'/0'/2' and xpubs A, B and C, the wallet is rebuilt and seeds A and B sign. Keep a copy of the descriptor with every seed backup, so any two places together hold two seeds and the descriptor.
Two seeds can sign, but they can’t find your coins. The lost key’s xpub can’t be calculated from the other two seeds. The descriptor records it, so a copy goes with every seed backup.

Common Mistakes to Avoid

1. Trusting software-displayed xpubs without hardware verification. The most dangerous mistake is accepting xpubs shown only on your computer screen without confirming them on each hardware device’s secure display. Malware on your computer could substitute an attacker’s xpub, giving them one of the required keys in your multisig quorum. Always verify on the device itself.

2. Skipping the master fingerprint comparison. Each seed (with its passphrase, if you use one) has its own master key fingerprint. When setting up or restoring a multisig wallet, failing to compare fingerprints between the coordinator software and the hardware device can lead to using the wrong key without realizing it. This mistake often surfaces only when attempting to sign a transaction, at which point funds may already be at risk.

3. Assuming every wallet app uses the same derivation path. Different coordinator applications may default to different derivation paths for multisig (e.g., m/45' vs m/48'/0'/0'/2'). If you switch coordinator software or attempt recovery using a different application, mismatched derivation paths will generate different xpubs from the same seed, making the wallet appear empty or inaccessible (the address types and derivation paths lesson explains why).

One seed, with master fingerprint 73c5da0a, followed down three derivation paths. m/45' (BIP 45) gives xpub68jrRzQopSUS…; m/48'/0'/0'/2' (BIP 48, the path used at setup) gives xpub6DkFAXWQ2dHx…; m/87'/0'/0' (BIP 87) gives xpub6DBjiYnc4ewK…. Each xpub leads to different addresses (BIP 45 wallets also use an older address type, starting with 3). Only the path used at setup finds your coins; the other two wallets look empty. The fingerprint is the same on every path, so it can't tell them apart. The descriptor records the path, so import it instead of rebuilding by hand.
Same seed, different path, different wallet. A coordinator that uses another path builds other xpubs and other addresses, and the wallet looks empty. The descriptor records the path, so nothing has to be guessed.

4. Failing to back up the wallet configuration file. Many users back up their seed phrases diligently but neglect to store the multisig wallet descriptor. Without this file, reconstructing the wallet requires knowing every xpub, the exact derivation paths, the script type, and the quorum structure — information you must reproduce exactly even with every seed. Once one seed is lost, its xpub can’t be recalculated, so it has to come from a copy you kept, such as your Step 3 notes.

5. Not performing a full send-and-spend test before depositing significant funds. Generating an address and receiving bitcoin proves nothing about your ability to spend from the wallet. Hardware devices may accept xpub imports but fail during signing due to firmware bugs, incorrect configurations, or path mismatches. A complete test transaction is the only reliable way to verify end-to-end functionality.

Frequently Asked Questions

What happens if one of my hardware wallets displays a different xpub than expected?

If a hardware wallet displays an xpub that does not match what your coordinator software shows, first check that both screens use the same format: the xpub and Zpub of the same key look completely different. If the formats match, stop the setup process immediately. This discrepancy could indicate compromised software on your computer, an incorrect derivation path configuration, or in rare cases a firmware issue on the device. Re-download your coordinator software from the official source, verify its signature, and restart the xpub import process on a computer you trust. Reinstalling only the app won’t clean an infected computer, so use another computer or reinstall this one’s operating system first. If the mismatch persists on that computer, check that the derivation path in the coordinator exactly matches the path the hardware device is using for export. Different BIP standards (BIP-45, BIP-48, BIP-87) use different derivation paths, and mixing them will produce different xpubs from the same seed.

Can I verify xpubs if my hardware wallet does not have a dedicated multisig verification feature?

Some older or simpler hardware wallets lack native multisig address verification. In this case, you can still verify the xpub by comparing it character-by-character between the device’s export screen and the coordinator software. However, you will not be able to verify receive addresses on-device for the multisig wallet specifically. This represents a reduced security model — consider upgrading to a device that supports full multisig verification, such as a Coldcard, Keystone, or recent Trezor firmware that includes this capability.

How often should I re-verify my multisig xpubs after initial setup?

Re-verification is recommended whenever you update your coordinator software, upgrade hardware wallet firmware, or restore the wallet configuration on a new computer. As a general practice, performing a quarterly verification — confirming that a test address generated by the coordinator matches what each hardware device displays — provides ongoing assurance that no configuration drift has occurred. This is especially important for large holdings or institutional custody arrangements where the cost of a security failure is high.

Is it safe to share my xpubs with other multisig participants?

Xpubs are less sensitive than private keys, but they are not public information in the same way a single Bitcoin address is. Whoever holds all the xpubs of a multisig wallet, which is exactly what the descriptor contains, can calculate every past and future address and so see your whole balance and history. In a collaborative multisig arrangement, sharing xpubs with co-signers is necessary for wallet creation, so each co-signer can see the whole wallet; treat this data as confidential. Transmit xpubs through encrypted channels and avoid storing them in cloud services or email.

Related Resources

Part of our free Bitcoin course: This topic is covered in Multisig in Practice: Sparrow, Nunchuk, Casa and Unchained, from the Advanced Bitcoin Security & Privacy course.
Filed under: Bitcoin Security

Continue Reading

← Back to All Articles