Timechain Wiki

Self-custody configuration ladder

30 min read

The major self-custody setups arrange themselves into a ladder of ascending complexity: single-sig hardware wallet → single-sig with passphrase → SLIP-39 / Shamir → DIY 2-of-3 multisig → collaborative 2-of-3 multisig → 3-of-5 multisig, with BIP-85 sitting orthogonally as a simplifier rather than a custody scheme. Each rung addresses a real failure mode and introduces new ones. The synthesis's central claim — adopted as this section's animating principle — is that the best setup is the simplest one that adequately covers your threat model, not the most impressive or the most secure-on-paper. Most newcomers should start at single-sig; most substantial holders should sit at 2-of-3 collaborative or DIY; 3-of-5 is right for a small minority. Combined setups (passphrase + SLIP-39 split, multisig + BIP-85, tiered hot/cold/deep-cold wallets) are sometimes useful, sometimes neutral, and occasionally actively harmful (stacked custom passphrases, co-located multisig, beneficiary-held Shamir shares). This note is the synthesizing spine of the Practical self-custody and sovereignty section — other operational notes refer to it rather than re-describe its configurations.

Why this note matters

This is the synthesizing primary note for the Practical self-custody and sovereignty section. The configuration ladder is the spine the rest of the section organizes around. Where Loss vs exposure failure modes names the structural trade-offs and Threat modeling for self-custody names the adversaries, this note maps both onto what to actually do.

It matters because:

  • It corrects the “more security is better” intuition that drives many holders to over-engineer. The reading across seven primary sources is direct: complexity is the dominant cause of lost Bitcoin, and most holders are better served by a simpler setup than the literature describes.
  • It provides the decision framework the rest of the section’s notes refer back to. Rather than re-describing the ladder in Multisig setups, Collaborative custody services, and others, those notes assume it and treat their specific configuration.
  • It engages the combined-setups question the literature handles unevenly. Some combinations are useful (passphrase + SLIP-39 split for inheritance); some speculative (beneficiary-held Shamir shares); some actively harmful (stacked custom passphrases). The note codifies which is which.

The defensible position: a setup should be defensible in terms of a specific threat model, an articulated loss-vs-exposure trade-off, and a recovery and inheritance plan that has been tested. The ladder makes those defences legible.

The animating principle

The simplest setup that adequately covers your threat model

The best self-custody setup is the simplest one that adequately covers your threat model — not the most impressive, not the one a specific vendor or commentator recommends, not the most secure-on-paper. The simplest one that:

  • Defends against the adversaries you can actually name
  • Has a recovery story your future self, in worse cognitive shape than now, can execute
  • Has an inheritance story your heirs, in worse emotional shape than now, can execute
  • You have actually tested end-to-end at least once

The wrong answer for anyone is the setup they do not actually understand.

This principle is drawn directly from the LegacyCipher synthesis and is treated as canonical across the section. Every configuration on the ladder is a defensible answer for the right holder. The wrong configuration is the one that does not match the holder’s actual operational discipline, threat model, and inheritance situation.

Configuration 1 — Single-signature on a hardware wallet

One hardware wallet. One seed phrase backed up once or twice on metal, stored somewhere secure. The simplest form of self-custody that is not outright negligent.

What this is

A hardware wallet generates and holds a single 12- or 24-word BIP-39 seed. The seed is backed up to durable physical media (steel or paper). The hardware wallet signs transactions; the holder verifies on the device’s screen and confirms on the device’s buttons. No coordination software is required beyond a single-vendor companion app or a compatible wallet.

What single-sig is good at

  • Simplicity. One device, one seed, one backup. There is a single mental model to master, and it is not hard.
  • Cost. A 137 BitBox02 is enough. No coordination software, no partner fees.
  • Recovery speed. One seed phrase into one wallet and you are back. No descriptors, no quorums.
  • Universal support. Every wallet and every educator supports it.

What single-sig is not good at

  • Single point of failure. The seed backup is the one thing that must not be lost and must not be seen. Any single event — fire, theft, coercion, a nosy house-sitter — that compromises that one thing compromises everything.
  • No adversary tolerance. If an attacker obtains the seed, they spend the coins. There is no second layer.
  • Wrench-attack exposure. With one seed, the attacker can see the entire balance and knows they have the full set. There is no structural reason for them to believe more exists.

Who should use it

Holders whose stack is modest relative to net worth; beginners in the first year of self-custody; anyone whose primary concern is exchange risk rather than targeted physical threats. The Bitcoin Adviser, Casa, and Unchained all recommend a pattern of “small balance on single-sig for convenience; large balance on multisig for security” — and that pattern is nearly universal across the synthesis sources.

Attempting to leap directly to 3-of-5 multisig introduces complexity the new holder is not yet equipped to manage. The complexity itself is a larger threat than the threats multisig addresses for a holder at this scale.

Configuration 2 — Single-sig with a BIP-39 passphrase

The same setup as Configuration 1, plus a passphrase chosen at wallet creation. The seed phrase alone opens one wallet (the decoy); the seed phrase plus the passphrase opens a different wallet (the real one).

What this gains

  • Protection against seed-phrase exposure. A found metal backup, a photographed seed, an extracted seed from a compromised device — none of these alone is sufficient to spend the real funds.
  • Plausible deniability. The decoy wallet is not obviously a decoy. An attacker who finds only the seed has no structural reason to suspect a hidden wallet exists. The holder under coercion can reveal the seed and the unpassphrased wallet without revealing the real holding.
  • Cheap in complexity. You already have the hardware wallet. You choose a passphrase during setup.

What this costs

  • A new single point of failure: the passphrase. Forget it or lose its backup and the coins are gone, even with the seed intact.
  • The passphrase is not a password. It cannot be rate-limited, reset, or recovered. Weak or guessable passphrases are nearly as bad as no passphrase at all.
  • Plausible deniability is a belief, not a guarantee. Lopp documents cases where decoys failed to convince attackers and victims who handed over decoys were tortured for hours under the assumption of hidden reserves.

The passphrase backup problem

The single most-cited inheritance failure mode in the synthesis: the holder picks a strong passphrase, memorises it, never writes it down (“if someone finds the backup, the whole point is defeated”), then dies or forgets. A passphrase that exists only in the holder’s head is a single point of failure with no backup. The seed phrase — which is backed up — gives the illusion that the wallet is recoverable. It is not.

The conventional defence: back up the passphrase separately from the seed phrase, in a different location, ideally with a different party involved in the chain. Some holders SLIP-39-split the passphrase specifically (see Combined setups, below).

Who should use it

Holders at Tier 1–2 who want a second cryptographic layer without adopting the operational complexity of multisig. Particularly useful for holders whose realistic exposure concern is “found seed backup” rather than “compromised device at signing time.” Less useful for holders who want plausible deniability against sophisticated coercion (where the speculation about the attacker’s beliefs is shaky).

Configuration 3 — SLIP-39 / Shamir Secret Sharing

Instead of one or two complete seed backups, the seed is mathematically split into N shares such that any M of them (for M ≤ N) reconstructs the original, but fewer than M reveal nothing. A common pattern is 3-of-5 shares distributed across locations or trusted parties.

What this gains

  • No single share compromise matters. An attacker who finds one share learns nothing about the seed.
  • Redundancy without full replication. You can survive the loss of (N − M) shares. In 3-of-5, two shares can be lost without compromising recovery.
  • Single wallet on-chain. Unlike multisig, the wallet does not appear to blockchain observers as a multi-party arrangement. This has privacy advantages.

The critical caveat (every source emphasises this)

At recovery time, the M shares must be physically combined on one device to reconstruct the master seed. At that moment, that device holds the entire spending capability. If the reconstruction device is compromised, the seed is exfiltrated. If the reconstruction process is observed, the whole point of distribution is undone.

Unchained calls this “single points of failure at certain instances during its lifecycle.” Casa prefers multisig over SLIP-39 specifically for this reason. Lopp has written a dedicated piece, Shamir’s Secret Sharing Shortcomings, arguing the same position.

This is not an argument against SLIP-39 — it is an argument that SLIP-39 and multisig solve overlapping problems differently. SLIP-39 excels as a backup scheme for a seed that is rarely touched. It is less ideal as a frequently-used operational wallet.

Who should use it

Holders who want geographic distribution of backups without the operational complexity of multisig, and whose principal use is long-term cold storage rather than frequent spending. Shamir-backed single-sig combined with a strong on-device passphrase is a reasonable intermediate tier between simple single-sig and full multisig. Trezor supports SLIP-39 natively; some other devices support it to varying degrees.

Configuration 4 — DIY 2-of-3 multisig (sovereign multisig)

Three hardware wallets, preferably from three different manufacturers, held entirely by you. Any two together can spend. Keys are geographically distributed — common distribution is home, bank safe deposit box, and a trusted family member or second property.

This is the configuration nearly every rigorous self-custody commentator endorses as the first that genuinely removes single points of failure for personal-scale holdings. It is substantially more complex than single-sig; the complexity is the point — and the primary risk.

Why three different manufacturers?

If all three signing devices are Coldcards and a firmware bug, supply-chain compromise, or undisclosed vulnerability affects Coldcard globally, all three keys are simultaneously at risk. Diversifying across (for instance) Coldcard, BitBox02, and Foundation Passport means a single-vendor failure compromises at most one key. Lopp calls this avoiding “correlation risk” between keys; every major practitioner endorses it.

What DIY 2-of-3 gains

  • No single point of failure. Loss or theft of any one key, any one location, or any one vendor’s security model does not compromise funds.
  • Full sovereignty. No third party is involved. No company can fail, freeze, or subpoena the setup.
  • Recoverable. If a single key is lost, you sign with the other two, sweep funds to a fresh 2-of-3, and re-establish the quorum.

What DIY 2-of-3 costs

  • Complexity, the top cause of lost Bitcoin. Six sensitive items now require management: three hardware wallets and three seed backups. Plus the wallet descriptor. Plus the coordinator software state. Unchained’s consistent framing: “The most common way that people lose bitcoin when self-custodying is by introducing too much complexity.”
  • Geographic coordination. To spend, you must access two of three distributed locations without co-locating any two keys. For routine withdrawals, manageable. During crisis (fire, illness, natural disaster), difficult.
  • Inheritance is harder. Heirs need to locate three keys or seed backups, hold the wallet descriptor, know which software coordinates a spend, and understand PSBT flows. “Just give them the seed phrase” no longer works.
  • Re-keying is arduous. A lost key requires sweeping funds to a fresh 2-of-3 setup — coordinating signatures from the remaining two keys, generating a new replacement key, and paying on-chain fees. For large UTXOs in a high-fee environment, non-trivial.

Who should use it

Holders with material Bitcoin exposure, the operational discipline to manage six distributed items, and realistic plans for setup recovery if they themselves are unavailable. Everyone the synthesis reviews agrees this configuration is overkill for small balances and that it is a mistake to adopt before being confident with single-sig.

Configuration 5 — 2-of-3 collaborative multisig

The same 2-of-3 quorum as Configuration 4, but one of the three keys is held by a collaborative custody partner — a business (Unchained, Casa, Nunchuk’s assisted service, The Bitcoin Adviser, and others) whose role is to hold one key and help coordinate spending, recovery, and inheritance.

The partner cannot move funds alone — they hold one of three. You still hold two. You retain unilateral spending authority. What you have outsourced is complexity management: the partner typically holds the wallet descriptor, maintains technical expertise for recovery, and provides a documented process for your heirs.

What collaborative 2-of-3 gains

  • Substantial complexity reduction. In Unchained’s framing, you manage five items instead of seven: two keys, two seed-phrase backups, and the wallet descriptor (which the partner also holds). For most holders, this is the difference between “manageable” and “overwhelming.”
  • Operational convenience. To spend, you sign with one key and instruct the partner to co-sign. The other key can stay in its secure location undisturbed.
  • A safety net. If one key is lost, the partner can provide the second signature to help recover to a fresh setup. They cannot unilaterally spend; they can only help when asked.
  • Inheritance becomes dramatically simpler. Heirs contact the partner — who has one key, the descriptor, and the technical expertise — prove their identity, and access one of the holder’s two keys. A much lower technical bar than DIY multisig inheritance.

What collaborative 2-of-3 costs

  • A trusted partner in the loop. You have disclosed that you hold Bitcoin, and typically an approximate amount. A privacy trade-off, particularly against the socially-close and institutional-leak categories.
  • Counterparty longevity risk. What if the partner goes out of business? Reputable partners publish open-source sovereign-recovery tools and documentation — you can still spend from the 2-of-3 setup using your two keys plus the descriptor without their cooperation. Casa and Unchained both publish this as a specific commitment; evaluating how seriously any given partner takes it is the critical part of choosing one.
  • Ongoing cost. Collaborative custody is a business. Free tiers exist (Nunchuk’s basic app is free; Unchained’s DIY is free if you hold all three keys). Assisted services typically cost hundreds to thousands of dollars per year for larger balances.
  • The partner knows you hold Bitcoin. For some threat models this matters.

Where the providers diverge

  • Unchained — white-glove partnership, documented inheritance protocols, attorney coordination, the relationship treated as ongoing and active.
  • Casa — multi-key architecture and tools first, partner role lighter.
  • Nunchuk — sovereignty and minimised trust; paid services exist but the philosophical stance is “don’t rely on us.”
  • The Bitcoin Adviser — estate-planning end of the spectrum, multisig as infrastructure for the broader inheritance plan.

None is correct. They serve different clients. The evaluation criteria (per the synthesis): (1) verify the partner’s open-source sovereign-recovery story; (2) confirm multi-vendor hardware support so you are not locked to a single device manufacturer; (3) understand exactly what happens to your setup if the partner disappears tomorrow.

Who should use it

Holders with substantial exposure who recognize that they themselves are likely their largest threat — and who would rather outsource complexity to a partner than build operational discipline from scratch. Particularly attractive for holders whose inheritance situation is non-trivial (substantial estate, multiple heirs, complex family dynamics) where the partner’s standing inheritance procedure adds significant value.

Configuration 6 — 3-of-5 multisig

Five keys, any three of which together can spend. A small step up in threshold, a large step up in complexity.

What it gains

3-of-5 tolerates the simultaneous loss of two keys, which 2-of-3 cannot. It is standard for some family-office and institutional setups. For holders with significant stacks and genuinely-different-custodian requirements — one key with an attorney in one jurisdiction, one with a family member in another, one in personal custody, two with separate collaborative partners — it can make sense.

What it costs

For most individuals, 3-of-5 fails the complexity test. 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.” Every time a key is lost, you must re-key the entire setup — now coordinating signatures from three keys across three locations rather than two.

Who should use it

A small minority of holders whose threat model genuinely demands it. For the rest, it is security theatre — complexity that introduces more self-inflicted loss risk than the additional fault tolerance buys.

The synthesis is direct on this. Adopting 3-of-5 because it is “even more secure” than 2-of-3 is the kind of decision that misreads the structural risk landscape. The marginal exposure-side protection is small; the marginal loss-side risk is substantial.

Configuration 7 — BIP-85 as an orthogonal simplifier

BIP-85 is not a custody scheme. It is a deterministic mechanism for deriving new seed phrases from an existing master seed. Typical use case: one cold-storage master seed, backed up to the highest standard you can manage, and several child seeds derived from it for specific purposes — a mobile hot wallet, a Lightning node, a wallet given to a partner or child.

What BIP-85 gains

  • One backup for many wallets. If the master is safe, every child is recoverable. The number of irreplaceable backups drops from N to 1.
  • Clean compartmentalisation. A child wallet compromise does not affect the master or sibling wallets.
  • Passphrase factory. A child seed is a large random number presented as words; the first few words can serve as a BIP-39 passphrase, making the master seed the deterministic source of passphrases too.

What BIP-85 costs

  • Concentrated single-point-of-failure on the master. The master must be protected at the level appropriate to everything downstream of it, not just its own balance.
  • Indexing complexity. Each child wallet was derived at a specific index. Lose the index, and even with the master you face a search problem. Coldcard’s BIP-85 implementation caps indexes at 9,999 by default — searchable but unfun.
  • Privacy leakage risk. Leak the master extended public key and all child extended public keys become computable, linking otherwise-independent wallets.

How to think about it

BIP-85 is best treated as an operational convenience, not a security improvement. It does not harden the master. It reduces what has to be backed up. Whether that trade is right depends on the holder’s confidence in their master-backup hygiene.

A common pattern: use BIP-85 to manage operational wallets (hot, Lightning, family-member spending wallets) while keeping the savings wallet in a separate, non-BIP-85 cold-storage setup. This bounds the BIP-85 master’s blast radius to wallets the holder is willing to lose.

Who should use it

Holders already running multiple wallets who want to reduce their total backup count, paired with a master-backup discipline equal to the total downstream exposure. Not useful as a single-wallet simplification — there is nothing to simplify.

Combined setups — which combinations help, which do not

A frequent move among experienced self-custodians is to combine schemes. Not all combinations are helpful. Some are genuinely useful; some are neutral; some are actively harmful.

Useful — Single-sig + passphrase + SLIP-39 split of the passphrase

The seed phrase is backed up conventionally (one or two metal plates). The passphrase — the component that makes the seed alone insufficient — is split using Shamir into N shares distributed among trusted parties or locations. A threshold of shares reconstructs the passphrase.

This is the cleanest answer to the passphrase-inheritance problem. The holder retains the simplicity of single-sig for routine use; the “what if I die with the passphrase only in my head” failure mode is eliminated. The seed alone remains insufficient to an attacker who finds it. Plausible deniability is preserved during the holder’s lifetime; an inheritance path exists post-mortem.

The main cost: it only solves the inheritance problem, not the geographic-distribution problem. All wallets still derive from one seed, and the security of that seed is still the security of everything.

Useful — Multisig + BIP-85 to simplify key management

A 2-of-3 multisig where one or more of the signing keys are themselves BIP-85 children of a master. This sounds like it reintroduces a single point of failure — compromise the master, compromise multiple keys — and it does. But for holders who already run multiple wallets and want to reduce backup count, using BIP-85 for the subset of keys they already manage (e.g., their two of three client-held keys in a collaborative setup) is a pragmatic simplification.

The critical constraint: BIP-85 should not derive all keys in a multisig. At least one key needs independent entropy — typically the collaborative partner’s key, or a key generated fresh on a separate device. Without this constraint, the multisig collapses to single-sig at the master level.

Useful — Tiered wallet system (Lopp’s three-wallet approach)

Not a single-custody scheme but a portfolio of custody schemes matched to different amounts and use cases:

  • Hot wallet (mobile, small amount, easy to spend) — for transactions and Lightning. Any compromise is painful but survivable.
  • Cold wallet (single-sig hardware, medium amount) — for near-term reserves. Single point of failure is limited in blast radius.
  • Deep cold storage (multisig with geographic distribution) — for long-term savings. Touched rarely. High-friction by design.

Lopp’s framing: the worst outcomes are all funds on a single hot wallet, or all funds on a maximum-security multisig you are afraid to touch. A tiered setup matches security to purpose. Casa, Theya, and multiple other services explicitly design around this pattern.

Questionable — Shamir shares held by the beneficiaries themselves

A pattern sometimes proposed for inheritance: split the seed into shares, distribute them to your heirs, and tell them that after your death they can combine the shares to recover. On paper, elegant. In practice, fragile: heirs must keep shares secure for decades, during which any one may be compromised, lost, discovered, misinterpreted, or simply out of contact with the others. River’s published inheritance writing documents the common failure modes: heirs treat the share as junk; divorce or family fall-out makes coordination impossible; the share ends up in a digital photo.

The pattern works when heirs are closely coordinated and technically engaged. It works less well otherwise. For most holders, a revocable living trust with a documented process administered by an attorney is more robust than a beneficiary-held Shamir scheme.

Actively harmful — Stacking custom passphrases on custom passphrases

Some holders, in pursuit of maximum security, layer multiple passphrases or use idiosyncratic encodings (“my seed plus my mother’s maiden name plus the name of my first pet, then rotated by 3”). The failure mode is nearly universal: the holder cannot reliably reconstruct the combination under stress. This is the largest self-inflicted loss category in the synthesis. Unchained, Lopp, and Nunchuk all caution explicitly against it.

If you need more than one passphrase, you need a backup strategy for each — and at that point you are better served by SLIP-39 or multisig, which are designed for the problem you are trying to solve.

Actively harmful — Multisig where all keys live in the same house

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. Geographic distribution is not an optional feature of multisig — it is a prerequisite for multisig to be meaningful.

The synthesis has seen this setup in the wild. The person who built it often believed “three devices is three times the security.” It is not. Three devices at one address is one address.

Actively harmful — Untested novel schemes

Any setup the holder has not tested end-to-end is a hope, not a setup. Lopp’s repeated insight: a setup whose recovery has never been rehearsed is a setup that does not, in any meaningful sense, exist. The novel scheme that has not been verified against a small test balance before funding the wallet has a non-trivial chance of failing precisely when the holder needs it.

How to navigate the ladder

The decision sequence the synthesis suggests:

Step 1 — Name your top three adversary categories

From Threat modeling for self-custody: write down which of the six categories (yourself, environmental, remote, local physical, socially close, institutional) you rank highest, in priority order. Five minutes of honest reflection.

Step 2 — Name your tier

From _Brief.md §12: Tier 0 (under 1K–50K–1M). Take the higher of the tier suggested by your holdings and the tier suggested by your threat surface.

Step 3 — Name your operational discipline

Honestly: are you a person who tests backups, writes documentation, rehearses recovery, and resists novelty? Or are you a person who sets things up and hopes? The first kind can sustain higher-complexity configurations. The second kind is structurally safer with simpler configurations and partnered custody.

Step 4 — Find the configuration that matches all three

For most readers, the configurations land roughly:

  • Tier 0 → Hot wallet on a phone, perhaps a hardware wallet if the holder enjoys learning the practice.
  • Tier 1, low-discipline → Single-sig hardware wallet, tested metal backup, basic inheritance envelope. Configuration 1.
  • Tier 1, high-discipline → Same as above, possibly with a passphrase if exposure threats rank high. Configuration 1 or 2.
  • Tier 2, low-discipline → Collaborative 2-of-3 with a reputable partner. Configuration 5.
  • Tier 2, high-discipline → DIY 2-of-3 multisig with vendor diversity and geographic distribution. Configuration 4. (Or collaborative 2-of-3 if inheritance complexity dominates.)
  • Tier 3, low-discipline → Collaborative 2-of-3 or 3-of-5 with two partners. Configurations 5 or 6.
  • Tier 3, high-discipline → DIY 2-of-3 or 3-of-5 with explicit jurisdictional and inheritance planning. Configurations 4 or 6.

These are not prescriptions. They are starting points the reader can adjust. The threat model determines where the adjustments go.

Step 5 — Layer combinations sparingly

If a combined setup genuinely solves a problem your single configuration does not (e.g., a passphrase + SLIP-39 split for inheritance), add it. If a combined setup is appealing because it sounds more secure (stacked passphrases, more shares, more keys), do not.

Step 6 — Test the setup before funding

Wipe the hardware wallet. Restore from the written backup. Verify the address. For multisig: restore each key from its seed backup independently and confirm the coordinator software reconstructs the wallet. Only then fund.

Step 7 — Document, then rehearse

Write down the setup in physical form, in language a non-technical person can follow. Walk an heir through finding the materials. Rehearse the recovery at least annually.

Tradeoffs and considerations

The configurations are not a hierarchy of correctness

The ladder is a hierarchy of complexity, not of correctness. Single-sig on a hardware wallet is the right answer for a meaningful fraction of holders. Adopting higher rungs is not a measure of seriousness — it is a measure of fit between the setup and the threat model.

The ladder does not capture everything

Two genuinely useful patterns the ladder doesn’t ladder cleanly:

  • The tiered-wallet portfolio (Lopp’s three-wallet) — holders should not pick one configuration; they should pick a portfolio of configurations matched to use. The configuration for the spending wallet is different from the configuration for the long-term savings wallet.
  • The inheritance overlay — every configuration has an inheritance story, but the inheritance story is not uniquely determined by the configuration. A single-sig holder with a documented heir-process inherits better than a DIY-multisig holder without one.

Re-keying as a chronic concern

Most configurations above 2-of-3 single-sig have a non-trivial re-keying overhead when any single component is lost. The synthesis treats re-keying as a routine cost; in practice it is friction that delays response and compounds risk. The configurations that age best are the ones where re-keying is cheap (single-sig has no re-keying — you just generate a new seed and move funds) or genuinely rare (a well-managed collaborative 2-of-3 may go years between re-keying events).

The “what does the partner know” axis

Collaborative custody configurations involve disclosure to the partner — what amount you hold, that you hold Bitcoin at all, sometimes geographic information. For some threat models (institutional risk dominant, KYC-leak correlation high), this disclosure is itself a meaningful cost. Nunchuk’s stance — minimum disclosure, no KYC beyond email, no balance knowledge — is the strongest privacy-preserving collaborative option, at the cost of less hand-holding.

The framework’s implicit assumption

The synthesis is calibrated for individual holders with personal-scale balances and 10–40-year holding horizons. The framework’s specifics drift for institutional holders, very-high-net-worth scenarios (where bespoke setups with security firms become reasonable), and short-horizon active traders (where the savings/spending balance is different). Adapt accordingly.

Tiered application

The ladder’s appropriate rungs by tier, condensed:

Tier 0 (under $1K, casual use): Configuration 1 light (hot wallet) or possibly nothing — exchange custody may be appropriate at this scale. The framework is mostly aspirational at Tier 0.

Tier 1 (50K): Configuration 1 or 2. A tested single-sig hardware wallet with a documented inheritance plan covers the realistic threat surface for most Tier 1 holders. A passphrase is appropriate where exposure threats rank highest; not otherwise. Multisig is overkill at Tier 1 and the complexity often becomes the dominant risk.

Tier 2 (1M+): Configurations 2, 4, or 5. The exact rung depends on threat surface and operational discipline. Many Tier 2 holders are well-served by collaborative 2-of-3 specifically because the inheritance and complexity-reduction benefits compound. Strong-discipline holders may prefer DIY 2-of-3 for full sovereignty.

Tier 3 (>$1M): Configurations 4, 5, or 6, with explicit attention to inheritance, jurisdictional risk, and threat-surface management. Tiered-wallet portfolios become more important at Tier 3 — different configurations for spending, near-term reserves, and deep-cold storage. Combined setups (passphrase + multisig + BIP-85 for operational wallets) are sometimes appropriate but should be adopted one at a time, each tested, each documented.

Common pitfalls

Climbing the ladder for the climb’s sake. “More multisig is more security” is wrong. Each rung introduces new failure modes; only the rungs that match your threat model and operational discipline improve the setup.

Adopting multisig before being competent with single-sig. Multisig amplifies operational discipline. A holder who has not internalized the discipline at single-sig will not magically acquire it at multisig — they will compound the deficiency.

Treating collaborative custody as “single-sig with extra hands.” Collaborative custody is multisig with a partner. The holder is still responsible for their two keys. Treating it as if the partner can compensate for missing operational discipline is a misunderstanding.

Mixing rungs of the ladder without articulating why. “I’ll use single-sig + passphrase + a SLIP-39 split + a multisig for the big balance.” Possibly sensible. Often complexity for its own sake. Each layer should be defensible against a specific threat the prior layer doesn’t handle.

Not having a tiered portfolio. All funds in the highest-security configuration is rarely correct. The holder ends up either touching the deep-cold setup too often (eroding the security) or under-spending Bitcoin (eroding the practice). Match security to purpose.

Failing to plan re-keying in advance. Every configuration above single-sig has a re-keying scenario. Knowing how it will play out — who you contact, what records you need, what fees you expect — is part of the setup, not an emergency improvisation.

Designing for the threat model you have today only. Threats evolve. The configuration that is right at age 35 may not be right at age 65. The configuration that is right for an anonymous holder may not be right after a public profile event. Plan for the configuration to evolve.

Treating the configuration as a one-time decision. The configuration is a practice, not a one-time choice. Rehearse, document, test, refine.

Tooling and resources

The synthesis document (canonical for the section):

  • Bitcoin Self-Custody & Security: A Synthesis of Contemporary Best Practices, LegacyCipher discussion, April 2026 — the explicit ladder framework, the combined-setups categorization, and the animating principle.

Primary practitioner sources:

  • Jameson Lopp — 21 tips for securing your bitcoin; ongoing essays at lopp.net; the Multisig Hardware Signing Performance reports (2020, 2024); Shamir’s Secret Sharing Shortcomings. See Jameson Lopp.
  • 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; Multisig, Shamir’s secret sharing & MPC compared.
  • Casa — Shamir Secret Sharing Shortcomings; the seedless-security model; multi-key plan documentation.
  • Nunchuk — Bitcoin Self-Custody: A Path Forward; Multisig Made Easy; the 2021 Canadian-injunction response letter as a sovereignty-stance reference.
  • The Bitcoin Adviser — estate-planning-focused configuration guidance.
  • Blockchain Commons — Smart Custody Book (CC-BY-SA, free); the cold-storage scenario.

Underlying specifications:

  • BIP-39 (mnemonic seeds), BIP-85 (deterministic entropy from BIP-32 keychains), SLIP-39 (Shamir secret sharing), BIP-174 (PSBT)

As of 2026-05-14: the ladder’s seven configurations and the combined-setups categorization are stable. The hardware-wallet device landscape (which products are appropriate at each rung) is fast-changing; see Hardware wallets overview for the current state.

Open questions for further development

  • The ladder’s seven configurations capture the established schemes. Are there emerging configurations that should be added? Specifically: MPC (multi-party computation) custody schemes — currently dominant in institutional crypto, contested in personal self-custody. The synthesis sidelines MPC; the framework may need to engage it as the technology matures.
  • How does the ladder handle the Bitcoin medium-of-exchange phase? Active spending wallets are structurally different from savings wallets. The ladder is calibrated for savings; the framework may need a parallel spending-wallet ladder.
  • The “combined setups” categorization includes some patterns the synthesis flags as “useful” but that may be more controversial. The passphrase + SLIP-39 split, for instance, is elegant but undertested at scale — is the synthesis’s endorsement well-grounded?
  • The framework presupposes a holder making decisions for themselves. Family-scale custody arrangements — multiple holders sharing infrastructure — are increasingly common. How should the ladder be adapted for these?
  • The 3-of-5 configuration is treated as overkill for nearly all individuals. Is this calibration right? Specifically: holders with multiple substantial heirs in different jurisdictions may have a legitimate threat model that 3-of-5 addresses better than 2-of-3. The synthesis’s collapse to “overkill for most” may be too broad.
  • The ladder does not engage proof-of-reserves and audit-trail considerations for institutional holders (corporate treasury, fund-managed Bitcoin). These are outside the personal-self-custody scope but are increasingly relevant for holders who interact with such vehicles. Worth a separate treatment?
  • Recovery rehearsal is the principal defence the framework recommends. How does the rehearsal practice scale to multisig configurations where rehearsing the spend requires actually moving funds? Signed-challenge-message rehearsals (Casa-style) are a lightweight option — should they be the default rather than full-spend rehearsals?

The other framing lenses:

The configurations as their own notes:

Hardware wallets:

The operational discipline the ladder presupposes:

Inheritance, which depends substantially on configuration:

The moral framing:

The principal practitioners:

  • Jameson Lopp — empirical security and the configuration-comparison work

The sub-MOC home:

Graph View

Backlinks