A timelock is an on-chain rule that blocks a transaction or contract call from executing until a defined block height, block count, or timestamp is reached. The wallet pattern called a dead man's switch wraps that rule around a routine "proof of life" reset, so funds release to a successor only if the owner fails to refresh in time.
The mechanism sits beneath several familiar setups. Bitcoin inheritance vaults from Casa and Liana rely on it; Compound and Aave use timelocks to delay governance executions; and the wallet category labeled "dead man's switch" stacks all three ideas (lock, reset, successor route) into a single script or contract that runs without a notary or executor.
What is a timelock and how does a dead man's switch use it?
A timelock is a consensus rule that blocks a spend, contract call, or governance action from running until a specified time condition is satisfied. The condition can be an absolute future block height or timestamp, or a relative duration counted from when the locked output was created. The dead-man's-switch pattern uses that rule as an inheritance trigger.
The pattern works in three steps. The owner signs a transaction or sets up a contract path that releases funds to a successor address after a future date. The owner periodically "resets" that date by moving the coins to a fresh output (or pinging the contract) before the lock expires. If the reset stops happening, the successor path opens automatically; if it keeps happening, the successor path never matures, and the funds stay under the original owner's control. This is distinct from Shamir's Secret Sharing, which splits the key itself among trustees rather than gating execution on time.
A simple example helps. A holder signs a Bitcoin transaction in 2026 that pays the holder's heir, with a lock that prevents the network from accepting it before January 2028. The heir keeps a copy of the signed transaction. If the holder is still active, the holder re-signs an updated version every six months that pushes the lock forward; if the holder dies, the heir broadcasts the most recent version on or after the unlock date. No probate, no notary, no exchange involvement.
How do Bitcoin script timelocks work (CLTV and CSV)?
Bitcoin script supports two opcode-level timelocks: OP_CHECKLOCKTIMEVERIFY (CLTV) enforces absolute locks against a future block height or Unix timestamp, and OP_CHECKSEQUENCEVERIFY (CSV) enforces relative locks counted from when the locked output was confirmed. Both became consensus-enforced in 2015 and 2016, sitting on top of the original transaction-level nLockTime field from Bitcoin's 2009 design.
CLTV was introduced in BIP-65 and activated on Bitcoin mainnet at block 388381 in December 2015 as a soft fork (source: BIP-65 specification; the activation height is recorded in BIP-90's buried-deployment list at Bitcoin Wiki BIP-0090). The opcode checks the spending transaction's nLockTime field against a constant baked into the script, and fails the script if the lock has not yet been reached. An heir-friendly inheritance script can encode "owner key can spend any time; heir key can spend after January 1, 2028" in a few lines of script.
CSV was introduced in BIP-112 and deployed alongside BIP-68 and BIP-113 in 2016, with the BIP-9 versionbits signaling window starting 1 May 2016 UTC (source: BIP-112 specification). CSV checks the spending transaction's sequence field, which BIP-68 redefined to express relative locks. The maximum relative lock is 65,535 blocks (about 15 months) or 65,535 multiplied by 512 seconds (about 13 months) (source: Unchained on miniscript timelock tradeoffs).
The two opcodes serve different patterns. CLTV is the natural fit for inheritance ("after this date, the heir can spend"). CSV is the natural fit for vaults and decaying multisig ("after these coins have sat for N months, an alternate quorum can spend"). Both live inside Bitcoin script and require a wallet that produces non-default scripts. Hardware signers like Coldcard and Trezor can sign transactions that include nLockTime and sequence values, with the lock itself living in the transaction rather than in the device firmware.
Miniscript, a structured language that compiles to Bitcoin script, makes these patterns readable. The miniscript expression or_d(pk(A),and_v(v:pk(B),after(50000))) reads as "either key A signs, or key B signs after 50,000 blocks have passed since this output was confirmed." Wallets like Liana from Wizardsardine generate exactly these scripts for users who want recovery-by-delay without writing script by hand (source: Liana announcement on wizardsardine.com).
How do EVM timelock contracts work (TimelockController and governance)?
EVM timelocks live in smart contracts rather than transaction-level scripts. The standard reference is OpenZeppelin's TimelockController, a contract that queues an operation, waits for a configured delay, and then permits execution. It is widely used for DAO governance, for smart-contract wallet admin functions, and for any administrative change that benefits from a review window.
TimelockController in OpenZeppelin Contracts v5.x exposes four roles: a proposer who queues operations, an executor who runs them after the delay elapses, a canceller who can drop queued operations, and an admin who manages role assignment (source: OpenZeppelin Governance docs). The contract itself typically holds the admin role, which means changes to the delay or to role membership have to go through the same time-gated process they govern. Setting the executor role to the zero address allows anyone to execute a queued operation once it matures, which keeps the system from depending on a specific keeper.
Compound's Governor Bravo uses a Timelock contract with a hard-coded minimum delay of two days; proposals that pass voting enter the timelock and become executable only after that window (source: Compound v2 Governance docs). Aave operates two executors: a short executor with a 1-day delay for most protocol parameters and a long executor with a 7-day delay for changes to core governance permissions and the AAVE token (source: Aave Governance Proposals reference). The longer window matches the higher consequence of the change.
The dead-man's-switch pattern on EVM is conceptually similar to the Bitcoin pattern but expressed as a contract method rather than a script template. A user deploys a contract holding their funds with a "checkIn" method that resets a counter, and a "claim" method that lets a successor withdraw after the counter exceeds a configured threshold. Sarcophagus is an Ethereum implementation that bundles this idea with encrypted off-chain storage on Arweave, releasing decryption keys to a designated recipient if the user fails to check in within the configured window.
EVM blocks are produced every 12 seconds post-Merge, which makes wall-clock targets in seconds directly translatable to block counts. A 30-day check-in window resolves to about 216,000 blocks. Compound's 2-day governance delay resolves to about 14,400 blocks.
What inheritance and recovery patterns rely on timelocks?
The four common patterns are pre-signed inheritance transactions, decaying multisig (a strong quorum that drops to a weaker one after a delay), expanding multisig (a small quorum that gains a recovery key after a delay), and contract dead-man's switches with off-chain payloads. Each balances current security against future recovery without a third party.
Pre-signed inheritance is the simplest Bitcoin pattern. The owner signs a CLTV-locked transaction in advance and gives the signed bytes to the heir. The heir cannot broadcast it before the lock date, and the owner can replace it any time before then by spending the input into a new output. Coldcard and other hardware signers produce these transactions via PSBT workflows; the hardware-wallet setup sits at the foundation of the pattern.
Decaying multisig uses CSV to relax the quorum after a delay. A 3-of-3 vault that decays to 2-of-3 after 90 days lets two of three keyholders recover funds if the third key is lost, without weakening the everyday spending policy. Expanding multisig flips the direction: a 2-of-2 that expands to 2-of-3 brings a recovery key into scope only after stagnation, keeping the recovery key offline until needed. The miniscript-timelock literature treats these as the canonical recovery archetypes.
Named products in 2026 take different paths. Casa uses on-chain Bitcoin timelocks with a 6-month verification window during which the original owner can reject any access request from a designated Recipient, so the timelock is paired with an active veto rather than a pure unlock. Unchained Capital's inheritance protocol, by contrast, does not use a Bitcoin timelock at all; it uses a 2-of-3 multisig where Unchained holds one key and signs alongside the executor when the time comes. Liana, from Wizardsardine, generates miniscript timelock scripts for self-custodied recovery without involving the wallet vendor in the eventual spend.
Looking ahead, OP_VAULT in BIP-345 (proposed by James O'Beirne, with a draft implementation on Bitcoin Inquisition) would let users build native Bitcoin vaults with a long timelock between any withdrawal request and the actual spend, and an immediate-recovery path back to deep cold storage during the lock window. As of mid-2026 the proposal is not activated on Bitcoin mainnet.
How does a dead-man's-switch wallet actually trigger?
A dead-man's-switch wallet triggers when a configured check-in window expires without a fresh proof of life. On Bitcoin, the trigger is maturation of a timelock on a pre-signed transaction or vault output. On EVM, it is a contract counter crossing a threshold and unlocking a claim function. In both cases, the trigger is mechanical, not judicial.
Three implementation choices matter. The first is the proof-of-life action itself. A Bitcoin script-based switch typically requires the owner to broadcast a "refresh" transaction that moves the locked coins to a new output, restarting the CSV clock; an EVM contract switch requires a transaction calling a checkIn function. The action has to be cheap and routine enough to perform without fail, because the consequence of forgetting is the successor path opening.
The second choice is the successor route. The script or contract has to embed where the funds go after the lock matures. A single successor address is the simplest. A successor multisig (the heir's Bitcoin multisig setup being the typical pattern) adds redundancy. A successor contract can route funds conditionally based on additional logic.
The third choice is how the encrypted payload is handled when off-chain instructions matter. A pure on-chain switch like a Bitcoin CLTV transaction transfers UTXOs only; the heir still has to know which keys control the destination. Hybrid systems like Sarcophagus on Ethereum encrypt off-chain instructions (seed phrases, wallet locations, written notes) and use the timelock to release the decryption key to the heir. The "archaeologists" who hold the encrypted shares are incentivized to publish them at the right time, with slashing if they leak early or fail to release on time.
Heirs in any of these patterns benefit from rehearsing the broadcast or claim flow before they need it. The hardest part is rarely the cryptography; it is locating the wallet files, identifying which transaction is the live one, and reaching a node that will accept the broadcast. Documentation written for a non-technical heir (printed instructions, named tools, a labeled USB drive) closes most of the operational gap.
What are the risks and tradeoffs of time-based recovery?
The four practical risks are accidental triggering (forgetting to check in), legal-survivor coordination (heirs unaware of the wallet or unable to act), key custody during the lock period, and hardcoded contract risk in switches with no upgrade path. Each is manageable with discipline, but none disappear by choosing a timelock over an alternative recovery model.
Accidental triggering is the dominant operational risk. An owner who travels off-grid, loses a phone, or simply forgets to refresh the timelock can wake up to find the heir's claim window open. Users with CSV-based vaults face refresh pressure roughly every 15 months at the maximum CSV bound, and a 30-day window invites monthly fee-rate decisions that may interact badly with a congested mempool. The mitigation is usually a longer window paired with a calendar reminder and a wallet client that surfaces the next refresh date.
Legal-survivor coordination is the social risk. A trustless inheritance script removes the need for a court, but it does not remove the need for the heir to know the wallet exists, to have the signed transaction or the contract address, and to be able to use a block explorer or wallet client at the right time. A timelock-based switch that nobody knows about effectively burns the coins.
Key custody during the lock period is the cold-storage risk. The successor key has to be available when the lock matures, which often means a backup that is itself protected by air-gapped signing or distributed among trustees. The lock alone does not solve the question of where the successor key lives in the meantime.
From Blofin's operational perspective, the time-based controls a centralized exchange typically implements (withdrawal cooldowns after a security-event trigger, queued governance executions, scheduled cold-storage drains) are platform-side timelocks that protect users without requiring them to set anything up on-chain. The retail user still has to handle on-chain inheritance and dead-man's-switch patterns off-platform, because exchange account models depend on KYC and operational recovery rather than a Bitcoin script or EVM contract that triggers on a calendar.
When does a timelock beat alternatives like Shamir or MPC?
A timelock beats alternatives when the recovery condition genuinely is the passage of time, not the assembly of trustees. If the question is "what happens if I disappear for two years," a timelock encodes that directly. If the question is "how do I split my key so no single person can spend," Shamir or MPC key custody fits better.
Three comparison axes help. The first is the trust model. A timelock trusts the chain to enforce time, the heir to act, and the owner to refresh. Shamir trusts a quorum of trustees to surface their shares at the right moment. MPC trusts a coordinator and a set of signers to remain online and honest. None is universally safer; each fails in a different direction.
The second axis is reversibility. A timelock is fully reversible until the lock matures: the owner can move the coins, replace the signed transaction, or cancel the contract path at any time before the trigger fires. A Shamir setup can be reconstituted by collecting the shares (which exposes the key) and re-splitting it. An MPC setup can re-key by running a new distributed key generation. Reversibility matters for owners whose successor list or coin location may change.
The third axis is operational load. A timelock that has to be refreshed monthly is more demanding than a Shamir backup that sits in trustees' safes. A timelock with a multi-year lock is the least operationally demanding, but it widens the window for the world (and the successor's circumstances) to change. The right choice depends on how much routine action the owner can sustain.
The common-sense pattern in 2026 is to combine these mechanisms rather than choose between them. A self-custody setup for the everyday balance, a multisig with Shamir-backed secondary keys for medium-term custody, and a CSV-locked recovery path for inheritance cover three different threat models with three different tools. The crypto wallet glossary defines the terms that show up in each.
Decision matrix: when each mechanism fits. Use-case rows × holding-size columns. Each cell is the mechanism that fits the intersection; the legend below maps abbreviations to setups.
Use case ↓ / Holding size → | Small (<$10k) | Medium ($10k–$250k) | Large ($250k–$5M) | Institutional (>$5M) |
|---|---|---|---|---|
Self-spending only (no recovery) | HW + seed backup | HW + seed backup + steel | 2-of-3 multisig on HW | Multisig + qualified custodian split |
Sole-owner inheritance (one heir) | DMS (key escrow service) | CLTV/CSV pre-signed tx + heir guide | Shamir 2-of-3 + CSV fallback | Trust company + multisig + governance timelock |
Multi-heir inheritance | DMS to heir-shared escrow | Shamir 2-of-3 across heirs | Shamir 3-of-5 + CSV fallback per branch | Bonded trustee structure + multisig + timelock |
Disappearance protection (1-3 yr) | CSV-locked recovery output | CSV-locked recovery + DMS heartbeat | Multisig with CSV recovery branch | TimelockController governance + multisig signers |
Lost-device / lost-seed recovery | Cloud-encrypted seed (low value only) | Shamir 2-of-3 across personal locations | Shamir 3-of-5 + multisig spare key | MPC re-key procedure + custodian backstop |
Active treasury (frequent spend) | Not applicable (use HW) | HW + watch-only mobile | Multisig + spending policy hot-key | Multisig + role-based MPC + governance timelock |
Legend. HW = hardware wallet. DMS = dead-man's-switch service (e.g., heir-targeted reveal after missed heartbeat). CLTV = OP_CHECKLOCKTIMEVERIFY (Bitcoin absolute timelock). CSV = OP_CHECKSEQUENCEVERIFY (Bitcoin relative timelock). Shamir = SLIP-39 share split. MPC = multi-party computation key custody. TimelockController = OpenZeppelin EVM contract with enforced delay between proposal and execution.
The matrix is opinionated rather than prescriptive: the right mechanism for a given owner also depends on the heir's technical fluency, the jurisdiction's probate rules, and the owner's appetite for periodic refresh work. Read it as the default starting point a setup conversation can move off, not the final answer.
Frequently asked questions
Does a Bitcoin transaction with a timelock sit in the mempool until it unlocks?
No. Bitcoin nodes reject any transaction whose nLockTime or CSV-imposed maturity has not yet been reached, which means a pre-signed inheritance transaction cannot enter the mempool until the lock expires. The heir holds the signed bytes off-chain, then broadcasts them on or after the unlock date. Until then, no node will accept the transaction, and the funds remain spendable by the owner through any alternate script path.
What happens if I lose the key during the timelock period?
The timelock alone does not give you a recovery path; it just delays an already-authorized successor's claim. If the owner key is lost and no script path lets the successor spend before the lock expires, the funds become unreachable until the lock matures and the successor key acts. Designs that anticipate this (such as decaying multisig that drops to 2-of-3 after a CSV delay) build a recovery quorum into the same script, so the loss of one key does not have to wait for the full timelock to clear.
Can I cancel a dead man's switch after it has been set up?
Yes, in almost every pattern, as long as the lock has not yet matured. The owner can broadcast a transaction that spends the locked output through the owner's still-valid script path, which invalidates the pre-signed successor transaction. On EVM, the owner can withdraw funds from a switch contract or update the configuration through a method that the contract exposes. Once the lock matures and the successor path becomes valid, cancellation is no longer possible from the owner side.
Do timelocks work the same way on Bitcoin and Ethereum?
No. Bitcoin enforces timelocks through transaction-level fields (nLockTime, sequence) and script opcodes (CLTV, CSV) that the network checks against block height or timestamp at validation. Ethereum enforces timelocks through smart-contract logic, with the contract reading block.timestamp or block.number and gating function calls based on the result. The user-facing patterns map onto each other (inheritance, vaults, governance delays), but the implementation primitives are different and the wallet tooling has to match the chain.
Is OP_VAULT (BIP-345) already activated on Bitcoin?
No. As of mid-2026, BIP-345 is a proposed soft fork in active discussion with a draft implementation on Bitcoin Inquisition (a testing sidechain for covenant proposals). It has not been activated on Bitcoin mainnet. Inheritance and vault patterns today rely on CLTV, CSV, and miniscript composition; if OP_VAULT activates in a future soft fork, it would enable native vault constructions that today require either off-chain coordination or covenant emulation through scripts.
Researched and written by the Blofin Academy editorial team with AI-assisted drafting. Primary sources include the BIP-65 OP_CHECKLOCKTIMEVERIFY specification, the BIP-112 OP_CHECKSEQUENCEVERIFY specification, the Bitcoin Wiki BIP-90 buried-deployment record for the block 388381 CLTV activation, OpenZeppelin's TimelockController documentation in Contracts v5.x, Compound's Governor Bravo governance documentation, Aave's governance process documentation for the 1-day and 7-day executors, Unchained Capital's analysis of miniscript timelock tradeoffs, and the Wizardsardine announcement of the Liana recovery wallet. All facts independently verified against cited documentation current as of May 2026.
This article is for informational purposes only and does not constitute financial advice, investment guidance, or a recommendation to buy, sell, or hold any digital asset. Cryptocurrency markets involve significant risk and you should conduct your own research and consult qualified professionals before making investment decisions. Blofin Academy content reflects the state of public information at time of publication; protocol parameters, fees, and ecosystem data change frequently.