Bitcoin Inheritance Planning: How to Pass Crypto to Heirs Without Losing Self-Custody

Bitcoin inheritance planning is one of the most overlooked aspects of self-custody. An estimated 3 to 4 million BTC are permanently lost according to Chainalysis research, reducing the effective circulating supply to roughly 16 to 17 million coins. Some of those losses stem from hardware failures and forgotten passwords. But a growing share comes from holders who die without leaving their heirs the means to access their Bitcoin.

The core tension is straightforward: the same properties that make Bitcoin resistant to seizure and censorship also make it resistant to inheritance. There is no bank to call, no "forgot password" flow, and no court order that can override a lost private key. Planning for succession means deliberately weakening your security model in controlled ways so that trusted parties can recover funds after your death, without giving them premature access.

Why Bitcoin Inheritance Fails

Traditional assets pass through well-established legal channels. Bank accounts freeze upon death notification, then release to named beneficiaries or through probate. Brokerage accounts support transfer-on-death (TOD) designations. Real estate follows deeds and titles.

Bitcoin has none of these mechanisms at the protocol level. A seed phrase written on paper in a safe deposit box works only if someone knows it exists, knows which box to open, and knows what to do with 12 or 24 words. The failure modes are numerous: heirs who do not know Bitcoin exists, backup media that degrades, passphrases stored separately from seeds with no instructions linking them, and estate attorneys unfamiliar with digital assets.

The inheritance time bomb: Early Bitcoin adopters are now in their 40s and 50s. As this cohort ages, the industry faces a wave of inaccessible Bitcoin unless holders plan proactively. Lost coins currently outpace new issuance: roughly 566 BTC per day age into "dormant" status (10+ years unmoved) while only 450 BTC are mined daily after the April 2024 halving.

Notable Cases of Lost Bitcoin

The consequences of poor inheritance planning are not theoretical. Several high-profile cases illustrate the scale of the problem:

Inheritance Strategy Overview

No single approach fits every situation. The right strategy depends on your technical comfort level, the size of your holdings, and how much you trust the people involved. The main approaches fall into five categories, each with distinct security and accessibility tradeoffs.

Shamir's Secret Sharing for Inheritance

Shamir's Secret Sharing (SSS) splits a seed into multiple shares using polynomial interpolation over a finite field. A threshold number of shares (say, 2 of 3 or 3 of 5) can reconstruct the original seed, while any fewer reveal zero information about it. The SLIP-0039 standard encodes each share as 20 or 33 mnemonic words, similar to BIP-39 seed phrases but incompatible with them.

How It Works for Inheritance

A holder creates a 2-of-3 Shamir backup and distributes shares to three parties: one kept personally, one given to a spouse, and one stored with an attorney. After death, any two of the three shares can reconstruct the seed and recover funds. No single share holder can access Bitcoin alone.

Trezor hardware wallets have supported SLIP-0039 since 2019. As of June 2024, Shamir backup became the default backup method for the Trezor Safe family of devices.

Limitations

• Reconstruction requires bringing shares together in one place, creating a single point of failure at recovery time
• Wallet support beyond Trezor is limited: most wallets cannot import SLIP-0039 shares directly
• No on-chain verification: unlike multisig, other participants cannot confirm the wallet state without the full seed
• If a share is compromised, you must reconstruct the full secret and re-split from scratch: there is no key rotation without full reconstruction

Multisig Inheritance Setups

Multisig wallets require multiple independent keys to authorize a transaction. For inheritance, a common pattern is 2-of-3: the holder keeps one key, a family member holds another, and a collaborative custody provider holds a third. After death, the family member and the custody provider can cooperate to move funds without the deceased's key.

Unlike Shamir's Secret Sharing, multisig never requires reconstructing a single secret. Each key signs independently, and the Bitcoin Script enforces the threshold on-chain. This eliminates the reconstruction vulnerability inherent in SSS.

Collaborative Custody Providers

Several companies now offer multisig vaults with built-in inheritance features. These services hold one key in the multisig quorum and provide operational support for beneficiary designation and key recovery.

Key tradeoff: Collaborative custody providers simplify inheritance but introduce counterparty risk. If the provider goes out of business, you must still be able to recover funds with your remaining keys. Always verify that you hold enough keys to meet the signing threshold independently.

Timelock Dead Man's Switches

Timelocks offer the most trust-minimized approach to Bitcoin inheritance. Using OP_CHECKSEQUENCEVERIFY (CSV), you can create a spending condition that activates only after a period of inactivity. The holder periodically moves their Bitcoin to reset the timer. If they stop (presumably due to death or incapacitation), the timelock expires and a designated recovery key can spend the funds.

How the Script Works

A simplified dead man's switch uses a two-path Bitcoin Script:

• Path 1 (normal spending): the owner's key can spend at any time with no restrictions
• Path 2 (recovery): the heir's key can spend only after a relative timelock (e.g., 26,280 blocks, roughly 6 months) has elapsed since the UTXO was last confirmed on-chain

The owner "refreshes" the switch by periodically sending the UTXO to a new address with the same script, resetting the relative timelock. CSV supports a maximum lock of 65,535 blocks (approximately 455 days). For longer inactivity periods, miniscript compositions or chained timelocks are required.

Wallet Implementations

Two wallets currently support timelock-based inheritance out of the box:

• Liana Wallet (by Wizardsardine): open-source desktop wallet using miniscript with a primary spending path and a recovery path that activates after a configurable inactivity period. Supports "decaying multisig" where fewer keys are needed as time passes.
• Nunchuk 2.0 (launched November 2025): autonomous on-chain inheritance for Honey Badger subscribers. After the timelock expires, the platform's key is automatically removed from the signing requirement, giving the beneficiary sole control.

Operational Considerations

• Each refresh requires an on-chain transaction with associated fees
• If you forget to refresh, the heir gains access prematurely
• The heir's recovery key must be stored securely but remain accessible: the same custody challenge, just shifted to a different party
• Output descriptors must be backed up alongside keys: without the descriptor, the wallet cannot be reconstructed even if all private keys are available

Miniscript: Programmable Inheritance Policies

Miniscript (BIP-379) enables composing complex spending policies from simple primitives: signature requirements, timelocks, and logical operators. For inheritance, this means you can express policies like "2-of-3 keys required now, but only 1-of-3 after 6 months of inactivity."

This "decaying multisig" pattern is particularly powerful. During normal operation, the full security of a multisig quorum protects the funds. After the holder's death (signaled by inactivity), the threshold drops so that surviving key holders can recover funds without meeting the original quorum.

Hardware wallet support for miniscript has expanded significantly. Signing devices including Coldcard, Blockstream Jade, and Ledger now support native SegWit miniscript. Taproot miniscript support is available on Coldcard, Ledger, and Specter DIY.

Custodial vs Self-Custodial Inheritance

For holders who prioritize simplicity over sovereignty, custodial solutions offer familiar inheritance mechanics. Some exchanges allow accounts to be held in the name of a trust, bypassing probate entirely. However, most major exchanges (including Coinbase) do not offer beneficiary designations: heirs must navigate probate, submit legal documentation, and wait months to gain access.

The best approach for many holders is a hybrid: keep the majority of holdings in a self-custodial multisig with inheritance provisions, while maintaining a smaller custodial position in a trust-held exchange account as a backstop.

Legal Considerations in the United States

Bitcoin is classified as property by the IRS (per Notice 2014-21), which means it is subject to estate tax, probate, and capital gains rules just like stocks or real estate. Understanding these rules is essential for any inheritance plan.

Estate Tax and the Step-Up in Basis

The One Big Beautiful Bill Act, signed July 4, 2025, permanently set the federal estate tax exemption at $15 million per person ($30 million for married couples), indexed for inflation. The estate tax rate remains 40% on amounts above the exemption. Bitcoin is included in the decedent's gross estate at fair market value on the date of death.

Critically, inherited Bitcoin receives a step-up in cost basis to its fair market value at the date of death. If someone bought 10 BTC at $500 each and dies when Bitcoin is at $100,000, the heir's cost basis becomes $100,000 per coin. Selling immediately triggers zero capital gains tax, permanently eliminating all unrealized gains. This makes inheritance significantly more tax-efficient than lifetime gifts, which carry the donor's original cost basis.

Digital Asset Access Laws

The Revised Uniform Fiduciary Access to Digital Assets Act (RUFADAA) has been adopted in nearly all 50 U.S. states. It gives executors and trustees legal authority to access a decedent's digital assets, following a three-tier priority system: online tool directions first, then estate planning documents, then terms-of-service defaults.

However, RUFADAA has a critical limitation for Bitcoin: it grants legal authority but cannot grant cryptographic access. A court order can compel an exchange to release an account, but it cannot recover a lost private key. This is why technical inheritance planning must accompany legal planning.

Practical Legal Checklist

• Create a "letter of intent" stored with your estate documents explaining what Bitcoin you hold, where keys and backups are located, and how to access them
• Name a technically capable executor or designate a Bitcoin-literate advisor who can assist the executor
• Consider holding Bitcoin in a revocable living trust to avoid probate and maintain privacy
• Document the cost basis and acquisition dates of all holdings for tax purposes
• Review state-specific RUFADAA provisions: some states require explicit opt-in to digital asset fiduciary access

Threshold Signatures and Future Inheritance Models

FROST threshold signatures (Flexible Round-Optimized Schnorr Threshold signatures) represent a significant advancement for inheritance-friendly key management. Unlike script-based multisig, FROST produces a single Schnorr signature indistinguishable from a regular single-key spend, regardless of how many parties participated in signing. This means better privacy, lower fees, and a smaller on-chain footprint.

BIP 445 (number assigned January 2026) formalizes the FROST signing protocol for Bitcoin. Companion work on ChillDKG provides distributed key generation without a trusted dealer. The Frostsnap hardware wallet, which shipped in 2025, is the first consumer device to implement FROST signing.

For inheritance, FROST enables key resharing: updating the set of authorized signers without moving funds on-chain. A holder could designate new beneficiaries, revoke compromised devices, or adjust the signing threshold without creating a new transaction. Combined with Taproot script paths, FROST could support a primary spending path (requiring the holder's participation) with a timelock fallback path where a threshold of family members can recover funds after a defined inactivity period.

Spark's Approach

Spark already uses threshold signatures at its core: every Spark balance is secured by a two-of-two arrangement between the user's key and the Spark operator collective (which itself uses FROST internally). This architecture naturally lends itself to inheritance-aware designs. A statechain operator could assist with recovery after a defined inactivity period, combining the benefits of self-custody during the holder's lifetime with operator-assisted succession planning. Because transfers on Spark do not require on-chain transactions, the periodic "refresh" that timelock-based approaches demand could happen at zero cost.

Building Your Inheritance Plan

The right setup depends on your holdings, your heirs' technical abilities, and how much ongoing maintenance you are willing to perform. Here is a practical framework:

For Small Holdings (under $50,000)

• Write your seed phrase on metal (fire and water resistant) and store it in a safe deposit box or home safe
• Create a sealed letter with clear instructions: what wallet software to download, how to enter the seed phrase, and how to sell or transfer funds
• Tell at least one trusted person that the letter exists and where to find it
• Consider a Shamir 2-of-3 split if you want to distribute trust among multiple parties

For Medium Holdings ($50,000 to $500,000)

• Use a collaborative custody multisig (2-of-3) with a provider like Casa, Unchained, or Onramp
• Set up the provider's inheritance or beneficiary designation feature
• Store your personal key backup in a separate location from your hardware wallet
• Include Bitcoin in your estate plan with a letter of intent for your executor

For Large Holdings (over $500,000)

• Use a 3-of-5 multisig with keys distributed across multiple geographic locations and institutions
• Implement timelock-based recovery via Liana or Nunchuk as an additional failsafe
• Work with a Bitcoin-literate estate attorney to create a revocable living trust
• Consider splitting across custodial and self-custodial setups for redundancy
• Document everything: wallet software versions, derivation paths, output descriptors, and recovery procedures

Critical reminder: Output descriptors and wallet configuration files are as important as private keys. A multisig or miniscript wallet cannot be reconstructed from keys alone: heirs need the descriptor to identify which addresses belong to the wallet and under what spending conditions.

The Security-Accessibility Tradeoff

Every inheritance strategy involves deliberately reducing your security posture to enable future access. The goal is to minimize that reduction while maximizing the probability that heirs can actually recover funds. A setup so complex that heirs cannot execute it is functionally equivalent to no plan at all.

Test your plan. Have a trusted person attempt a dry run using instructions you have documented. If they struggle with the process while you are alive and available to help, they will certainly struggle after your death. The best inheritance plan is one that is simple enough to execute under stress, with enough redundancy to survive the loss of any single component.

If you are exploring self-custodial wallet options that balance security with usability, Spark-powered wallets like General Bread provide a starting point for holding Bitcoin without the complexity of managing raw key material. For developers building inheritance-aware applications, the Spark SDK documentation covers threshold signature integration and wallet recovery flows. See also our deep dive on Bitcoin custody solutions compared for a broader look at the custody landscape.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.