Inheritance is the failure mode that has quietly consumed a material fraction of all Bitcoin ever mined — Chainalysis estimates 11–18% is permanently lost, with inheritance failure accounting for a substantial share. The Gannett Trust's 2026 report frames the moment as a tipping point: the earliest cohorts of holders are aging into accident, illness, and cognitive-decline years while their holdings have grown large enough to materially affect their families. Each ladder configuration has distinct inheritance properties — single-sig fails without context; single-sig with passphrase fails through the passphrase only the holder knew; DIY multisig is hard for non-technical heirs; collaborative multisig is best-aligned because the partner already holds a key, the descriptor, and the expertise; SLIP-39 to heirs is elegant on paper, mixed in practice. The discipline that distinguishes setups that work from setups that don't is the inheritance rehearsal — the designated heir walks through recovery dry-run while the holder is present. The Bitcoin-specific operational content slots into the broader estate-planning framework (findability, beneficiary mechanisms, trust-vehicle design).


Why this note matters

This is the principal cross-KB note for the Practical self-custody and sovereignty section. Where every other operational note assumes the holder is alive and cognitively intact, this note treats the scenario where they are not — and the operational discipline that determines whether the Bitcoin transfers to its intended heirs or joins the permanently-lost pool.

The note matters because:

  • It treats inheritance as a first-class operational concern rather than an afterthought. The synthesis is direct: inheritance failure accounts for a substantial share of permanently-lost Bitcoin.
  • It surfaces the configuration-specific inheritance properties that the configuration ladder doesn’t fully address. Each rung of the Self-custody configuration ladder has a different inheritance profile.
  • It establishes the inheritance rehearsal practice as the load-bearing discipline. Rehearsals distinguish setups that work from setups that don’t.
  • It frames Bitcoin inheritance as a special case of the broader estate-planning problem. The operational content here is Bitcoin-specific; the general principles (findability, beneficiary mechanisms, planning horizons, trust-vehicle design) operate as the broader scaffolding into which this note slots.

What this is

Inheritance planning for Bitcoin is the practice of ensuring that, in the event of the holder’s death or incapacitation, the Bitcoin transfers to the intended heirs in a way they can actually access. The discipline includes:

  • Configuration considerations — which custody configurations support inheritance well and which don’t
  • Documentation — what heirs need to know and how it should be communicated
  • Legal scaffolding — trust vehicles, beneficiary designations, jurisdictional considerations
  • Rehearsal — verifying the inheritance plan works by actually exercising it
  • Updating — keeping the plan current as configurations evolve, family changes, and life events occur

The practice spans the technical layer (the multisig setup), the human-readable documentation layer (instructions heirs can follow), and the legal layer (trust documents, wills, beneficiary designations). All three must be coherent for the inheritance to work.


The 2026 inflection point

The Gannett Trust’s 2026 report (cited widely in the industry) frames 2026 as a tipping point for Bitcoin inheritance:

  • The earliest cohorts of Bitcoin holders (those who acquired Bitcoin 2010–2015) are now in their 40s, 50s, and 60s
  • Health events, accidents, and cognitive decline are becoming statistically relevant
  • The same cohorts often hold substantial Bitcoin — early adoption plus appreciation
  • The inheritance failure mode is no longer theoretical; it is actively materializing

Chainalysis research estimates roughly 2.3–3.7 million BTC — about 11–18% of the 21-million supply — is already permanently lost; inheritance failure accounts for a meaningful share (alongside early-loss patterns from the 2010–2013 era when holders treated Bitcoin as worthless).

The implication: inheritance planning is moving from “good practice for when I’m older” to “current operational discipline I must address now.”


How each configuration handles inheritance

Single-sig

Simplest in theory — “here is the seed phrase.” Most common to fail in practice — because “here is the seed phrase” is only useful if the heir knows:

  • What the seed phrase is and what it is for
  • Which wallet software to import it into
  • What derivation path was used (less critical for modern standard paths)
  • Whether a passphrase is also required
  • How to actually move the funds after importing

A scribbled metal backup without context is a mystery puzzle. The heir may discard it, treat it as junk, lose contact with whoever knew what it was for, or wait too long to investigate.

Defences:

  • Clear written documentation alongside the backup: “This is a Bitcoin seed phrase. To use it, do X.”
  • Inheritance rehearsal — walk the heir through the procedure during the holder’s lifetime
  • Estate-plan integration — the wallet’s existence and basic recovery procedure are noted in the will or trust

Single-sig with passphrase

The most-cited inheritance failure mode in the synthesis. The pattern (from Common failure modes in self-custody):

  1. Holder picks a strong passphrase
  2. Memorizes it
  3. Never writes it down
  4. Dies or becomes incapacitated
  5. Heir finds the seed phrase; loads it into a wallet; sees an empty (decoy) wallet
  6. Heir concludes there was nothing; the real wallet is permanently inaccessible

The seed phrase being backed up creates the false impression that the wallet is recoverable. It isn’t.

Defences:

  • The passphrase must be backed up with the same rigor as the seed
  • The passphrase backup goes in a different location from the seed (so finding the seed doesn’t reveal the passphrase, but heirs can find both)
  • Inheritance documentation must explicitly mention the existence of the passphrase
  • For substantial holdings, SLIP-39 split of the passphrase among trusted parties provides post-mortem recovery without compromising lifetime security

DIY multisig

Unchained is direct about this configuration’s inheritance challenge:

Creating functional instructions for your loved ones on how to find your multiple, separate keys and recover your bitcoin is not always as simple as it sounds, especially if you want to leave no room for error. Your loved one will need to know how to access and use your wallet configuration file, find your multiple seed phrases and load them into one or more hardware wallets, and use those devices to perform signatures for the withdrawal.

For technically-inclined heirs, DIY multisig inheritance is achievable. For most heirs, it is not.

Defences:

  • Detailed inheritance documentation explaining:
    • The locations of all three keys
    • The wallet descriptor and what it is
    • Which coordinator software to use (with specific recommendation)
    • The PSBT flow at the level a non-technical reader can follow
  • Engagement with a technical executor or trusted technical party who can guide the heirs
  • Inheritance rehearsal — non-negotiable for DIY multisig
  • Consider whether DIY multisig is the right configuration given the inheritance requirement; for many holders, collaborative custody is structurally better

Collaborative multisig

The best-aligned of the major configurations for inheritance. The structural reason: the partner already has one key, the wallet descriptor, and the technical expertise. The heir’s task is simplified:

  1. Contact the partner (provided in inheritance documentation)
  2. Validate identity (typically with attorney coordination and a death certificate)
  3. Access one of the holder’s two keys
  4. Partner provides the second signature
  5. Funds move to the heir’s setup

Unchained, Casa, and The Bitcoin Adviser all treat inheritance as a first-class feature. Each has documented procedures, attorney relationships, and templates the holder can adopt.

This is the principal argument for collaborative custody for holders with non-trivial inheritance situations. See Collaborative custody services.

SLIP-39 distributed to heirs

Elegant on paper, mixed in practice. The pattern:

  • Split the seed into N shares via SLIP-39
  • Distribute shares to N trusted parties (heirs, attorneys, family members)
  • After the holder’s death, the parties combine the shares to recover

The central risks (per the synthesis):

  • Shares must be kept secure for decades — any party may compromise, lose, or misinterpret theirs over time
  • Coordination at recovery time requires the parties remain in contact and willing
  • Heir disputes or family fall-outs can prevent coordination
  • The share-holders may treat the share as junk over time, not recognizing what it is

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.

BIP-85 considerations

BIP-85 child seeds inherit the same way the master does — through the master’s inheritance plan. But the heir must understand:

  • That BIP-85 is in use
  • Which indexes were used for which purposes
  • How to derive the children if needed

Without this documentation, the heir with only the master seed may not realize that additional wallets derive from it.


Across the inheritance-focused sources — The Bitcoin Adviser, Casa, the Gannett Trust report, River’s inheritance writing — a consensus emerges around the revocable living trust as the practical legal wrapper for Bitcoin inheritance.

The structural role

The trust holds:

  • The inheritance instructions — written guidance for executor and heirs
  • The custody documentation — what wallets exist, where to find materials, how to recover
  • The legal authority — the trustee has the authority to execute the plan
  • The successor framework — who steps in if the primary trustee is unavailable

The trust does not typically hold the Bitcoin itself directly — though some configurations do this for jurisdictional or tax reasons. The trust scaffolds the inheritance; the technical custody setup provides the mechanism.

The trustee role

The trustee (often a family attorney with digital-asset experience) has the authority to execute the plan. Their role:

  • Mediate between the technical custody setup and the heirs
  • Coordinate with collaborative-custody partners if applicable
  • Manage timing — Bitcoin’s value volatility, tax considerations, jurisdictional issues
  • Provide a neutral party in cases of family disputes about the holdings

For Tier 2+ holdings, engaging a digital-asset-experienced attorney during the holder’s lifetime is the standard recommendation. Boilerplate wills often fail to handle Bitcoin correctly.

Integration with broader estate-planning frameworks

Bitcoin-specific inheritance work integrates with a broader estate-planning literature whose central principles are well-established outside Bitcoin: findability as the primary failure mode — heirs who cannot locate the materials cannot recover them, regardless of how robust the technical setup; beneficiary designations and the way they override wills — a legal mechanism Bitcoin does not have directly, but which trust structures can replicate; the distinction between legal bindingness and persuasive intent — what the trust enforces versus what it suggests; and planning-horizon and plan-staleness considerations — the temporal dimension that affects all estate planning, especially over multi-decade Bitcoin holding periods. For substantial holdings, non-grantor trust design and related trust-vehicle considerations apply. The Bitcoin-specific operational content stays in this note; the general estate-planning principles operate as the broader scaffolding.


The inheritance rehearsal

Several sources — Casa, The Bitcoin Adviser, Unchained, the synthesis itself — now recommend a periodic inheritance rehearsal in which the designated trustee or heir walks through the recovery process with the living holder.

The structure

Not a production recovery — a dry run:

  1. The holder provides the inheritance documentation (as it would be discovered post-death)
  2. The heir (or trustee), using only the documentation, attempts to locate the materials
  3. The heir, using only the documentation, attempts to perform the recovery — typically with a small test balance
  4. The holder observes and answers questions only where the documentation is unclear
  5. Where the procedure fails or stalls, the documentation is updated

What it tests

Can the heir actually:

  • Find the materials?
  • Understand the instructions?
  • Use the wallet software?
  • Coordinate the signatures (for multisig)?
  • Locate the trustee or partner if collaborative?
  • Manage the timing and tax considerations?

If not, the setup is documented incorrectly. The point of the rehearsal is to discover this while the holder is still available to fix it.

Cadence

  • At inheritance-plan creation — initial verification
  • At major life events — births of heirs, divorces, holder relocations, custody-configuration changes
  • Every 3-5 years — to catch drift

The cadence is operational; some holders engage it annually as part of broader estate-plan review.

Where it fits in the section

This is the inheritance-specific version of Recovery rehearsal practice. The recovery-rehearsal note treats rehearsal at the holder level; the inheritance rehearsal treats it at the heir level.


What needs to be documented

The minimum-viable inheritance documentation:

Existence and overview

  • The fact that Bitcoin holdings exist — many heirs don’t know
  • Approximate amount — sufficient to indicate seriousness
  • Why this matters — context for the heir’s engagement

Material locations

  • The hardware wallets — where each device is
  • The seed backups — where each metal backup is, with location notes detailed enough that a non-resident heir can find them
  • The passphrase backup (if applicable) — separate location; explicit existence note
  • The wallet descriptor (for multisig) — location(s)
  • The documentation itself — primary copy, backup copies

Technical instructions

  • The configuration — single-sig, multisig, etc., at a level the heir can understand
  • Which wallet software to use — specific recommendation
  • The signing flow — basic steps for routine recovery
  • What to verify — basic anti-phishing instructions

Recovery procedure

  • For single-sig: import seed (plus passphrase) into the recommended wallet; verify addresses; transfer to heir’s destination
  • For multisig: contact partner (if collaborative); locate all keys; coordinate the signing; transfer
  • For complex configurations: a step-by-step procedure

Contact information

  • Trustee or attorney — name, contact, role
  • Collaborative-custody partner (if applicable) — name, contact, role
  • Technical executor or advisor (if applicable) — name, contact, role
  • Tax/financial advisor — name, contact, for the financial-planning side

Update history

  • When the documentation was last reviewed — for the rehearsal cadence
  • What changed since the prior version
  • The current state of the configuration

Tradeoffs and considerations

The privacy-vs-findability tension

Inheritance documentation requires that materials be findable by heirs. But materials that are findable are also potentially findable by attackers (burglary, family member discovery during the holder’s lifetime).

Mitigations:

  • Sealed documentation accessible only after death (sealed envelope with attorney; specific provisions in trust documents)
  • Encrypted documentation with the decryption key held by the trustee
  • Geographic distribution that requires multiple parties to coordinate
  • Time-released information (a service that releases instructions after a holder doesn’t check in)

The tension is structural; the right resolution depends on the threat-model priorities.

The “what the heir actually needs” question

A common documentation failure: the holder writes for themselves rather than for the heir. The holder knows what “BIP-39 seed phrase” and “wallet descriptor” mean; the heir may not.

The documentation should be readable to the actual heir. A useful test: have a non-technical friend or family member (someone not engaged with Bitcoin) read the documentation and explain what they would do. Where they can’t, the documentation is unclear.

The configuration’s inheritance burden

Different configurations impose different inheritance burdens. The holder’s choice should consider not just the configuration’s security properties but also its inheritance properties:

  • A 3-of-5 multisig with five geographically-distributed keys is structurally secure during the holder’s lifetime; it may be effectively impossible for non-technical heirs to recover
  • A collaborative 2-of-3 with a partner is operationally complex but inheritance-friendly because the partner handles the technical layer
  • A single-sig with strong documentation is inheritance-simple but exposure-fragile during the holder’s lifetime

The configuration choice should reflect the holder’s full lifecycle, not just the active-holder phase.

The longevity question

Inheritance planning must survive over a 30+ year horizon (the holder’s remaining lifetime plus the time until the heir actually executes). During this period:

  • Hardware wallets may go out of production
  • Wallet software may be discontinued
  • Coordinator software may evolve
  • Collaborative-custody partners may merge, change ownership, or fail
  • Family situations may change
  • Jurisdictions may modify the legal framework

The inheritance plan must be updateable. The holder should review and refresh the plan periodically (annually or every 3-5 years).

Tax and jurisdictional considerations

The full tax-and-legal treatment of Bitcoin inheritance is beyond this note’s scope (and belongs to specialist counsel). But the operational note should flag:

  • Bitcoin holdings may trigger tax obligations at the holder’s death (estate tax, step-up basis considerations)
  • The heir’s recovery timing affects tax treatment
  • Jurisdictional considerations apply — Bitcoin in a US holder’s estate is treated differently than Bitcoin in a non-US holder’s estate
  • For substantial holdings, integrating Bitcoin inheritance with broader estate planning is structurally important

The Bitcoin Adviser and similar specialty providers focus specifically on this integration. For Tier 2+ holdings, engaging this expertise is warranted.


Tiered application

Tier 0: Basic note in the holder’s estate planning that Bitcoin holdings exist; the wallet is on a phone and recovery requires the phone access. Limited inheritance discipline needed.

Tier 1: Documentation that includes:

  • The hardware wallet existence and location
  • The seed backup location
  • The passphrase backup location (if used)
  • Basic recovery instructions
  • Designation of the heir or executor who can engage the recovery

For a Tier 1 setup, the documentation can fit in a single page or two of the holder’s estate plan.

Tier 2: Substantially more rigorous:

  • Detailed documentation per the “what needs to be documented” section above
  • Inheritance rehearsal with the primary heir at plan creation
  • Collaborative-custody partner integrated into the plan if applicable
  • Trust-vehicle integration for legal scaffolding
  • Annual review

Tier 3: Continuous operational practice:

  • Attorney-coordinated inheritance plan
  • Multiple rehearsals with multiple heirs
  • Trust-vehicle integration with substantial complexity (multiple trustees, succession provisions)
  • Jurisdictional considerations integrated
  • Professional advisors retained
  • Quarterly or biannual plan review

In all tiers: the inheritance plan should be actually rehearsed, not just documented. Documentation without rehearsal is the dominant failure mode.


Common pitfalls

Treating inheritance planning as a future task. The 2026 inflection point is now. Holders in their 40s and 50s should engage; holders in their 60s+ should engage urgently.

The “passphrase only in my head” pattern. The most-cited inheritance failure mode. The passphrase must be backed up with the same rigor as the seed.

Writing documentation for yourself rather than for the heir. The heir may not know what a BIP-39 seed is. Use language they will understand.

Skipping the inheritance rehearsal. Documentation that has never been exercised by the heir is structurally fragile. The rehearsal catches gaps the holder didn’t see.

Treating multisig as inheritance-friendly because it’s “more secure.” DIY multisig is meaningfully harder to inherit than single-sig. The configuration choice should reflect the heir’s actual capability.

Boilerplate wills that don’t handle Bitcoin. Standard estate-planning documents often don’t address digital assets adequately. Specialist counsel is warranted for substantial holdings.

Outdated documentation. Setups evolve; family changes; collaborative-custody partners change. Annual review catches drift.

Excluding heirs from the planning conversation. Heirs who first learn about the holding at the holder’s death are at a disadvantage. Where appropriate, engage heirs in the planning while the holder can guide.

Treating collaborative custody as the complete answer. The partner provides substantial inheritance support but does not replace the holder’s documentation discipline. The holder’s two keys, the descriptor backup, the heir’s awareness of the partner — all are still load-bearing.

No succession planning for the trustee. The trustee themselves may die or become unavailable. The plan should specify successor trustees.

Treating the inheritance plan as private to the holder. A plan no one knows exists is functionally no plan. At minimum, the primary heir and the trustee should know the plan exists and where to find it.

Ignoring the tax-and-legal dimensions. Bitcoin inheritance has tax implications that affect timing and execution. Coordinate with tax-and-legal advisors.

The “I’ll do this when I’m older” pattern. Accidents and acute health events don’t wait. The plan should be in place before it’s needed.


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 LegacyCipher product is specifically inheritance-focused; the synthesis treats inheritance as a first-class concern.

Inheritance-focused practitioner sources:

  • The Bitcoin Adviser — thebitcoinadviser.com; estate-planning-focused collaborative custody
  • Casa — published inheritance procedures; in-product inheritance support
  • Unchained — formal inheritance protocols; attorney coordination
  • Nunchuk — sovereignty-focused inheritance guidance
  • The Gannett Trust — 2026 inheritance report; the inflection-point framing

Trust-vehicle and estate-planning resources:

  • The published estate-planning literature on findability, beneficiary mechanisms, planning horizons, and trust-vehicle design — the general framework Bitcoin-specific inheritance content slots into
  • Specialist trust-and-estate attorneys with digital-asset experience — the Bitcoin Adviser maintains referrals; some collaborative-custody providers have lists

The synthesis’s specific recommendations:

  • Revocable living trust as the legal wrapper (drawing on the broader trust-design literature)
  • Inheritance rehearsal as the central practice
  • Collaborative custody for non-trivial inheritance situations
  • Attorney coordination for Tier 2+ holdings

As of 2026-05-14: the inheritance-planning landscape is maturing. LegacyCipher (the source of the synthesis document) is specifically a Bitcoin inheritance product. Casa, Unchained, and The Bitcoin Adviser have established procedures. The remaining variable is operational — whether holders engage the practice while it can still help.


Open questions for further development

  • The 2026 inflection-point framing is plausible but the empirical record is still developing. As more inheritance events materialize, what specific failure patterns emerge that the current framework underweights?
  • AI-assisted inheritance planning is emerging. Some services offer to generate inheritance documentation from a holder’s setup. Are these tools sufficient, or do they introduce new failure modes (the AI-generated documentation that doesn’t match the actual setup)?
  • The cognitive-decline question is increasingly relevant. Some holders may be in early decline without realizing it. What planning patterns help here? The “have the rehearsal while still cognitively sharp” recommendation is one answer; are there others?
  • The cross-jurisdictional inheritance question for internationally-distributed holders is non-trivial. Are there emerging frameworks that handle this well?
  • The “what is the right tax treatment for Bitcoin in an estate” question is jurisdiction-specific and evolving. Should the framework engage this more substantively, or treat it as out-of-scope?
  • Generation-skipping inheritance (Bitcoin held for grandchildren) raises unique challenges — the holding horizon extends 50-80+ years, hardware and software will evolve significantly, and the second-generation heir may not be born at planning time. Are there established patterns?

The framing context:

Configuration-specific inheritance:

Storage and key concepts:

Hardware wallets:

  • Hardware wallets overview — devices the heirs need to know about
  • Bitkey — consumer-facing collaborative custody specifically designed for inheritance support

Operational discipline:

The moral framework:

The principal practitioners:

  • Jameson Lopp — operational-security context
  • The Bitcoin Adviser, Casa, Unchained — inheritance-focused providers

The sub-MOC home: