Timechain Wiki

Practical self-custody and sovereignty

18 min read

The operational and procedural dimensions of holding Bitcoin without trusted intermediaries. Where the Economics and Culture-philosophy sections argue why sound money matters, this section answers how to actually hold it — across the full range of threat models, holding sizes, and life stages. The animating principle: the best self-custody setup is the simplest one that adequately covers your threat model — not the most impressive, not the one a vendor recommends, but the simplest one that defends against the adversaries you can name, has a recovery story your future self can execute, has an inheritance story your heirs can execute, and that you have actually tested end-to-end. A Privacy practice cluster extends the operational frame to the chain-analysis exposure layer.

How to use this sub-MOC

The operational notes are arranged in nine clusters, in roughly the order a thoughtful holder should engage them:

  1. Foundational framing — the lenses every other note uses
  2. Storage and key concepts — the cryptographic primitives and operational vocabulary
  3. Hardware wallets — the comparative landscape and per-device assessments
  4. Custody configurations — single-sig (with optional passphrase variant), multisig, and collaborative-multisig spanning the operational-complexity range
  5. Backup, recovery, and rehearsal — the discipline that makes a setup actually a setup
  6. Operational security — the behavioural layer that catches most real-world losses
  7. Privacy practice — the chain-analysis exposure layer; the operational defences that complement custody
  8. Inheritance — the failure mode that has consumed a material fraction of all Bitcoin ever mined
  9. Running your own node — the sovereignty layer beyond the keys

Each cluster can be read on its own, but the clusters are themselves ordered — framing before primitives, primitives before configurations, configurations before inheritance. The section is operational and decision-supporting rather than theoretical-argumentative; the notes should help you act, not just understand.

The framing lenses

Three lenses run through every operational note. They are codified as concept notes of their own; everything else in the section refers back to them.

The two failure modes. Every custody decision trades off loss (you can no longer access your own Bitcoin) against exposure (someone else now can). Almost every defence against one failure mode makes the other worse — passphrases protect against exposure but introduce loss risk; geographic distribution protects against local exposure but introduces coordination loss risk; Shamir-splitting protects against share theft but reconstructs the seed singularly at recovery. Good design is not the absence of trade-offs; it is making trade-offs you can articulate, for a threat model you can name. See Loss vs exposure failure modes.

The threat model. Self-custody decisions only make sense once you have named the adversaries you are defending against. The six categories synthesized from Blockchain Commons’ 27-adversary framework: yourself (the largest single category — forgetfulness, novel schemes, dying without documentation), environmental (fire, flood, hardware failure), remote attackers (phishing, malware, supply chain), local physical attackers (burglary, the “$5 wrench”), socially close parties (family, roommates, heirs), and institutional/legal (custodian failure, court orders, capital controls). Different holders should adopt different setups. See Threat modeling for self-custody.

The configuration ladder. The major self-custody setups arrange themselves in ascending complexity: single-sig → single-sig + passphrase → SLIP-39 → DIY 2-of-3 multisig → collaborative 2-of-3 → 3-of-5 → with BIP-85 as an orthogonal simplifier across the ladder. Each rung solves a real problem; each rung introduces new failure modes. The central question is not “what is the best setup” but “what is the least complex setup that adequately covers my threat model?” See Self-custody configuration ladder.

Foundational framing

These three notes establish the lenses. Read them before the rest of the section — they make the trade-offs in every subsequent note legible.

  • Loss vs exposure failure modes — The opposing-risks rule of thumb; the historical record of lost-vs-stolen Bitcoin; the principle that good design is articulated trade-offs.
  • Threat modeling for self-custody — The six adversary categories; the “name your top three” exercise; the structural reason why different holders should adopt different setups.
  • Self-custody configuration ladder — The seven canonical configurations from single-sig to 3-of-5 to BIP-85-orthogonal, with combined setups (helpful, questionable, actively harmful) called out separately. The synthesizing note for the section.

Storage and key concepts

The cryptographic primitives and operational vocabulary. These notes describe what you are protecting, in the precise terms the rest of the section uses.

  • Hot vs cold storage — The dimension that organizes everything else. The tiered-wallet approach (hot for transactions, cold for reserves, deep-cold for savings) and why mixing them is the principal pattern across practitioners.
  • Seed phrases and BIP-39 — The BIP-39 standard, the 12/24-word convention, what a seed phrase is and is not (a seed phrase is not a password — anyone who sees it has everything forever).
  • Passphrases and the 25th word — The optional BIP-39 passphrase, plausible deniability, the passphrase-backup problem (the most common documented inheritance failure mode in the synthesis).
  • BIP-85 child seeds — Deterministic derivation of child seeds from a master; orthogonal to custody schemes; reduces backup count but concentrates failure on the master.
  • SLIP-39 and Shamir Secret Sharing — Mathematical M-of-N splits; the critical recovery-time caveat (the seed is reconstructed singularly on one device at restore); how it differs from multisig.
  • PSBT and wallet descriptors — The unglamorous infrastructure: Partially Signed Bitcoin Transactions and wallet descriptors. The descriptor as first-class backup artifact for multisig.

Hardware wallets

The comparative landscape and per-device assessments. The overview note establishes the framework (air-gap, open-source firmware, multisig support quality, PSBT/descriptor support, vendor track record, progress indicators); the product notes assess specific devices against it.

  • Hardware wallets overview — The 2026 device table; what to actually look for; vendor diversity as cheap insurance in multisig.

Product notes (Variant B):

  • Coldcard — The power-user device; Coldcard Q with QWERTY and QR/NFC; strong BIP-85 and multisig support.
  • Trezor — Trezor Safe 5; native SLIP-39; colour touchscreen.
  • BitBox — BitBox02 BTC-only; Swiss engineering; open-source; pairs well in multi-vendor multisig.
  • Ledger considerations and tradeoffs — Honest assessment including the 2023 Recover controversy; framing for the holders who already own one.
  • Foundation Passport — Strict QR air-gap; pleasant UX; removable battery.
  • Blockstream Jade — Budget-conscious; good multisig support; 2026 Unchained integration.
  • Bitkey — Non-technical, mobile-first; no screen; higher app reliance.

Custody configurations

Three operational configurations spanning the simplicity-to-complexity range, from baseline single-sig (with the optional passphrase variant as a layered modification) through engineered multi-key answers to the trade-off problem. The ladder note is the synthesis; these notes are the specifics.

  • Single-sig and passphrase setups — the baseline configuration: standard single-sig spending, the passphrase variation that protects against seed exposure at the cost of new loss risk, and common operational patterns (decoy wallets; multi-passphrase compartmentalization across wallets).
  • Multisig setups — DIY 2-of-3 sovereign multisig: vendor diversity, geographic distribution, the six-items-to-manage problem, re-keying mechanics, why 3-of-5 is the right answer only for a small minority.
  • Collaborative custody services — 2-of-3 with a partner key: Unchained (white-glove, inheritance-focused), Casa (multi-key architecture), Nunchuk (sovereignty-minimized), The Bitcoin Adviser (estate-planning bent). Sovereign recovery as the critical evaluation criterion.

Backup, recovery, and rehearsal

The discipline that turns a setup into a tested setup. The synthesis’s strongest claim: a backup that has not been tested is not a backup; it is a hope.

  • Backup strategies for seeds — Paper, metal, geographic distribution, the wallet descriptor as a first-class artifact, what to do with the passphrase backup.
  • Steel seed storage — Specific metal products, Lopp’s four rounds of stress tests, the failure rate of products marketed as indestructible, what actually survives heat/corrosion/deformation.
  • Recovery rehearsal practice — The first rehearsal (wipe and restore with small amounts before funding the wallet); periodic rehearsals; signed-challenge-message lightweight rehearsals; what to actually test.

Operational security

The behavioural layer. The synthesis is direct: technical security is a ceiling, not a foundation; a material fraction of real-world losses are not cryptographic but human.

  • Common attack vectors — Phishing as the single highest-incidence threat; clipboard malware; address replacement; supply-chain attacks; the KYC-data-to-home-invasion pipeline; the $5 wrench attack.
  • Operational security practices — Don’t talk about Bitcoin (Lopp’s single-most-emphasised point); compartmentalised KYC identity; the cognitive-state rule for transactions; the limits of decoy and duress patterns.
  • Common failure modes in self-custody — The catalogue: the passphrase no one knew about, the forgotten passphrase, the untested metal backup, co-located multisig, the lost wallet descriptor, the seed photo, the phishing signature, the novel scheme.

Privacy practice

The chain-analysis exposure layer. Custody secures your access to your coins; privacy practice secures your linkage to them. The loss-vs-exposure framing extends naturally — privacy practice defends a specific exposure mode: third parties knowing which coins are yours, with what history, at what scale. The adversary categories most directly engaged are remote attackers (the chain-analysis industry), institutional/legal (KYC-driven record-keeping made active by exchange breaches or court orders), and local physical attackers (the chain-analysis-to-home-invasion pipeline that Common attack vectors flags). The cryptographic-privacy theoretical lineage (Chaum, the cypherpunks, mix-network theory) is in History and origins via David Chaum and Tim May and is referenced from here, not duplicated. The six-note cluster is organised as three sub-clusters internally.

Threat model and chain-analysis

  • Address reuse and chain analysis — The foundational threat. How chain-analysis firms cluster addresses; the common-input-ownership and change-detection heuristics; the practical exposure of address reuse; what hygiene defeats most clustering.
  • KYC leakage — The institutional-exposure surface. What KYC records create; how exchange breaches and court orders activate them; the practical defences (compartmentalised identities, withdrawal hygiene, the gap that mixing tools open).

Privacy-enhancing tools

  • CoinJoin — The principal privacy-enhancing transaction pattern; mechanism with light hand; tool history including the 2024 Samourai indictment and Wasabi voluntary wind-down; the current state of CoinJoin tooling and what’s available today.
  • PayJoin — BIP-78 cooperative funding; how it breaks the common-input-ownership heuristic without requiring coordination rounds; current adoption.
  • Stealth addresses and Silent Payments — The recipient-side privacy primitive; predecessor stealth-address designs; BIP-352 Silent Payments as the current state of the art; what wallets implement it.

Lightning privacy

  • Lightning privacy properties — What Lightning hides (the transaction graph for routed payments) and what it doesn’t (channel open/close on-chain footprints, routing-node observability, receive-side leakage); the operational implications.

Inheritance

The failure mode that has quietly consumed a material fraction of all Bitcoin ever mined — and the area where the operational content interfaces most deeply with the broader estate-planning literature.

  • Inheritance planning for bitcoin — How each ladder configuration handles inheritance (single-sig, single-sig + passphrase, DIY multisig, collaborative multisig, SLIP-39 to heirs); the revocable living trust as the legal wrapper; the inheritance rehearsal as the test that distinguishes a plan from a hope.

Bitcoin inheritance is best understood as a special case of estate planning. The broader estate-planning literature contributes the general principles — findability as the primary failure mode, beneficiary mechanisms (which Bitcoin lacks directly but trust structures can replicate), the distinction between legal bindingness and persuasive intent, planning-horizon and plan-staleness considerations, and non-grantor trust-vehicle design for substantial holdings. The Bitcoin-specific operational content lives in Inheritance planning for bitcoin; the general scaffolding is treated as broader background.

Running your own node

The sovereignty layer beyond the keys. Verifying your own transactions, not trusting third-party explorers, optionally serving as the backend for your own wallet.

Suggested reading orders

Different purposes warrant different sequences. None of these is canonical; they are entry points for different reader profiles.

For the brand-new holder

Someone who just bought Bitcoin on an exchange and wants to take self-custody for the first time:

  1. Loss vs exposure failure modes — the trade-off framing
  2. Threat modeling for self-custody — name your top three categories
  3. Hot vs cold storage — the foundational distinction
  4. Hardware wallets overview — choose a device
  5. Seed phrases and BIP-39 — what you are actually backing up
  6. Backup strategies for seeds — how to back it up
  7. Recovery rehearsal practice — test before you fund
  8. Common attack vectors — what to watch for

This sequence gets a new holder from exchange-custody to tested single-sig on a hardware wallet — the configuration most newcomers should adopt and most newcomers should not yet move beyond.

For the holder considering multisig

Someone with a tested single-sig setup whose holdings have grown enough to justify reconsidering:

  1. Self-custody configuration ladder — where on the ladder you actually need to be
  2. Threat modeling for self-custody — re-rank your adversaries at higher holding size
  3. Multisig setups — the DIY 2-of-3 framework
  4. Collaborative custody services — the partnered alternative
  5. PSBT and wallet descriptors — the infrastructure you must understand to operate a multisig
  6. Inheritance planning for bitcoin — the load-bearing consideration that often tips the choice toward collaborative

The decision between DIY 2-of-3 and collaborative 2-of-3 is often determined by inheritance, not by the operational mechanics.

For the holder planning inheritance

Someone who is already custodying competently but realises they have not actually planned for their own absence:

  1. Inheritance planning for bitcoin — Bitcoin-specific operational framework
  2. Common failure modes in self-custody — the inheritance-specific patterns (the passphrase no one knew about)
  3. Recovery rehearsal practice — the inheritance-rehearsal pattern

This sequence treats Bitcoin inheritance as a special case of estate planning rather than a standalone problem. The broader estate-planning principles — findability as the primary failure mode, beneficiary mechanisms, planning horizons, and non-grantor trust design for substantial holdings — are foundational background that the Bitcoin-specific operational content fits within.

For the operational-security focus

Someone who has accepted their setup is reasonable and wants to harden the behavioural layer:

  1. Common attack vectors
  2. Operational security practices
  3. Common failure modes in self-custody
  4. Recovery rehearsal practice

These four notes together capture the bulk of what Lopp’s two decades of empirical work emphasises: opsec is where most real-world losses actually happen.

For the holder focused on privacy hygiene

Someone who is custodying competently and wants to address the chain-analysis exposure layer:

  1. Address reuse and chain analysis — the foundational threat
  2. KYC leakage — the institutional-exposure surface
  3. CoinJoin — the principal mitigation and current tooling reality
  4. PayJoin — the cooperative-funding alternative
  5. Stealth addresses and Silent Payments — recipient-side mechanisms
  6. Lightning privacy properties — what Lightning adds and doesn’t add

This sequence assumes basic custody is solved. Privacy practice is a layer of refinement, not a substitute for the rest of the section — the threat-modeling and operational-security clusters remain prerequisites because most real-world deanonymisations begin with opsec failures, not cryptographic ones.

Key connections to other areas

This section is the operational destination for several theoretical arguments developed in other sections.

To Culture philosophy and the morality of money:

To Economics and monetary theory:

To the broader estate-planning framework:

  • The general principles of estate planning — findability as the primary failure mode, beneficiary mechanisms, the distinction between legal bindingness and persuasive intent, and planning-horizon considerations — are the load-bearing background for Bitcoin inheritance work. The Bitcoin-specific operational content lives in Inheritance planning for bitcoin; the general scaffolding is treated as well-established background.

To trust-vehicle considerations:

  • For holders whose threat model includes large-estate creditor or tax considerations, non-grantor trust design and related trust-vehicle considerations apply. The general trust-design literature operates as background; it is not recapitulated here.

What this area doesn’t cover

This sub-MOC is intentionally bounded. Several adjacent topics belong elsewhere:

  • Lightning-specific operational detail — channel management, watchtowers, routing — belongs to the Scaling and Layer 2 section, with cross-references from here for the connection. The Lightning privacy properties note in the Privacy practice cluster is the boundary case — it treats privacy implications, not operational Lightning detail.
  • Cryptographic-privacy theory and the cypherpunk lineage — Chaum’s eCash, mix-network theory, the pre-Bitcoin cryptographic-privacy tradition — belongs to History and origins via David Chaum, Tim May, and Pre-Bitcoin attempts at internet money. The Privacy practice cluster references these but does not duplicate them; its voice is operational, not historical-theoretical.
  • Privacy-coin comparison — Monero, Zcash — is out of scope. Brief acknowledgments OK; no substantive treatment.
  • Regulatory and sanctions framing of mixing tools — Tornado Cash precedent, BSA implications, the legal-doctrine treatment — defers to the Regulation policy and geopolitics section. The Privacy practice cluster treats tool-history operationally (what tooling exists today, why) but not the legal doctrine.
  • Tax accounting and jurisdictional questions — belong to the Investing and markets section (or potentially a dedicated section if scope warrants)
  • Custodial services as investment vehicles — ETFs, treasury vehicles, custodial Lightning — are partly addressed here where they affect self-custody decisions but principally belong to Investing and markets
  • Software-engineering detail — programming Bitcoin transactions, implementing wallets — belongs to the Technical foundations section
  • The UX-and-accessibility critique of self-custody — the argument that key management is too hard for mainstream adoption to ever be self-custodied at scale — is treated as a Bitcoin criticism in User experience and accessibility friction (homed in Criticisms of Bitcoin). This section treats the operational reality — how to actually custody well across threat models and skill levels — rather than re-arguing the critique (sequestered-negativity).

Each adjacent area has or will have its own sub-MOC.

Open questions in this area

Each note will have its own open questions. The area-level questions that cut across multiple notes:

  • How does the section accommodate the rapid evolution of the hardware-wallet landscape? Specific products and firmware versions will drift; the “as of [date]” convention helps but does not solve the problem.
  • Where does collaborative custody belong on the configuration ladder? The synthesis treats it as a reasonable mid-tier; the moral framing in Self-custody as a moral act may push toward DIY for holders who can manage it.
  • How tightly should the inheritance treatment couple to broader trust-vehicle considerations? Bitcoin-specific operational content stays here, but the line is genuinely fuzzy at the trust-design end where the broader estate-planning literature takes over.
  • What is the right cadence for revisiting the configuration-ladder note? The seven canonical configurations are stable, but the combined-setups and actively-harmful patterns will evolve as the field evolves.
  • Should there be a dedicated note on the “$5 wrench attack” given its 2025 surge per Lopp’s database? Or does it belong inside Common attack vectors?
  • How does the section treat the emerging multi-party-computation (MPC) custody space, currently dominant in institutional crypto but contested in self-custody? The synthesis sidelines it; the operational notes should mention it but not necessarily build it out as a configuration.

Canonical sources across the area

The section’s principal reference is the LegacyCipher synthesis document — “Bitcoin Self-Custody & Security: A Synthesis of Contemporary Best Practices,” LegacyCipher Knowledge Base, April 2026. The synthesis itself draws on:

Primary practitioner sources (cited heavily throughout the section):

  • Jameson Lopp — blog at lopp.net; Physical Bitcoin Attack database; “21 tips for securing your bitcoin”; the 2020 and 2024 Multisig Hardware Signing Performance reports; four rounds of Metal Seed Storage Stress Tests. See Jameson Lopp for biographical and corpus material.
  • Blockchain Commons Smart Custody — the Smart Custody Book (CC-BY-SA), the cold-storage scenario, the twenty-seven-adversary personification framework.
  • 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”; operational security guides.
  • Nunchuk — “Bitcoin Self-Custody: A Path Forward”; “Multisig Made Easy.”
  • Casa — case studies; “Shamir Secret Sharing Shortcomings”; the seedless-security model.
  • The Bitcoin Adviser — estate-planning and inheritance guidance.

Underlying specifications:

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

Hardware-vendor documentation (cited from the product notes):

  • Coldcard documentation — BIP-85 implementation details
  • BitBox — BIP-85 and passphrase operational guides
  • Trezor — SLIP-39 support documentation
  • Foundation — Passport documentation

Reading these (plus the LegacyCipher synthesis as the integrating document) covers the bulk of the canonical operational literature.

The principal author the section leans on:

  • Jameson Lopp — two decades of empirical security work; the single most-referenced practitioner across the synthesis

The moral frame the operational practice expresses:

The broader estate-planning framework:

  • Bitcoin inheritance is best understood as a special case of estate planning. The general principles — findability as the primary failure mode, beneficiary mechanisms, the distinction between legal bindingness and persuasive intent, planning-horizon considerations, and non-grantor trust-vehicle design for substantial holdings — are foundational background that the Bitcoin-specific operational content fits within. See Inheritance planning for bitcoin for the Bitcoin-specific treatment; the general framework is treated as well-established background.

Graph View

Backlinks