# Dead Man’s Switch Module

**URL:** <https://forum.safefoundation.org/t/dead-man-s-switch-module/6948>\
**Category:** Developer Discussion\
**Created:** [March 4, 2026, 4:50am UTC](https://forum.safefoundation.org/t/dead-man-s-switch-module/6948 "2026-03-04T04:50:34Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![blockful](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.safefoundation.org/blockful/32/4800_2.png) [@blockful](https://forum.safefoundation.org/u/blockful)\
**Post date:** [March 4, 2026, 4:50am UTC](https://forum.safefoundation.org/t/dead-man-s-switch-module/6948/1 "2026-03-04T04:50:34Z")

</div>

Hey everyone,

that’s been an idea we have in our backlog for a while and we never found an existing recommended implementation, so we figured we should do it. We built an open-source dead man’s switch module for Safe and wanted to share it with the community.

## The problem

A lot of crypto becomes permanently inaccessible every year. Lost keys, deceased owners, incapacitated signers. If a Safe owner is gone, the funds are effectively frozen. There’s no built-in way to pass control to someone else.

## The solution

A single Solidity contract that plugs into your Safe as both a **module** and a **guard**. You configure a delay (say, 90 days) and designate an heir. Every time the Safe owners sign a transaction, the inactivity timer resets automatically. If the timer runs out, the heir can call `triggerTakeover()` and become the sole owner of the Safe.

The heir can be any address. An EOA, another Safe, any multisig. So you could set up inheritance to a family multisig, a DAO, or whatever governance structure makes sense for you.

No oracles, no third parties, no off-chain components. Just a contract watching for signs of life.

```auto
  Safe owners sign transactions as usual
        (proof of life / check-in)
                    |
                    v
       +------------------------+
       | DeadManSwitch |
       | (module + guard) |
       +------------------------+
       | checkAfterExecution() |-----> resets inactivity timer
       +------------------------+
                    |
                    | delay passes with no activity
                    v
       +------------------------+
       | heir: triggerTakeover |
       +------------------------+
                    |
                    v
       Safe now has 1 owner: heir
       (threshold = 1, module paused)

```

## How the guard + module pattern works

The contract is enabled on the Safe as both a guard and a module:

- **As a guard** : `checkAfterExecution` fires after every `execTransaction` and resets the inactivity timer. Important: only direct Safe transactions (signed by owners) trigger the guard. Calls from other modules via `execTransactionFromModule` bypass the guard and do **not** count as activity.
- **As a module** : when the delay expires, the heir calls `triggerTakeover()`, which uses `execTransactionFromModule` to remove all existing owners, set the heir as the sole owner, and change the threshold to 1.
- **Manual check-in** : the Safe can call `ping()` to reset the timer without performing any other action. Useful if other modules are enabled whose activity won’t be detected by the guard.

## Design decisions

- **Single contract** : guard and module in one contract. No cross-contract calls, simpler trust model.
- **ERC-1167 minimal proxies** : each Safe gets its own clone (~45 bytes) instead of a full contract deployment. Cheap and deterministic via CREATE2.
- **Heir can be any address** : EOA, multisig, another Safe. The heir just needs to be able to call `triggerTakeover()`.
- **Heir-is-owner support** : the heir can already be one of the Safe’s co-owners. Takeover handles this correctly by removing the other owners instead of reverting.
- **Auto-pause** : the module disables itself permanently after takeover to prevent reuse.
- **Admin functions** : the Safe can update the heir, the delay, or pause the module at any time through a Safe transaction.

## Setup

After deploying a clone through the factory, only 2 Safe transactions are needed:

```auto
safe.enableModule(deadManSwitch)
safe.setGuard(deadManSwitch)

```

## Limitations

- `execTransactionFromModule` calls from other modules bypass the guard. If your Safe has other modules whose activity should count, the Safe should periodically call `ping()`.
- The module has powerful permissions. It can change owners. Treat it as a time-locked root key.
- No upgradeability. If a bug is found, owners must disable the module and deploy a new one.

## Status and next steps

This is **unaudited** and **not production-ready**. The code is tested (unit tests + fork tests against a mainnet Safe), MIT licensed, and open for contributions.

We’d love to see if the DAO could help cover an audit so we can take this to production. We’re also interested in understanding if there’s appetite to add this into the Safe app directly, or if we should build a separate interface for it.

**Repo** : [GitHub - blockful/deadman-switch-safe: Dead man's switch module for Safe. Transfers ownership to an heir after prolonged inactivity. · GitHub](https://github.com/blockful/deadman-switch-safe)

Looking forward to hear feedback from the community and Safe team.