What is a dead man's switch for crypto?
A mechanism as old as locomotives, rebuilt in smart-contract form: as long as you keep signaling "I'm here," nothing happens. When the signals stop, the person you chose can claim your crypto. Here's exactly how it works — and the hard questions to ask anyone selling you one.
Direct answer: a crypto dead man's switch is a time-based transfer mechanism. The owner periodically proves activity; after a configured silence period, a named beneficiary may start a claim; a separate challenge window lets the owner cancel a false trigger before settlement.
Review status: technically reviewed on 27 September 2026 against the source of the Will & Key version 2 contract, which was written after the preliminary audit of version 1 and deployed on 28 September 2026. No independent smart-contract auditor or lawyer has approved this guide.
Key takeaways
- The mechanism detects silence, not death.
- Inactivity and challenge periods solve different problems and should not be merged.
- A beneficiary address is a security-critical configuration item.
- Admin powers, upgradeability, fee rules and settlement liveness must be verified in code.
The train driver's handle
Early locomotives had a simple safety problem: what if the driver dies at the controls? The answer was a handle the driver had to keep holding. Grip it and the train runs; let go and the brakes apply. The system doesn't need to know the driver is dead — absence of the signal is the signal.
That inversion is what makes the idea perfect for crypto inheritance, because it solves the problem no blockchain can solve directly: a smart contract cannot check a death certificate. It can, however, notice that an address which used to send a heartbeat transaction every month has gone silent for a year.
The mechanism, step by step
- Lock. You put funds in a vault contract and name your heir's wallet address. You choose an inactivity period — how long the silence must last.
- Check in. Any time before the period elapses, you send a cheap transaction that resets the timer. Checking in monthly on a 90-day timer means three missed months before anything can happen.
- Claim. If the timer truly runs out, your heir — and only the wallet you named — can initiate a claim, naming the address the funds should be paid to. In Will & Key the heir can correct that address only by cancelling the claim and filing a new one, and safely only before the claim becomes finalizable.
- Challenge window. The claim doesn't settle instantly. A veto period runs (in Will & Key's case, minimum seven days; we suggest 14 or more) during which you can cancel the claim. This is the safeguard against the hospital scenario: being unreachable is not being dead. In Will & Key, before your horizon, the cancelling actions are Veto claim, changing the heir, changing the check-in period, installing or disarming a check-in chain (advanced), extending the horizon or any withdrawal. A check-in or a top-up does not cancel a claim, and ordinary wallet activity does not count; at or after the horizon only extending the horizon or withdrawing everything works. The window only protects you if you notice it: Will & Key sends no alerts of any kind, so nobody will notify you if a claim is filed.
- Settle. Once the window has run, anyone can finalize the transfer. Finalizing is a transaction, not an automatic event: until it is mined, your key can still cancel, so an heir should finalize promptly. After finalization, nobody can reverse it or redirect the funds — including the people who built the contract.
Worked timeline: 90 days of inactivity plus 30 days to challenge
| Day | Event | What the contract permits |
|---|---|---|
| 0 | Owner checks in | Inactivity deadline becomes day 90 |
| 90 | Deadline passes with no owner activity | The named beneficiary becomes eligible to initiate a claim |
| 91 | Beneficiary initiates | A 30-day challenge window starts; funds do not transfer yet |
| 100 | Owner presses Veto claim | The pending claim is cancelled and the clock restarts (a plain check-in would not cancel it) |
| 121 | If no valid veto occurred | Anyone can finalize; until someone does, the owner's key can still cancel |
This example is explanatory, not a recommended timer. Hospitalization, travel, hardware loss, network congestion and the beneficiary's own availability all affect a sensible margin.
What it protects against — and what it can't
Honest implementations are explicit about both columns:
| Protects against | Cannot protect against |
|---|---|
| Death or permanent incapacity (your heir can claim the funds) | A stolen owner key (a thief with your key is indistinguishable from you) |
| Your own lost key (stop checking in, heir inherits — a built-in recovery path) | A lost heir key after you're gone (keep the heir's address current while alive) |
| Custodian failure (there is no custodian) | Forgetting to check in and never looking during the challenge window (Will & Key sends no warnings of any kind) |
| Seed-phrase leakage via paperwork (no secret is ever shared — see why not a will) | Chain-level catastrophe (any on-chain asset shares its chain's fate) |
The questions to ask any dead man's switch
- "Can the operator touch my funds?" The only acceptable answer is a provable no, and ask which assets it covers. In Will & Key's contract, vault balances are arithmetically outside the admin's reach, and that's verifiable in the source, not a policy promise. It holds because a vault can hold only ETH or one of four listed tokens (USDC, WETH, cbBTC and EURC), chosen because each lives at one address and never changes a balance on its own; the list is fixed in the contract and nobody can add to it. A token's issuer can still freeze its own token: Circle can pause or blocklist USDC and EURC, and Coinbase cbBTC.
- "What happens if the company disappears?" The contract must keep working with the website gone. Claims must be finalizable by anyone, not by the operator's server.
- "Can the fee change under me?" Look for a hard cap in the bytecode, a creation-time ceiling and a notice period for raises. Will & Key's current global settlement fee is 0.5% and the bytecode cap is 1%. Each vault records the rate in force when it was created as its ceiling. A cut applies at once, but a raise takes effect only 30 days after it is announced on chain, so it cannot be slipped in front of your transaction. Starting a claim locks the lower of the vault's ceiling and the rate then in force, and a later cut helps the heir only if it is still in force when the claim settles.
- "Is it upgradeable?" An upgradeable inheritance contract means someone can change the rules after you're gone. Non-upgradeable is the right answer even though it makes the developer's life harder.
- "Who controls administration?" Identify the current owner address and every privileged function. Will & Key's administrator is a single Ledger hardware-wallet key, not a multisig, and it also receives the fees. Its functions are pausing new vault creation, cutting the global fee or announcing a raise that takes effect 30 days later (never above the 1% cap), changing the fee recipient, sweeping surplus in ETH or a listed token, and transferring administration. It cannot add a token. The address is on the security page. A single key is a disclosed risk even though the administrator cannot withdraw vault balances; moving to a multisig is recommended.
- "Has it been audited?" Will & Key's contract on Base is version 2, live since 28 September 2026. It was written in response to a preliminary audit of version 1 by AI auditing agents, performed at the project's request and not independent, and it has since been reviewed only by AI agents of the same kind that wrote it. It has no completed independent third-party audit and no completed full minimum-duration Base Sepolia lifecycle test. Do not treat internal evidence as an external assurance.
Three timers, three different promises
| Setting | Purpose | Too short | Too long |
|---|---|---|---|
| Inactivity period | Defines when a beneficiary may begin | Ordinary missed check-ins can trigger claims | Recovery after genuine incapacity is delayed |
| Challenge window | Gives the owner time to cancel a false trigger (we suggest 14 days or more) | Hospitalization, access problems or a slow network may outlast it | A legitimate beneficiary waits longer after claiming |
| Absolute horizon | Bounds how far routine check-ins can defer the final inheritance path | Owner may need deliberate extension sooner | The beneficiary's long-stop comes later |
The trade you are making
A dead man's switch converts the inheritance problem into a liveness problem. You no longer need to trust an institution, share a secret, or teach your family cryptography. In exchange, you take on one recurring obligation: check in, on a schedule you chose, for the rest of your life. Whether that trade is good depends entirely on whether checking in is easy and whether you remember to — which is why the timer minimums are measured in weeks, not hours. Will & Key sends no alerts of any kind, so put your check-in dates in your own calendar.
Verify the mechanism before using the interface. Read the deployed address, bytecode hashes, administrator powers, fee boundaries, test status and known limitations.
Review security evidenceDeciding whether this mechanism fits your family? Use the printable worksheet to compare it with exchange custody, multi-share backups and multisig, then record a rehearsal.
Download checklist (PDF)Further reading: what happens to your crypto when you die · a complete inheritance plan in one weekend.
Primary sources and verification
- Ethereum.org - smart contracts, real-world data limits and multisig
- Ethereum.org - externally owned and contract accounts
- Base documentation - mainnet and Base Sepolia network details
- Base documentation - verifying contracts and transactions with explorers
- OpenZeppelin - ownership and access-control concepts
- BaseScan - deployed Will & Key InheritanceVault address (version 2)
- Will & Key - transaction-by-transaction mechanism
- Will & Key - bytecode, admin powers, tests and audit status