MultiSig Backup Maps: Protect Keys and Privacy

The evolution of Bitcoin wallet security has led to increasingly sophisticated solutions, with multisignature (MultiSig) wallets emerging as a robust approach for securing digital assets. A thorough understanding of how MultiSig wallets function, particularly regarding their backup mechanisms and security considerations, is crucial for anyone serious about cryptocurrency security.

MultiSig wallet architectures represent a significant advancement in cryptocurrency security by requiring multiple signatures to authorize transactions. This approach distributes risk and creates redundancy, making it substantially more difficult for attackers to compromise funds. However, the implementation of MultiSig solutions introduces new considerations regarding backup management and privacy that deserve careful attention.

The backup map, also known as the wallet configuration file, serves as a critical component in the MultiSig ecosystem. This file contains essential metadata about the wallet structure, including extended public keys (xpubs), derivation paths, and wallet configuration details. While this information cannot directly compromise funds, its sensitivity from a privacy perspective cannot be overstated. The backup map effectively provides a complete view of the wallet’s structure and transaction history, making it a valuable target for adversaries seeking to understand a user’s financial position.

An example 2-of-3 backup map as Sparrow exports it, one line of text shown here on several: wsh(sortedmulti(2, then three keys of the form [a1b2c3d4/48h/0h/0h/2h]xpub6E.../<0;1>/*, then ))#q8v4nz3k. Six parts are numbered. 1, script type: wsh means native SegWit multisig, with addresses starting bc1q. 2, threshold: 2 signatures, from the 3 keys listed, can spend. 3, master fingerprint: 8 characters that name the seed a key comes from. 4, derivation path: the route from that seed to the key, the BIP 48 standard; 48h is also written 48' with an apostrophe. 5, extended public key, the xpub: this key's part of every receive (0) and change (1) address. 6, checksum: 8 characters that catch a character copied wrong. There is no private key and no seed word, so the map can't sign; it holds every public key, so it can rebuild every address of the wallet. The fingerprints, keys and checksum are example values. — **The backup map is the wallet’s recipe, written in one line.** It names every key by its fingerprint, path and public key, and says how many must sign. With it, any compatible coordinator rebuilds the same wallet (the values here are examples).

Security considerations for MultiSig implementations must balance multiple factors. The primary security mechanism relies on the distribution of private keys across different physical locations or entities, typically in a configuration such as 2-of-3 or 3-of-5 signatures required for transaction authorization. This distribution creates a robust security model that can withstand the compromise of individual key components. However, the backup map introduces an additional element that requires careful management.

The relationship between private keys and the backup map creates an interesting security dynamic. While the backup map alone cannot compromise funds - as it contains no private key material - it does present significant privacy implications. An attacker obtaining the backup map gains visibility into the wallet’s entire transaction history and current balance, which could make the holder a target for physical attacks or social engineering attempts. This is why the backup map needs the same privacy as the seed phrases, even though it can’t move a single coin.

If someone finds one copy of your backup map, they hold your three xpubs, the extended public keys. From them they work out every address of the wallet, past and future, and look each one up on the public blockchain. So they see your balance and every payment in and out. They can't spend: the map holds no private key, so not one coin can move. But they know what you hold, and that can make you a target for physical coercion or scams. The map is a window onto your wallet, not a key: keep every copy as private as a seed. — **The map can’t spend, but it shows everything.** Anyone who reads it can follow every coin the wallet has received or will receive. Give each copy the same privacy as a seed phrase.

Best practices for MultiSig wallet management suggest maintaining multiple copies of the backup map, with common approaches including storing one copy alongside each key holder. This redundancy ensures that the wallet can be reconstructed even if some components are lost, while still maintaining the security benefits of the MultiSig arrangement. Some users choose to store encrypted copies of the backup map in digital formats, including cloud storage, which would be unthinkable for private keys but may be acceptable for backup maps given their limited compromise potential.

Privacy considerations extend beyond just the backup map itself. The entire MultiSig setup process requires careful attention to operational security (OpSec) practices. This includes considering how and where keys are generated, how backups are created and stored, and how the wallet is used in practice. Each interaction with the wallet potentially creates metadata that could be used to track or target the wallet owner.

The technical implementation of MultiSig wallets in software like Sparrow Wallet demonstrates the balance between security and usability. The ability to quickly reconstruct a wallet using the backup map provides important functionality for disaster recovery scenarios, while the requirement for multiple signatures maintains security even if the backup map is compromised. This design shows how careful cryptographic engineering can create systems that are both secure and practical to use.

Advanced users might consider additional security measures such as encrypting the backup map, using secure storage solutions, or implementing complex key rotation schemes. These approaches can further enhance security but must be balanced against the risk of making the system too complex to reliably operate and recover when needed.

Looking forward, the evolution of MultiSig wallet technology continues to advance. New proposals for improving backup mechanisms, enhancing privacy, and simplifying user interfaces while maintaining security are regularly proposed and implemented. The fundamental security model of requiring multiple signatures remains sound, while the surrounding infrastructure continues to mature and improve.

Step-by-Step Guide

Creating, securing, and managing backup maps for a multisig wallet requires a methodical approach. The following steps cover generating the backup map, creating multiple copies in different formats, distributing them across secure locations, and establishing a verification routine.

Generate the backup map from your coordinator software. In Sparrow Wallet, navigate to File > Export Wallet and select the “Output Descriptor” export option. This produces a text file whose first descriptor, under “# Receive and change descriptor”, contains the wallet’s script type (P2WSH for native segwit multisig), the quorum threshold (e.g., 2-of-3), and each cosigner’s extended public key (xpub) with its derivation path and master fingerprint. Save this file to a secure, air-gapped device — not to your everyday computer’s desktop. Each cosigner’s fingerprint in the file should match what its hardware wallet displays, but a fingerprint only names a seed and is easy to fake. To verify the export itself, load the file as a watch-only wallet and check that its first receive address matches the one your hardware wallet shows.
Create an encrypted digital copy of the backup map. Using GPG or an equivalent encryption tool on an air-gapped machine, encrypt the backup map file with a strong passphrase (at least 20 characters, randomly generated). Use symmetric encryption (gpg -c --cipher-algo AES256 wallet_descriptor.txt) so you do not depend on a GPG key pair for decryption. Record the encryption passphrase on a separate piece of durable media (steel plate or laminated paper) and store it independently from the encrypted file. This encrypted copy can safely be stored on a USB drive, microSD card, or even cloud storage — without the passphrase, its contents are unreadable.
Create a paper or steel backup of the backup map’s core information. Write out the following details by hand or stamp them on steel: the wallet script type, the quorum configuration, and each cosigner’s xpub and derivation path. Include each device’s master fingerprint. If you copy the full descriptor line, include the eight characters after the # sign too: they are a checksum, and Sparrow refuses a copy in which a character was copied wrong. This analog backup survives digital media failure, electromagnetic pulses, and software incompatibility. Verify the handwritten or stamped xpubs character by character against the digital export — a single transposed character renders the backup useless for wallet reconstruction.
Register the backup map on each hardware wallet that supports it. Import the wallet descriptor onto each hardware wallet in the multisig quorum that stores it. On Coldcard, use Sparrow’s Coldcard Multisig export (File > Export Wallet) and load that file from the microSD card with Settings > Multisig Wallets > Import; Coldcard rejects the three-descriptor file from step 1. A SeedSigner stores nothing, so you scan the descriptor’s QR code in each session, and a Trezor has no registration: the coordinator sends it the other keys each time. Once registered, each device can independently verify receive and change addresses, providing a second layer of confirmation that the backup map data is correct. If a device rejects the import, first check that you gave it the export format it expects. If it displays different address information than the coordinator software, the backup map file may be corrupted and must be re-exported.
Distribute copies across geographically separated locations. Place one copy of the backup map (encrypted digital + paper/steel) alongside each seed phrase backup. For a 2-of-3 setup with keys stored in three locations, each location should contain: one seed phrase, one encrypted copy of the backup map on USB or microSD, and one paper or steel copy of the backup map. This distribution ensures that anyone accessing two locations (the minimum needed to sign) also has the backup map needed to reconstruct the wallet in coordinator software.
Establish a verification and rotation schedule. Every 6-12 months, visit each storage location and verify that the backup media is intact and readable. Insert USB drives and microSD cards into a reader to confirm the files are accessible. Decrypt the encrypted copy with the stored passphrase to verify the passphrase is correct and the file is uncorrupted. Check steel or paper backups for legibility. If any copy shows signs of degradation, create a fresh copy immediately. This routine catches problems before you face an actual recovery scenario.
Document the backup map locations in a sealed guide for your estate. Create a written document — stored in a location accessible to your heirs or estate executor — that describes what the backup map is, where each copy is stored, and the general process for wallet reconstruction. This document should not contain seed phrases, encryption passphrases, or xpubs. It should only contain enough information for a technically capable person to locate and assemble the pieces needed for recovery. Seal this document and instruct your executor on when and how to open it.

Common Mistakes to Avoid

Treating the backup map as less sensitive than seed phrases

While the backup map cannot be used to steal funds directly, it reveals your complete wallet balance, transaction history, and all current and future addresses. An attacker with this information knows exactly how much bitcoin you hold and can target you for physical coercion or social engineering. Treat the backup map with the same physical security protocols you use for seed phrases — locked safes, tamper-evident packaging, and access controls — even though the threat model differs.

Storing all backup map copies in a single location

If all copies of the backup map are in your home and your home is destroyed by fire, flood, or burglary, you may lose the ability to reconstruct the wallet in coordinator software. First look for a working copy that survived elsewhere: a Coldcard you registered the wallet on in step 4 can export the full descriptor, with every cosigner’s xpub (Settings > Multisig Wallets > your wallet > Descriptors), and so can a coordinator on a computer kept outside the house. If no copy survived, you can rebuild the wallet only if you still have every seed phrase: you would need to manually re-derive each cosigner’s xpub from its seed phrase using the correct derivation path — a process that requires precise technical knowledge and is error-prone under pressure. If one seed phrase was kept in the same home, its xpub is gone with it, and it can’t be worked out from the other two seeds: two seeds alone can’t find or spend your coins, even though two signatures would be enough. Geographic distribution of backup copies eliminates this single-point-of-failure scenario.

A fire destroys your home, where seed A was kept. Seed B is in a bank vault and seed C at a relative's. First plan, every copy of the backup map kept at home: all three copies burn with seed A. You still have seeds B and C but no map. Two signatures would be enough, but key A's xpub burned with the maps, and it can't be worked out from seeds B and C; without it, no software can rebuild your addresses, so your coins can't be found or spent. Second plan, a map copy kept with each seed: the home copy burns, but you still have seeds B and C and a map copy. Either surviving copy lists all three xpubs, so any coordinator rebuilds the wallet and finds the coins, and B and C sign. Two seeds can spend only with the map: keep a copy with every seed. — **Keep every map copy at home and one fire can lock your coins away.** Every address is built from all three xpubs, and key A’s can’t be worked out from seeds B and C. With a copy beside each seed, any two places hold two seeds and the map.

Relying solely on the coordinator software to store the wallet configuration

Sparrow Wallet, Specter Desktop, and similar coordinators store the wallet configuration on your computer’s hard drive. If that drive fails, gets stolen, or the software is uninstalled, the wallet configuration is lost from that instance. The coordinator is not a backup — it is a working copy. The backup map exists precisely to reconstruct the wallet in any compatible coordinator on any computer. Always maintain independent copies of the backup map outside of the coordinator software.

Using an unencrypted backup map on cloud storage

Uploading an unencrypted wallet descriptor to Google Drive, Dropbox, iCloud, or similar services exposes your complete wallet structure to anyone who gains access to your cloud account — through phishing, credential stuffing, or a data breach at the cloud provider. If you store the backup map in the cloud, encrypt it with a strong passphrase first. The encrypted file is safe to store anywhere, as long as the passphrase is stored separately on physical media that you control.

Someone breaks into your cloud account. With a plain copy of the backup map, they read the map, from wsh(sortedmulti(2, onwards, and see your whole wallet and balance. With an encrypted copy, they get scrambled bytes, useless without the passphrase. And you, with both pieces, the encrypted file plus the passphrase written on paper or steel and kept elsewhere, get the map back in a coordinator; test it by decrypting it each time you check your copies. Encrypt any digital copy, and keep the passphrase away from it. Seed words never go digital, encrypted or not: only paper or metal. — **An encrypted copy is only as private as its passphrase is separate.** A file encrypted with GPG and a strong passphrase can sit on a USB stick or in the cloud. Write the passphrase on paper or steel and store it somewhere else.

Failing to verify backup map copies after creation

Creating a backup and assuming it is correct without verification is a common source of recovery failures. After writing each copy of the backup map, verify it by importing it into a coordinator on a separate device, kept offline so no server sees the wallet, and confirming that the first receive address it shows matches the one on your hardware wallet. Delete that test wallet when you are done. For paper or steel backups, compare every character of every xpub against the verified digital source. A single wrong character in an xpub makes the entire backup map invalid for wallet reconstruction.

Before you rely on a copy of the backup map, check it in three steps. 1, load it as a watch-only wallet: paste or import it into Sparrow on another computer, with Sparrow offline so no server sees your wallet; a watch-only wallet holds no keys, so nothing can move. 2, the checksum checks every character: a correct copy ending #q8v4nz3k is accepted; a copy with one character wrong, here an E copied as F inside an xpub, no longer matches its checksum and is refused. Copy the 8 characters after the # too. 3, compare the first receive address in Sparrow with the one your hardware wallet shows: the same address means this copy works. Check every copy when you make it, and again every 6 to 12 months. — **Test each copy, and you know it works.** Sparrow refuses a descriptor whose checksum doesn’t match, so a character copied wrong shows up at once. A first address that matches your device proves the copy rebuilds your wallet.

Frequently Asked Questions

What exactly does the backup map contain, and can it be used to steal my bitcoin?

The backup map (wallet output descriptor) contains the wallet script type, quorum threshold (e.g., 2-of-3), and each cosigner’s extended public key (xpub) with derivation path and master fingerprint. It does not contain any private keys or seed phrases. An attacker with only the backup map cannot sign transactions or move funds. However, they can derive all past and future wallet addresses, view the complete transaction history, and determine the total wallet balance. This privacy exposure can make you a target, which is why the backup map deserves physical security protections even though it cannot directly compromise funds.

How many copies of the backup map should I keep?

For a 2-of-3 multisig, maintaining three copies — one alongside each seed phrase — is the standard recommendation. This ensures that any combination of two locations (which is the minimum needed to meet the signing threshold) also includes at least one copy of the backup map. Some users keep a fourth encrypted copy in a separate location or on encrypted cloud storage for additional redundancy. The trade-off is between recovery resilience (more copies) and privacy exposure (each copy is a potential leak). Three copies in secure, distributed locations satisfies most threat models.

Can I reconstruct my wallet without the backup map if I have all the seed phrases?

Technically yes, but the process is significantly more difficult. You would need to know the exact derivation path used for each cosigner, the script type (P2WSH, P2SH-P2WSH), the threshold (for example 2 of 3) and, if your coordinator didn’t sort the keys, the order in which they were listed. If you used standard derivation paths and a well-known coordinator, an experienced user can reconstruct the wallet by deriving xpubs from each seed and manually building the descriptor. If you used non-standard paths, custom configurations, or cannot remember the exact setup parameters, reconstruction becomes extremely difficult or impossible. The backup map eliminates this entire problem.

Should the backup map be stored on the same steel plate as the seed phrase?

Storing both on the same plate means that anyone who finds the plate has both the seed phrase and the backup map, which together reveal one key and the full wallet structure. For a 2-of-3 setup, this is acceptable because a single seed phrase plus the backup map is not sufficient to spend funds — you still need a second seed phrase from a different location. However, if you prefer maximum separation of concerns, store the backup map on a separate plate or medium from the seed phrase, even if they are in the same physical location. This adds a small amount of defense against a targeted search of a single location.

Do I need to update the backup map if I receive more bitcoin to the wallet?

No. The backup map describes the wallet’s structure — its script type, quorum, and cosigner xpubs — not its balance or transaction history. Receiving bitcoin to the wallet does not change any of these parameters. The backup map remains valid indefinitely as long as you do not change the wallet’s quorum configuration or replace cosigner devices with new seed phrases. If you do change the quorum or replace a cosigner with a new seed phrase, you are making a new wallet, and it needs its own backup map. Your coins stay in the old wallet until a transaction signed with the old keys moves them, so keep the old map and enough old seeds to sign at least until that transfer has confirmed.

Related Resources

Part of our free Bitcoin course: This topic is covered in Multisig Wallets Explained: 2-of-3 Security With Multiple Keys, from the Advanced Bitcoin Security & Privacy course.

Filed under: Bitcoin Privacy