Timechain Wiki

Multisig setups

17 min read

A multisig wallet requires multiple signatures from independent keys to move funds — a 2-of-3 wallet has three keys, any two of which can spend; a 3-of-5 has five keys, any three of which can spend. Multisig is the first cleanly-engineered answer to the loss-vs-exposure trade-off problem: it tolerates the loss or theft of any single key without catastrophe. 2-of-3 is the right configuration for most individuals and businesses; 3-of-5 is overkill for most holders and right only for a small minority whose threat model genuinely demands it. DIY 2-of-3 — all three keys held by the operator, distributed geographically with vendor-diverse hardware wallets — is the sovereign approach; collaborative 2-of-3, where a partner holds one key (see Collaborative custody services), is the complexity-reduced alternative. This note treats DIY multisig: vendor diversity as cheap insurance, geographic distribution as prerequisite, the six-items-to-manage problem, the descriptor as first-class backup artifact, re-keying mechanics, and the 2-of-3 vs 3-of-5 considerations. It operationalizes Configuration 4 (DIY 2-of-3) and Configuration 6 (3-of-5) from the Self-custody configuration ladder.

Why this note matters

Multisig is the most-misunderstood configuration in the ladder. The structural protection is real and substantial — but the operational complexity it introduces is the dominant cause of self-inflicted Bitcoin loss for holders who adopt it without the discipline to sustain it. The note matters because:

  • It establishes the specific operational discipline DIY multisig requires. The cryptography is the easy part; the human-and-process layer is where most failures occur.
  • It surfaces the 2-of-3 vs 3-of-5 question the synthesis treats with unusual sharpness — and the synthesis’s clear preference for 2-of-3 for most holders.
  • It anchors vendor diversity, geographic distribution, and descriptor backup as non-negotiable elements rather than optional features.

The defensible position: DIY multisig is the right configuration for holders whose holdings justify it AND who have the operational discipline to sustain it AND who have planned for the inheritance complexity it introduces. For holders who lack any of these, collaborative custody (see Collaborative custody services) or single-sig with strong discipline is structurally safer.

What this is

A multisig wallet is one where the spending condition is “M of N keys must sign” rather than “one key must sign.” The math is implemented at the Bitcoin protocol level (P2WSH for native-SegWit multisig; P2TR for Taproot multisig) — the blockchain enforces the multisig rule, not any specific wallet software.

The numbers have intuitive names:

  • Threshold (M) — the minimum number of signatures required
  • Total (N) — the total number of keys in the wallet
  • Quorum — the combination M-of-N (the most common configurations are 2-of-3 and 3-of-5)

Each key is an independent cryptographic key, generated on a separate hardware wallet. The keys are never combined; signatures are aggregated at the transaction level via PSBT (see PSBT and wallet descriptors).

The structural protection: no single key is sufficient to spend. A 2-of-3 multisig tolerates the loss or compromise of any one key. A 3-of-5 tolerates the loss or compromise of any two.

This is a strictly different problem from single-sig. In single-sig the question is “protect one thing very well.” In multisig the question is “protect several things reasonably, and do not let any two become compromised simultaneously.” For most holders the second problem is structurally easier than the first.

When to use this

DIY 2-of-3 multisig is appropriate when:

  • Holdings are Tier 2 or higher ($50K+; threshold varies with threat model)
  • The holder has operational discipline for managing six sensitive items (three hardware wallets + three seed backups) plus the descriptor and coordinator state
  • Geographic distribution is genuinely possible — at least two and ideally three distinct secure locations
  • The holder has planned for inheritance with the multisig complexity in mind (heirs need keys, descriptor, knowledge of coordinator software, and at least passing familiarity with PSBT)
  • The holder values sovereignty specifically — no third party in the loop

DIY 2-of-3 is not appropriate when:

  • Holdings are Tier 1 or smaller (complexity dominates the benefit)
  • The holder lacks operational discipline for the six-item management
  • Geographic distribution is impractical (all keys end up co-located, defeating the purpose)
  • Inheritance planning for multisig is too complex for the realistic heirs

For holders who want multisig’s structural protection but lack one of the prerequisites above, Collaborative custody services is the right alternative.

3-of-5 multisig is appropriate when:

  • The holder has specific reasons that 2-of-3 fault tolerance is insufficient — typically Tier 3 holdings with multiple jurisdictional or family-branch considerations
  • The holder has the operational capacity for eight items (five keys + minimum-three-seed backups required for quorum recovery + the descriptor)
  • The holder has already operated a 2-of-3 multisig successfully — adopting 3-of-5 as a first multisig is high-risk

For most individuals, 3-of-5 fails the complexity test. The synthesis is direct: it is the right answer for a small minority of holders whose threat model genuinely demands it.

How DIY 2-of-3 works in practice

Setup

  1. Acquire three hardware wallets from different vendors. The canonical pattern: one Coldcard + one BitBox02 + one Foundation Passport (or substitute Trezor for one of these). Vendor diversity is the central discipline. See Hardware wallets overview for the device-selection framework.

  2. Initialize each device independently. Each generates its own seed; record each on metal backup; verify each. Treat each seed as a load-bearing artifact for the wallet.

  3. Plan the geographic distribution. Common patterns:

    • Home safe (Key 1)
    • Bank safe deposit box (Key 2)
    • Trusted family member’s home OR second property OR attorney’s office (Key 3)
    • For Tier 3: extend to additional jurisdictions

  4. Choose coordinator software. Sparrow, Specter, Nunchuk, Bitcoin Core, or others. Sparrow and Specter are the most common; Nunchuk pairs well for cross-platform use.

  5. Create the multisig wallet in the coordinator. Import the extended public keys from each hardware wallet; specify the 2-of-3 threshold; choose script type (P2WSH for native-SegWit multisig is the standard; P2TR for Taproot multisig is emerging).

  6. Export the wallet descriptor. This is the load-bearing artifact for recovery. See PSBT and wallet descriptors. Back up the descriptor alongside each seed backup; treat it as a first-class artifact.

  7. Verify with a test transaction. Send a small amount to the wallet; verify all three devices can sign (two at a time); confirm receipt at the destination; sweep back to original setup if desired.

  8. Distribute keys to their geographic locations. Ensure that no two keys are co-located at any time during normal operation.

  9. Document the setup for the heir. What devices exist, where the keys are, what the descriptor is, which coordinator to use, basic operational instructions. See Inheritance planning for bitcoin.

Spending

Routine spending from a DIY multisig:

  1. Coordinator (e.g., Sparrow) constructs the transaction. The holder reviews the addresses and amounts.
  2. Coordinator generates a PSBT.
  3. PSBT is transferred to the first hardware wallet (USB, QR, or microSD depending on the device).
  4. The hardware wallet displays the transaction; the holder verifies the destination address ON THE DEVICE SCREEN (not just in the coordinator).
  5. Holder confirms; device signs and returns the partially-signed PSBT.
  6. PSBT is transferred to the second hardware wallet.
  7. The second device displays the transaction; the holder verifies again.
  8. Holder confirms; device signs and returns the now 2-of-3-signed PSBT.
  9. Coordinator finalizes the transaction and broadcasts.

The third key is never touched in routine spending — it is the reserve for emergencies (loss of one of the active keys).

Re-keying

When a single key is lost (device fails, key forgotten, seed backup destroyed), the holder should sweep funds to a fresh 2-of-3 setup:

  1. Construct a transaction sending all funds from the old multisig to a new 2-of-3 wallet
  2. Sign with the two remaining keys
  3. Broadcast
  4. The compromised key is now irrelevant — funds have moved to the new wallet
  5. Replace the lost key with a new device + new seed
  6. Establish the new 2-of-3 with the replacement and the two existing keys

Re-keying is operationally heavier than single-sig recovery — coordinating the spend, generating the new key, updating geographic distribution, paying on-chain fees. For large UTXOs in high-fee environments, the fee cost can be meaningful. Plan the re-keying scenario in advance rather than improvising it.

Tradeoffs and considerations

Why three different manufacturers?

Vendor diversity is the most-emphasised single recommendation across the synthesis sources. The structural argument: if all three signing devices are Coldcards (or all Trezors, or all Ledgers) and a firmware bug, supply-chain compromise, or undisclosed vulnerability affects that vendor globally, all three keys are simultaneously at risk. The multisig’s structural protection collapses.

Three different devices (Coldcard, BitBox02, Foundation Passport, for example) means a single-vendor failure compromises at most one key. The 2-of-3 protection survives.

Every major practitioner endorses this: Lopp, Casa, Unchained, Blockchain Commons. The cost is modest (three devices instead of three of the same, perhaps 600 total). The benefit against a real attack class is meaningful. There is no defensible reason to use three identical devices in a 2-of-3 multisig.

Geographic distribution is a prerequisite, not a feature

A 2-of-3 multisig where all three hardware wallets and all three seed backups are in the same home is functionally no more secure than single-sig and is more complex. A fire, burglary, flood, or coordinated home invasion compromises the entire setup at once.

The minimum configuration: at least two physically distinct locations. The typical configuration: three locations. The principle: no single location should contain enough material to meet the threshold.

Patterns that fail this:

  • Three keys in three drawers in one home
  • Two keys at home, one at the office (where the holder works every day)
  • Three keys at one bank safe deposit box

Patterns that work:

  • Home safe + bank safe deposit box + trusted family member in a different city
  • Home + attorney’s office + second property
  • For Tier 3: extends across jurisdictions

The six-items-to-manage problem

DIY 2-of-3 involves managing:

  1. Hardware wallet 1
  2. Seed backup 1 (metal, in a location distinct from device 1)
  3. Hardware wallet 2
  4. Seed backup 2 (metal, distinct location)
  5. Hardware wallet 3
  6. Seed backup 3 (metal, distinct location)
  7. Wallet descriptor (in multiple locations, ideally with each seed backup)
  8. Coordinator software state (typically a Sparrow or Specter wallet file)

The 3-of-5 version expands to:

  • Five devices + five seed backups + descriptor + coordinator state = twelve items at minimum
  • Or, with minimum-three-seed backups for quorum recovery: eight items at minimum

The synthesis is direct: complexity is the top cause of lost Bitcoin among self-custodians. The discipline to manage six items is meaningfully harder than to manage one or two; the discipline to manage twelve is meaningfully harder still.

A useful test: can you locate each of the six items from memory? Can you state the contents of each? Can you describe the coordinator software state? If the answer is no for any item, the setup is structurally fragile.

The descriptor is the assembly instruction

Without the wallet descriptor, holding all three seed phrases is not sufficient to reconstruct the wallet (in practice). The descriptor specifies:

  • Which three extended public keys form the wallet
  • The threshold (2-of-3)
  • The script type (P2WSH, typically)
  • The derivation path
  • The key ordering (in some implementations)

A holder who loses the descriptor and only has the three seeds faces a recovery problem that may cost more in expert time than the multisig’s structural benefit ever saved. The descriptor must be backed up alongside each seed.

See PSBT and wallet descriptors for the full treatment.

Why 2-of-3 and not 3-of-5 for most holders

The synthesis’s argument for 2-of-3 over 3-of-5 as the default:

  • 2-of-3 tolerates one simultaneous loss; 3-of-5 tolerates two. The marginal protection is real but modest.
  • 2-of-3 requires six items; 3-of-5 requires eight to twelve. The complexity increase is substantial.
  • Re-keying frequency scales with the number of keys. More keys means more re-keying events over the holding horizon. Each is operationally costly.
  • The “what threat does the additional fault tolerance defend against” question rarely yields a compelling answer for individual holders. Two simultaneous-key losses in a properly geographically-distributed 2-of-3 is unusual; the cases where it happens (catastrophic event affecting multiple locations) often also compromise the additional 3-of-5 keys if they are nearby.

Unchained’s analysis is pointed: “With 3-of-5 collaborative custody, with proper seed phrase backups for each key, you would need to secure eight secure locations. Even if you only secured a seed phrase for the minimum to create a quorum (three), you would still need six secure locations.”

3-of-5 is the right answer for:

  • Family-office or institutional configurations where multiple stakeholders genuinely need independent signing capability
  • Tier 3+ holdings with explicit jurisdictional or multi-party considerations
  • Holders who have already operated 2-of-3 successfully and have specific reasons for the upgrade

For everyone else, 3-of-5 is security theatre: additional complexity that introduces more self-inflicted loss risk than the additional fault tolerance buys.

Coordinator longevity

A DIY multisig depends on the coordinator software being available for the holding horizon. Sparrow, Specter, Nunchuk, and Bitcoin Core are all mature and likely to persist; the risk is not that all of them disappear simultaneously but that the holder’s specific coordinator-saved state becomes uninterpretable to alternatives.

The defence: use canonical wallet descriptors (BIP-380 output descriptors) rather than coordinator-specific formats. Test that the wallet can be imported into at least one alternative coordinator. The descriptor is the portable specification; the specific coordinator is the active tool.

Tiered application

Tier 0–1: DIY multisig is overkill. Single-sig with strong discipline is structurally safer.

Tier 2 (1M+): DIY 2-of-3 is the appropriate sovereign choice. Vendor diversity (Coldcard + BitBox02 + Foundation Passport, or similar). Three geographic locations. Tested annually. Inheritance planned.

Tier 3 (>$1M): DIY 2-of-3 or DIY 3-of-5 depending on threat model. For holders with jurisdictional, family-office, or multi-party considerations, 3-of-5 may be appropriate. For Tier 3 holders without those specific considerations, 2-of-3 with strict discipline is often structurally safer. Possibly combined with collaborative custody for additional redundancy.

In all tiers, the operational principle: the configuration is only as good as the discipline that sustains it. A well-managed 2-of-3 is structurally safer than a poorly-managed 3-of-5.

Common pitfalls

Three identical hardware wallets. Defeats vendor diversity. The standard recommendation is three different vendors; any other configuration should be justified by a specific reason.

Co-located keys. Three keys in one home, two keys in two adjacent rooms, three keys at one bank. The geographic distribution is the structural defence; co-location defeats it.

Lost descriptor. Holding three seeds with no descriptor is a recovery problem most holders cannot solve without expert help. Back up the descriptor alongside each seed.

Skipping the test transaction. A multisig that has never been tested with a real spend has not, in any meaningful sense, been tested. The first spend should be a small test before the wallet holds substantial funds.

Adopting 3-of-5 because “more security.” Without a specific threat-model justification, 3-of-5 is complexity for complexity’s sake. Most holders are better served by well-managed 2-of-3.

Improvising re-keying under pressure. The re-keying scenario should be planned in advance — what coordinator, what fee target, what new device, what location for the new device. Improvising under the stress of a key loss is where additional mistakes occur.

Treating multisig as a passive setup. Multisig requires periodic verification — at minimum, the holder should confirm annually that they can still access two of the three keys. Setups drift; locations get renovated; family members move. Without periodic verification, the geographic distribution can erode without the holder noticing.

Not planning inheritance. A DIY multisig is meaningfully harder to inherit than single-sig. Heirs need keys, descriptor, coordinator knowledge, and PSBT familiarity. Without explicit inheritance planning, the multisig’s exposure-side protection becomes a loss-side liability for the family.

Treating the third key as redundant. The third key in a 2-of-3 is the redundancy that justifies the multisig. Treating it as “extra” and letting its location drift or its seed backup go unverified erodes the structural protection.

Comparison with alternatives

ApproachStructural protectionOperational complexityInheritance complexityTier fit
Single-sigSingle point of failureLowestLowestTier 0–1
Single-sig + passphraseTwo artifacts must be compromisedLow-mediumMedium (passphrase backup)Tier 1
SLIP-39Distributed backup, single-sig operationMediumMediumTier 1–2
DIY 2-of-3 multisigNo single-key compromiseHighHighTier 2–3
Collaborative 2-of-3Same as DIY but with partner managing complexityMediumLower (partner-supported)Tier 2–3
DIY 3-of-5Tolerates two simultaneous lossesVery highVery highTier 3 (specific use cases)
Collaborative 3-of-5Same as DIY but with partnerHighMedium-highTier 3 (family-office)

The decision pattern: choose the lowest-complexity configuration that adequately covers your threat model. Don’t climb the ladder for the climb’s sake.

Tooling and resources

Coordinator software for DIY multisig:

  • Sparrow Wallet — desktop; the most popular general-purpose multisig coordinator
  • Specter Desktop — desktop; multisig-focused; tighter integration with Bitcoin Core
  • Nunchuk — desktop and mobile; full multisig support; the “sovereignty-minded” coordinator
  • Bitcoin Core — for the deeply technical; multisig via PSBT command-line tools
  • Casa app / Unchained app — for collaborative custody specifically; see Collaborative custody services

Hardware wallets (see Hardware wallets overview for the full framework):

Primary practitioner sources:

  • Unchained — Why 2-of-3 is the right multisig setup for most individuals and businesses; DIY multisig vs. collaborative custody multisig; Multisig 2-of-3 vs. 3-of-5; the canonical multisig advocacy
  • Casa — multi-key plan documentation; the multi-key architecture framework
  • Nunchuk — Multisig Made Easy; sovereignty-focused multisig
  • Lopp — Multisig Hardware Signing Performance Reports (2020, 2024); operational essays. See Jameson Lopp.
  • Blockchain Commons — Smart Custody Book; multisig within the broader Smart Custody framework

The synthesis document: Bitcoin Self-Custody & Security (LegacyCipher, April 2026) — multisig treated as Configurations 4 and 6 of the ladder.

As of 2026-05-14: multisig tooling is mature. Sparrow, Specter, Nunchuk, and Bitcoin Core all interoperate cleanly via BIP-380 output descriptors. Hardware-wallet support for multisig is universal among mainstream devices.

Open questions for further development

  • The 2-of-3 vs 3-of-5 question is somewhat settled by the synthesis but the empirical case is mostly argumentative rather than data-driven. Are there comparative data on multisig-related Bitcoin loss across configurations?
  • Taproot multisig (P2TR with Schnorr signatures) offers some privacy and efficiency benefits over P2WSH multisig. The adoption is increasing. When does the framework recommend Taproot multisig as the default?
  • The re-keying frequency question: how often, in practice, does a DIY 2-of-3 require re-keying over a 20-year holding horizon? The synthesis doesn’t quantify this; practitioners suggest “rarely, but plan for it.”
  • Multi-party multisig where each holder is a distinct individual (e.g., family-office configurations, business partnerships) is structurally different from individual multisig with distributed keys. Should the framework treat these separately?
  • Time-locked multisig (where one signing path requires a delay) is an emerging configuration. Useful against coercion attacks specifically. Should the framework include it as a variant of 2-of-3?

The framing context:

Adjacent custody configurations:

Storage and key concepts:

Hardware wallets:

Operational practice:

Inheritance:

The principal practitioners:

The sub-MOC home:

Graph View

Backlinks