Dead Man’s Switch

A recovery model can give the owner an immediate branch and other keys a branch available only after a delay. The same condition can arise during hospitalization, device loss or neglected maintenance. Technical access therefore cannot establish someone’s circumstances or identify a rightful heir. Before designing the system, specify the exact event it actually observes. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

The service deadmansswitch.net sends prepared emails after missed check-ins. This illustrates a different layer from Bitcoin Script. In your own design, separately assess account availability, delivery to the recipient and premature disclosure. A message may identify a backup location but does not prove that spending conditions are met. Sending a seed cannot be undone by changing a timer; a leak also requires addressing control of the coins. [Dead Man’s Switch — Service mechanism]

BIP 65 and OP_CHECKLOCKTIMEVERIFY check an absolute height or time threshold. BIP 112 and OP_CHECKSEQUENCEVERIFY, together with BIP 68, can enforce the age of a specific UTXO. Relative time-based locks use 512-second units and median-time-past, not a phone’s clock; BIP 113 describes the median timestamps of the previous 11 blocks. A block interval must not be presented as an exact calendar deadline. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 113 — Median time-past]

If a UTXO confirmed at H has a recovery branch delayed by 1000 blocks, that branch may become usable no earlier than H+1000, subject to other conditions. Logging into an app or receiving funds in another output does not reset its age. Renewing the relative delay requires spending this output and confirming a new one with the intended policy. Track each UTXO separately; a partial wallet refresh can leave older coins near the threshold. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]

In a model with a permanently available primary branch, expiry does not remove its authority. It adds a usable recovery branch; someone must still arrange signing and broadcasting. If both branches are valid, a confirmed transaction decides which spends the same UTXO, not an app’s “owner” or “heir” label. The design must therefore address late renewal and competing spends. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

nLockTime alone delays a particular transaction; it does not prove that an authorized key cannot sign another payment. A presigned plan must specify exact inputs, outputs, signing powers and fee funding. Spending its input in another confirmed transaction makes the original presignature unusable. Changing the document is therefore insufficient when updating the plan: check actual UTXOs and whether recipients have the new supporting material. [BIP 65 — OP_CHECKLOCKTIMEVERIFY]

These mechanisms imply a need for a margin before the nearest deadline, functioning alerts and fee funds. More frequent renewal costs transaction fees; longer delays extend the recovery branch’s unavailability. The recovering person needs the right keys, a policy description such as a descriptor and a usable tool. A backup locked behind the unavailable owner’s account or device creates a circular dependency. [Liana — Wallet architecture] [Liana — Signet testing guide]

Liana provides a Signet guide; a separate test setup can verify an early attempt, recovery-branch maturity and renewal of a specific output. Add scenarios for undelivered alerts, loss of the primary key and restoration from saved material. Check what old keys and old UTXOs still allow after changing the recipient. Distinguish signing, mempool acceptance and confirmation; success in one scenario does not prove that the whole plan is fault-free. [Liana — Signet testing guide] [BIP 112 — CHECKSEQUENCEVERIFY]