Skip to Content
DocumentationReal-world guidesBitcoin workflowsCreate, sign and recover a Bitcoin multisig wallet

Create, sign and recover a Bitcoin multisig wallet

A two-of-three policy needs two distinct signing keys, not two copies of one recovery phrase. Mixed devices can reduce dependence on one implementation but add script, policy and transport compatibility work. Rehearse with independent practice signers before receiving meaningful funds.

Watch the overview: Build a multisig wallet.

Before you start

Use Sparrow as coordinator and follow each signer’s documented setup. The Desktop-assisted KeepKey route requires a build with Bitcoin multisig co-signing, enabled in Settings → Feature Flags, and a supported script/policy. Desktop contributes KeepKey public cosigner information and signs a matching checked policy; it does not control the other hardware wallets.

Choose a signing policy

Watch this step.

  1. A single-signature wallet needs one signing key. A two-of-three multisig wallet needs two distinct signer keys for each spend. Three devices carrying the same recovery phrase are copies of one key, not three independent signers.
  2. Record signer access, backup locations, and the approval process. A policy that prevents theft but cannot survive ordinary loss can still lose access permanently. Check that the planned quorum is actually reachable.
  3. Mixed hardware can reduce dependence on one implementation, while adding compatibility and operational work. Check the exact script type, key origins, wallet-policy handling, and signing transport supported by each device before committing funds.
  4. Use Sparrow to coordinate the mixed-device wallet. Desktop can contribute the connected KeepKey’s public cosigner information and co-sign a matching enrolled policy; it does not operate the other hardware wallets for you.
  5. Rehearse setup, address comparison, signing, and recovery with a separate practice wallet first. Choose the simpler policy if you cannot reliably perform those checks. Keep the public configuration as well as each signer’s recovery material.

Create a mixed-device policy

Watch this step.

  1. Prepare three independent practice signers and protected backups. Create a new Sparrow wallet with a two-of-three multisignature policy. Choose one script type supported by every participant.
  2. For the Desktop-assisted KeepKey route, enable Bitcoin multisig co-signing in Settings, then open Multisig co-signing. Select the matching script type and account. Read the public key and copy its key-with-origin information.
  3. Import that public cosigner into Sparrow’s intended keystore. Add the other two using their documented hardware or public-key import routes. Close competing applications before connecting a USB signer. Never type recovery words into the coordinator.
  4. Compare all three master fingerprints, full public keys, and derivation paths against the intended signer accounts. Check the threshold and script type again. Different account paths can produce a different wallet even on the same device.
  5. Apply the configuration and protect the wallet file. Preserve Sparrow’s complete output descriptor with every cosigner’s public information. Continue to cross-checking addresses and Desktop policy import before receiving funds; an assembled configuration is not a completed verification.

Verify the multisig configuration

Watch this step.

  1. Inspect Sparrow’s threshold, script type, and all cosigner accounts. Compare every fingerprint, full public key, and derivation path with its intended source. A fingerprint alone does not establish a matching key.
  2. Copy the complete public output descriptor into Desktop’s Multisig co-signing panel. Select Check policy. Desktop matches both the connected KeepKey’s fingerprint and its derived account public key, and rejects a conflicting origin or unsupported policy.
  3. Compare Desktop’s first receive address with Sparrow. Choose Verify address on KeepKey and save, then compare the full physical address before approving. Stop on any mismatch.
  4. Desktop saves this checked public policy on the host for normal wallets. Passphrase-wallet policies are session-only. This operation confirms a derived address; it does not claim that KeepKey displays or persistently registers the complete policy text.
  5. Follow each other signer’s documented policy-registration and address-verification procedure where supported. Compare additional receive and change addresses using independent derivation. Preserve the checked descriptor and repeat verification after changing any signer, origin, script, or threshold.

Sign a two-of-three payment

Watch this step.

  1. In the verified practice wallet, prepare the intended payment in Sparrow. Check recipients, amounts, change, and fee. Export a PSBT with the full previous transactions and cosigner key origins required by Desktop’s co-signing checks.
  2. Open the PSBT in Desktop with the matching policy already checked. Review its outputs, fee, and signature counts per input. Desktop refuses conflicting policy data or invalid existing signatures before asking KeepKey to sign.
  3. Read the actual recipient and amount prompts on KeepKey and approve only the intended payment. Desktop verifies the returned signatures against the reviewed transaction, then saves a signed PSBT. One signer’s approval does not satisfy a two-key quorum.
  4. Return that file to Sparrow and obtain the second independent signer’s approval through its documented route. Check the same transaction again on that device. Keep the first signature; changing recipients or amounts requires a fresh review and signing round.
  5. Require two valid signer signatures for every input, then review Sparrow’s completed transaction. Completion and broadcast are separate actions. Check the final recipient, fee, and change.

Combine signing transports

Watch this step.

  1. Sparrow holds one public configuration and proposed transaction. Signers can receive it through different transports. Compatibility depends on each device’s script, PSBT, and QR support.
  2. KeepKey connects by USB to its signing computer. Desktop reviews and co-signs the PSBT, then returns the file. A thumb drive connects the computer workflows; KeepKey has no native camera or removable-media signing interface.
  3. For a QR-capable signer, follow that vendor’s Sparrow workflow and use its supported encoding. Read the device’s physical transaction details before approving, then scan the signed result back into the same coordinator wallet.
  4. For a removable-media signer, export the appropriate PSBT, approve it on that device, and return the signed file. Treat both scanners and media as input surfaces; an offline transport does not make malicious transaction content harmless.
  5. After every import, confirm the unchanged transaction and verified signatures per input. Preserve previous signatures while collecting the next signer. If formats are incompatible, stop and resolve support rather than weakening policy checks to force the exchange.

Back up the complete wallet

Watch this step.

  1. Preserve the configuration: threshold, script type, key ordering, and every cosigner’s public key, fingerprint, and derivation path. A threshold number of recovery phrases alone is insufficient.
  2. Export the wallet descriptor from Sparrow and keep protected copies with your recovery plan. Desktop can also export its checked public policy. These files cannot sign alone, but they can reveal wallet activity and should remain private.
  3. Back up each independent signer using that device’s documented procedure. Include any required passphrase in a separate, deliberate plan. Keep enough signers and recovery material in separate locations so one incident does not destroy the quorum.
  4. Do not combine all recovery words in a coordinator file or support message. Record which backup belongs to which public cosigner without exposing the secret itself. Two copies of one signer still represent only one signing key.
  5. Reconstruct the public wallet on a clean practice setup and compare receive and change addresses. Rehearse signer recovery using practice secrets. A saved file becomes a tested recovery only when these checks agree.

Recover with one signer unavailable

Watch this step.

  1. Confirm the original policy is two of three and two independent keys remain accessible. Two of two has a different limit. A copied backup is not an additional signer.
  2. Restore the complete public configuration in Sparrow, including the unavailable signer’s public key and origin. The missing device does not mean its public cosigner can be deleted: that key remains part of the scripts controlling the existing funds.
  3. Compare expected receive and change addresses before preparing a transaction. Verify the remaining devices match their intended public accounts and passphrase choices. A different account can look healthy while belonging to another wallet entirely.
  4. Prepare a practice PSBT in the restored wallet and collect signatures from the two available signers. Keep every approval on the same transaction. Desktop’s KeepKey route still requires its matching checked policy and complete previous-transaction information.
  5. Require the threshold on every input. If it cannot be met, stop: changing the coordinator’s displayed number cannot unlock old outputs. The replacement lesson applies when the original quorum can authorize migration.

Replace a multisig signer

Watch this step.

  1. Editing the coordinator cannot change already-funded scripts. Existing outputs retain their original policy. Keep its complete configuration and enough original signer keys until any migration is confirmed.
  2. Prepare a replacement signer using its documented setup and backup procedure. If a key may be compromised, use independent new key material. Restoring the same exposed recovery phrase onto new hardware does not replace that signing key.
  3. Create a new public policy in Sparrow using the intended participants, threshold, and compatible script type. Cross-check every key origin and supported device policy. Import and verify the new policy separately in Desktop if KeepKey will co-sign it.
  4. Verify the new receiving address on the participating hardware using each device’s supported procedure. Rehearse a small practice receive and spend before migrating larger holdings. The new policy’s address will differ because its controlling keys changed.
  5. The old wallet’s valid quorum must authorize migration to the verified new address. Track submission and confirmation separately. A replacement key alone cannot spend outputs without the original threshold.

Check multisig signing failures

Watch this step.

  1. Match the original policy: network, script, threshold, every cosigner key, and each origin. Check the intended account and passphrase. The right device can still present the wrong wallet.
  2. Check verified signature counts on every input. Two files or repeated approvals from one key do not satisfy a two-key threshold. Every input needs its own quorum.
  3. Keep the same unsigned transaction when combining results. Changing a recipient, amount, fee, input, or other signed field can invalidate earlier signatures. Return to the reviewed original PSBT or begin a clearly identified new signing round.
  4. Desktop requires full previous transactions, matching cosigner origins, and supported signature rules for this co-signing route. It rejects invalid existing signatures or conflicting scripts. Supply correct public transaction data from the coordinator rather than disabling these checks.
  5. If KeepKey already signed, or the quorum is present, return the PSBT to Sparrow for combination or final review. Complete is not broadcast or confirmed. Keep diagnostic records private and recovery material offline.

Verify the result

Compare every cosigner’s full public key, fingerprint and origin, threshold, script type and key ordering. Verify derived receive/change addresses. On spending, require verified signatures meeting the threshold on every input and inspect the final transaction before any separate broadcast.

If something fails

Preserve the complete public configuration and the original transaction files. A signature from the same key twice is not another signer. Do not remove an unavailable cosigner from a funded wallet or change the threshold in the UI to bypass its original policy. Recovery and signer replacement require the original quorum.

Last updated on
Understand Bitcoin servers and statusCheck, stop and recover a Bitcoin workflow