Most "Digital Inheritance" services are architecturally flawed. They operate on a Custodial Model:

You upload your private keys/passwords to their database.

They promise (pinky swear!) they are encrypted.

When you die, they send the data to your wife.

As a developer, this is a nightmare. If I upload my seed phrase to your server, I am trusting your sysadmin, your database config, and your immunity to a $5 wrench attack. I don’t trust any of those things.

So I tried to solve the Dead Man’s Switch Paradox: How can a system deliver a secret it doesn’t know? How can I ensure the data is recoverable only after I disappear, but mathematically impossible to access before?

Here is how I architected Deadhand Protocol (Open Source) to solve this using Python.

The Logic: "Fail-Deadly" vs "Fail-Safe" Standard software is "Fail-Safe" (if it breaks, it locks down). A Dead Man’s Switch must be "Fail-Deadly". It does nothing until a negative condition is met (Silence).

The core loop is simple async logic, but the Payload Delivery is where the magic happens.

The Cryptography: Client-Side AES + The "Trigger" Key I refused to store raw data. Instead, I implemented a split-key architecture.

The Client-Side Encryption Before the data leaves the user’s browser/terminal, we encrypt it using AES-GCM. The key to decrypt this payload is NOT sent to the server yet. The server receives an encrypted blob. It has no idea if it holds a Bitcoin wallet or a recipe for lasagna. 1.

The Trigger Mechanism The decryption key (or a shard of it) is the "Trigger." The user stores this key locally. The Beneficiary (the person receiving the data) receives a "Dormant Link." 1.

The Event Loop The backend (FastAPI) runs a background worker (Celery/Redis) checking the last_heartbeat timestamp.

Python

Pseudo-code of the Reaper Logic

async def reaper_job(): threshold = now() - timedelta(days=30) dead_users = db.query(User).filter(User.last_heartbeat < threshold).all()

for user in dead_users:
# The user failed to check in.
# We verify if the 'Grace Period' has passed.
execute_protocol(user)

The Hard Part: Avoiding the "Honeypot" If I store the "Decryption Key" on the database waiting to be emailed, my database is a honeypot. Hackers will target it to steal the keys of 1,000 users.

The Solution: Shamir’s Secret Sharing (Concept) In the next version (v2), we are implementing SSS to split the key into 3 parts:

Shard A: Held by the User (destroyed upon death).

Shard B: Held by the Server (The "Deadhand").

Shard C: Held by the Beneficiary.

To reconstruct the secret, you need 2 of 3.

While alive: User has A. Server has B. Beneficiary has C. (Server + Beneficiary cannot conspire because they don’t know each other).

Upon Death: Server sends Shard B to Beneficiary. Beneficiary combines B + C.

Result: The Server never had enough shards to decrypt the data. The admin (me) cannot steal your coins even if I wanted to.

Why I Open Sourced It Security tools require Zero Trust. You shouldn’t trust my backend. You should trust the math. By making the repo public, anyone can verify:

The Heartbeat logic is robust.

The encryption is standard (no "roll your own crypto").

There are no backdoors.

If you are a dev, you have a responsibility to handle your "Bus Factor." Don’t rely on Google’s "Inactive Account Manager" (which can be disabled by policy changes). Rely on code you can audit.

Check the implementation here: 👉 github.com/pyoneerC/deadhand

(Pull Requests for the SSS implementation are welcome. Let’s harden this thing.)