Self-custody is the correct answer for crypto privacy. Your keys, your coins. Nobody else has access. Nobody can freeze or confiscate what they can't reach.
The problem is that the properties that make self-custody secure also make it permanent in the wrong direction. If you die with your seed phrase undiscovered, the funds are lost. Not locked. Not recoverable. Gone.
This creates a genuine problem that most privacy-focused crypto discussions avoid: how do you pass on access to funds you've deliberately hidden?
The baseline failure mode
Most people who die with cryptocurrency in self-custody leave no instructions. The surviving family knows the person held crypto — maybe. They find a hardware wallet, or a phone with a wallet app, or a piece of paper with words on it they don't recognize as a seed phrase. Without the seed phrase, correctly entered, the funds are inaccessible.
There's no equivalent of a safety deposit box where a bank officer can assist a verified heir. There's no password reset. There's no probate process that applies to a 24-word phrase held nowhere but the owner's memory.
Research on lost Bitcoin suggests a meaningful fraction of all Bitcoin in existence is permanently inaccessible for exactly this reason — not hacking, not exchanges collapsing, just people dying without transmitting access. Chainalysis estimated in 2020 that roughly 3.7 million BTC — about 20% of supply at the time — was already effectively lost. Death is a significant contributor.
The privacy tension
The obvious solution is to write down the seed phrase and give it to someone you trust. This immediately creates the privacy problem: the person you've given it to now has full, unconditional access to your funds. If your threat model includes anyone who might compel that person to disclose, you've just extended your attack surface.
Giving a seed phrase to an attorney, a family member, or a safety deposit box converts the custody from “only you” to “you and that party” — with whatever risks that party brings.
Technical approaches that address the tension
Shamir's Secret Sharing (SSS)
Shamir's Secret Sharing splits a secret into n shares such that any k shares (the threshold) can reconstruct the original, but any k-1 shares reveal mathematically nothing. The math is based on polynomial interpolation over a finite field.
Concretely: if you split your seed phrase into 5 shares with a threshold of 3, any 3 shareholders can recover the funds. Any 2 cannot — and crucially, 2 shares give an attacker zero information about the secret beyond its length.
Trezor's SLIP39 standard implements SSS natively on hardware wallets. You can generate SLIP39 shares directly from a Trezor Model T during wallet setup.
For software-based SSS, the ssss CLI tool handles arbitrary secrets:
Install on Debian/Ubuntu
sudo apt install ssss
Split a secret into 5 shares, requiring 3 to reconstruct
echo “your seed phrase here” | ssss-split -t 3 -n 5
Output: 5 share strings, any 3 reconstruct the original
Share 1: 1-a7f3c2...
Share 2: 2-9d14e8...
...
Reconstruct from any 3 shares
ssss-combine -t 3
Enter 3 of the above share strings when prompted
Each share goes to a different trustee. Distribute them across people who don't know each other — ideally in different jurisdictions. A subpoena to one trustee gets nothing useful.
For a more user-friendly implementation with BIP39 mnemonic support, horcrux wraps SSS in a simpler interface:
Install
go install github.com/jesseduffield/horcrux@latest
Split a seed phrase file into 3-of-5 shares
horcrux split seed.txt -t 3 -n 5
Combine shares to recover
horcrux combine share1.txt share3.txt share5.txt
Multisig
Multisig is architecturally different from SSS. With SSS, shares combine to reconstruct a single private key. With multisig, there is no single private key — the wallet is controlled by m of n independent keys, each of which can sign transactions. Funds move only when m signatures are present.
A 2-of-3 multisig setup:
Key 1: held by you (hardware wallet)
Key 2: held by trusted family member (hardware wallet)
Key 3: held by attorney (hardware wallet, in sealed instructions)
Transaction requires: any 2 of these 3 to sign
No single party can move funds unilaterally. If you die, keys 2 and 3 cooperate to access. If one trustee is compromised, the attacker still can't move funds without another key.
Bitcoin multisig setup using Bitcoin Core and bitcoin-cli:
Generate addresses on 3 separate wallets
Each participant runs this on their own device:
bitcoin-cli -rpcwallet=wallet1 getnewaddress “” legacy
Returns: their public key / address
Create a 2-of-3 multisig address from 3 pubkeys
bitcoin-cli createmultisig 2 '[“pubkey1”, “pubkey2”, “pubkey3”]'
Output includes:
– redeemScript (save this — needed to spend)
– address (fund this address)
For a more practical setup, Sparrow Wallet provides a GUI for multisig with hardware wallet support (Trezor, Coldcard, Ledger), including watch-only wallets that let a trustee monitor balances without spending keys.
For Monero, native multisig is supported but more complex. The monero-wallet-cli implements M-of-N multisig:
On each participant's machine, start wallet in multisig preparation
monero-wallet-cli —generate-new-wallet multisig_wallet
Exchange multisig info strings between participants
(wallet outputs a string to share with each other participant)
prepare_multisig
Each participant runs with the other's string:
makemultisig 2
Final exchange to finalize:
exchangemultisigkeys
The Monero multisig documentation covers the full ceremony in detail.
Time-locked transactions (dead man's switch)
A time-locked transaction is pre-signed but not broadcast. It sends funds to an heir's address after a future block height. While you're alive, you periodically cancel and re-create it with a new future date. If you stop — because you're dead or incapacitated — it eventually broadcasts automatically.
In Bitcoin, this uses OP_CHECKLOCKTIMEVERIFY (CLTV). A pre-signed transaction with nLockTime set to a future block height won't be accepted by the network until that height is reached.
Creating a time-locked transaction with bitcoin-cli:
Get current block height
bitcoin-cli getblockcount
e.g., 850000
Set locktime to ~6 months from now (~25920 blocks)
TARGET_BLOCK=875920
Create raw transaction with locktime
bitcoin-cli createrawtransaction \
'[{“txid”:””,“vout”:0}]' \
'{”“: 0.99}' \
$TARGET_BLOCK
Sign it (with your key)
bitcoin-cli signrawtransactionwithwallet
Store the signed hex — do NOT broadcast yet
Give the signed hex to your heir (or store it in your estate documents)
Every 5 months, create a new one with a later locktime
The heir holds a valid, signed transaction they can broadcast after the locktime passes. You stay alive → you periodically replace it with a new one → heir's copy expires. You die → heir broadcasts after the block height.
The maintenance burden is real: you need a calendar reminder every few months. Missing the window doesn't lose funds — you can always create a new one — but if you're incapacitated before creating the new one, the old one executes.
The documentation problem
Technical solutions to the custody problem still require documentation — instructions explaining what the heir has, how the scheme works, and what to do with it. Most people aren't technical enough to work through a multisig recovery without guidance.
A minimal inheritance document should cover:
What assets exist and approximately where
Bitcoin: multisig wallet, Sparrow Wallet software
XMR: hardware wallet + passphrase
What scheme was used
“2-of-3 multisig. Your key is on the Coldcard in the envelope.
The third key is held by [attorney name] at [firm].”
What software is needed
Download Sparrow Wallet from sparrowwallet.com
Import the wallet file at [location] using the watch-only descriptor
Step-by-step recovery instructions
Written for someone non-technical
Include the redeemScript or wallet descriptor
Who to contact
The other keyholder(s)
A technical contact who can assist
An encrypted portfolio tracker that stores asset locations, addresses, and instructions locally — accessible to a designated party under specific conditions — addresses part of this. The Privacy Portfolio stores everything locally with AES-256-GCM encryption; no server-side copies, no account. Instructions stored there could be part of a documented inheritance plan.
Choosing the right approach
Approach Privacy Complexity Requires trustees Maintenance
SSS (Shamir) High — shares reveal nothing individually Medium Yes (n parties) Low
Multisig High — no single point of compromise Medium-High Yes (keyholders) Low
Time-locked tx High — heir needs no key until triggered Medium Optional High (periodic refresh)
Seed phrase to attorney Low — full access given to one party Low Yes (1 party) None
Written and hidden Low — discovery risk Low No None
For most self-custody holders, a 2-of-3 multisig or a 3-of-5 SSS split covers the inheritance problem without meaningfully expanding the attack surface — provided the trustees are chosen thoughtfully and the documentation is clear.
The hard honest answer
There's no elegant solution that simultaneously maintains the full privacy properties of self-custody and guarantees inheritance access. Every approach that solves the inheritance problem introduces some version of a trusted party or documented instruction set.
The question is how to minimize that exposure while ensuring access is genuinely possible. Shamir's with a thoughtful quorum of trustees — people who don't know each other, in different jurisdictions — comes closest. But it requires planning, documentation, and technical setup that most self-custody holders haven't done.
The alternative is accepting that your funds will be lost on your death. For some users and some amounts, that's a deliberate choice. For most, it isn't — it's just an unconsidered default.
themselves, are the unsexy but necessary component.
An encrypted portfolio tracker that stores asset locations, addresses, and instructions locally — accessible to a designated party under specific conditions — addresses part of this. The Privacy Portfolio stores everything locally with AES-256-GCM encryption; no server-side copies, no account. Instructions stored there could be part of a documented inheritance plan.
Choosing the right approach
Approach Privacy Complexity Requires trustees Maintenance
SSS (Shamir) High — shares reveal nothing individually Medium Yes (n parties) Low
Multisig High — no single point of compromise Medium-High Yes (keyholders) Low
Time-locked tx High — heir needs no key until triggered Medium Optional High (periodic refresh)
Seed phrase to attorney Low — full access given to one party Low Yes (1 party) None
Written and hidden Low — discovery risk Low No None
For most self-custody holders, a 2-of-3 multisig or a 3-of-5 SSS split covers the inheritance problem without meaningfully expanding the attack surface — provided the trustees are chosen thoughtfully and the documentation is clear.
The hard honest answer
There's no elegant solution that simultaneously maintains the full privacy properties of self-custody and guarantees inheritance access. Every approach that solves the inheritance problem introduces some version of a trusted party or documented instruction set.
The question is how to minimize that exposure while ensuring access is genuinely possible. Shamir's with a thoughtful quorum of trustees — people who don't know each other, in different jurisdictions — comes closest. But it requires planning, documentation, and technical setup that most self-custody holders haven't done.
The alternative is accepting that your funds will be lost on your death. For some users and some amounts, that's a deliberate choice. For most, it isn't — it's just an unconsidered default.
Top comments (0)