Picture the moment. You've done everything right: hardware wallet, airgapped signing device, no exchange, no custodian, no paper trail. Your bitcoin is yours in the most absolute sense the protocol allows. Then a bus, a blood clot, a mountainside. The coins sit there, perfectly secured, perfectly inaccessible, while your family spends six months trying to remember the name of the wallet app you used.
The blockchain doesn't care about your next of kin.
This is not a hypothetical designed to frighten you into buying a product. Chainalysis has estimated that somewhere between three and four million bitcoin are likely lost forever, a meaningful fraction of that attributable to keyholder death. Self-custody done right is powerful. Self-custody done without a succession plan is an expensive gift to no one, and the distinction between those two outcomes is almost entirely a matter of planning.
Bitcoin's scripting language, combined with two well-understood primitives, offers a technical answer: timelocked multisig schemes that function as a dead-man's switch. The mechanism is elegant. The setup is not trivial. And the failure modes deserve more attention than they usually receive.
The Two Primitives That Make This Work
Bitcoin transactions can carry two kinds of constraints: who must sign, and when the transaction becomes valid. These map to multisig and timelocks respectively.
A multisig output requires M-of-N signatures before the coins can move. A 2-of-3 setup means any two of three designated keys can authorize a spend. The keys can live with different people, in different locations, on different hardware.
Timelocks come in two flavors. `OP_CHECKLOCKTIMEVERIFY` (CLTV) locks an output until a specific block height or Unix timestamp is reached. `OP_CHECKSEQUENCEVERIFY` (CSV) locks relative to when the funding transaction was confirmed, counting forward from the moment coins arrive rather than from an arbitrary calendar date. That distinction matters considerably for inheritance design, since a CSV-based scheme resets naturally each time the owner refreshes the output.
Combine them and you get a script that says: normally, spending requires these two keys together; but if a certain amount of time passes without activity, a different and broader set of keys can act alone.
A Concrete Dead-Man's Switch, Step by Step
Take a plausible scenario. Marcus holds a 2-of-3 multisig: his hardware wallet, a second device in a fireproof safe, and a key held by a trusted attorney. Under normal conditions, he needs two of those three to move funds. His heirs have no access.
Now add a timelocked inheritance branch to the same script, using Taproot's script-path spending, which keeps alternative branches hidden until they are actually needed. This second branch says: after 52,560 blocks (roughly one year, given Bitcoin's ten-minute block target), a 1-of-2 signature from either his daughter or the attorney is sufficient to spend.
The dead-man's switch logic is this. Marcus, while alive and well, refreshes the timelock before it expires. He sends the coins to a new output with a fresh 52,560-block clock. This is his regular proof-of-life action. If he stops, the clock runs out, and his daughter and the attorney gain the ability to claim the funds.
No oracle. No third-party service. No trusted server that needs to stay online for thirty years. The timelock enforcement is consensus-level Bitcoin protocol, as reliable as the chain itself. The scheme is, in this respect, more like a property deed recorded in a public register than like a password stored on someone else's server.
The Refresh Problem (and Why It's Not Optional)
Here is where most explanations quietly skip the hard part.
Refreshing a timelocked output costs a transaction fee and requires Marcus to actually do it. If he sets a one-year window and goes off-grid for fourteen months, his heirs may gain access while he is still very much alive and hiking in Patagonia. The window length is a genuine design tension, not a parameter to be set once and forgotten. Too short and a hospital stay or extended travel triggers the switch prematurely. Too long and you are asking heirs to wait years after a death before gaining any access.
A two-year window is probably the practical midpoint for most setups. That is a judgment, not a formula, and I will commit to it: schemes with windows shorter than eighteen months introduce more operational risk than they resolve, and any design that requires monthly on-chain transactions will eventually fail because life is not a cron job.
Some practitioners solve the attrition problem by layering the inheritance branch: a 1-of-2 threshold after two years, escalating to a 1-of-1 (the daughter alone, no attorney required) after three. The longer the death goes unaddressed, the lower the recovery threshold. This requires more script complexity but reduces the risk that an attorney goes incommunicado over a multi-decade horizon. It is the kind of redundancy a well-drafted will builds in through alternate executors, and it belongs here for the same reason.
One further point Marcus must document: the script itself. Bitcoin does not store spending conditions on-chain in readable form. To spend from a Taproot output using the inheritance path, the daughter needs the exact script, the full set of public keys, and her private key. If that documentation is lost, the timelock expires and the coins become unspendable by anyone. That outcome is indistinguishable from permanent loss.
What People Assume That Isn't True
The most common misunderstanding: that adding an heir's key to a multisig is sufficient for inheritance. It is not. A 2-of-3 arrangement where one key belongs to your daughter still requires her to locate and use a second key. If that second key is on your hardware wallet and you are dead, she is stuck. The multisig has not provided a path forward; it has provided the illusion of one.
The timelocked branch solves this by making the inheritance path easier than the normal spending path, but only after the waiting period. Before the clock expires, the coins are just as locked for heirs as they would be with no inheritance plan at all. That asymmetry is the point.
A subtler assumption concerns Taproot's script-path privacy. It does hide the inheritance branch until it is spent, which is genuinely useful. But once the daughter broadcasts the inheritance transaction, the full script becomes public. Anyone watching the chain can see the structure. This is not a flaw; it is a property worth understanding before designing around it.
And then there is the assumption about institutional longevity. People design schemes that depend on an attorney or co-keyholder being reachable in twenty years. Law firms dissolve. People move. A key held by an institution that closes is a key that is gone. This is why a 1-of-2 threshold (daughter or attorney) is structurally superior to any arrangement requiring both: the scheme survives the loss of one party, which is more than can be said for most estate plans drafted before the relevant technology existed.
Making It Durable
Ask yourself honestly: if you were incapacitated tomorrow, could the person you trust most find the script, the extended public keys, the derivation paths, and the refresh schedule without your help? If the answer requires any hesitation, the inheritance plan is incomplete regardless of how elegant the cryptography is.
Encrypted backups held by a solicitor, with written instructions that survive you, are not glamorous. Neither is scheduling an annual calendar reminder to refresh the timelock. This is the actual work of self-sovereign inheritance planning. The cryptography handles the enforcement. The documentation and the maintenance discipline are what make it real.
If the coins matter enough to hold in self-custody, they matter enough to build a path home for the people you will eventually leave behind. A timelock doesn't grieve. It just counts blocks.