What is Bequest?

Bequest is a way to pass on your most important files. You seal things away — documents, passwords, recovery phrases, letters, photos — and choose who should receive them after you are gone. While you're around, they stay locked and only you can reach them. If you're ever not, they are released to the people you named.

This answers a problem that otherwise has no good solution. The things the people close to you would need if you died or were incapacitated — account logins, where the will is, the keys to your savings — tend to be either written down somewhere insecure or locked away so well that they're lost with you. Handing them over now means trusting someone with access today; keeping them truly safe means no one can reach them when it matters. Bequest removes that trade-off.

It works by checking in. Every so often you confirm you're still here — a deliberate action, on a schedule you choose. Each check-in resets the clock and nothing happens. But if you go quiet for long enough — and you decide how long that is — the vault opens to your recipients, and they receive exactly what you left them.

You stay in control the whole time. You can keep separate vaults for different people, change what's inside whenever you like, and name backup recipients in case your first choices never respond.

The idea is known as a dead man's switch. The name comes from the railways: early electric trains lost their two-man crew, which raised a new problem — what if the lone driver was incapacitated? The answer was a handle the driver had to hold down, so that if they collapsed at the controls, letting go would bring the train safely to a stop. It's a slightly grotesque term, but it captures the principle well: you stay in control while you're alive, and if you're not, the machinery takes over and carries out what you directed.

Until the moment it opens, everything inside stays secure — from hackers, and also from us. Your files are encrypted on your own device before they ever leave it, and the key to open them doesn't exist anywhere until it's needed.

How it works

Vaults and recipients

A vault holds your files and the recipients who should receive them. Each recipient has a name and an email address, and a waiting period — how long after you go quiet before the vault opens to them. Backup recipients get longer waits, so they step in only if the first ones never claim it.

Checking in

You decide how often you check in — monthly, yearly, whatever fits. A check-in is a deliberate confirmation that you're still here, and it resets the clock. You can also have Bequest email you ahead of each deadline.

If you stop checking in

Miss a deadline and the vault expires. Your primary recipients are notified, and any backups' waiting periods begin. The vault stays available to recipients for a retention period you set, then is permanently deleted.

How your files stay private

Your files are encrypted on your own device before they're uploaded, so Bequest only holds data it can't read. The key that unlocks them is never ours and isn't stored with the files. It's produced on demand by a network of independent computers running verified code, and released to a recipient only once their vault has opened. Until then it doesn't exist anywhere.

What your recipients see

Before a vault opens, a recipient sees nothing — and unless you tell them, they have no way to even know they've been named. When the vault opens, they're emailed a link, verify their identity, and download the files, which are decrypted in their own browser.

Where it runs

Bequest runs on the Internet Computer — a decentralized network of independent computers, not servers we control. There's nothing we could be pressured to unlock, because we can't unlock it ourselves, and no off-switch we could quietly throw. The rules that protect your vault are fixed in code running on the network.

Under the hood

This section is for readers who'd rather verify the claims above than take them on faith. None of it is needed to use Bequest.

Architecture

Bequest is four canisters (smart contracts) on the Internet Computer:

• Index — the trust anchor. Holds accounts, credits, vault metadata, recipient lists, and the check-in schedule. It is the only canister that can authorize a key derivation.
• Bucket — bulk storage, holding the encrypted file chunks and nothing else. Additional buckets are added as the system grows to accommodate more storage.
• Frontend — the app you're using now, served directly from a canister as static assets.
• Claim app - A stripped down simple to audit web app, just for claiming a vault.

Encryption and key handoff

Files and metadata are encrypted in your browser with AES-256-GCM before upload, so the bucket only ever receives ciphertext. The file keys are in turn wrapped to the vault's identity using vetKeys — the Internet Computer's threshold key-derivation feature. Recipient details are encrypted under a separate key — one the index can obtain itself, but only once that recipient becomes active — so their information stays secret until then.

With vetKeys, the vault's decryption key is never held by any one node. A threshold of the subnet's nodes derive it on demand — no single node ever sees the whole key — and return it encrypted under a transport key generated in the recipient's browser.

When a recipient becomes eligible they can request a derivation; the index — which runs in replicated mode across the 34 independent nodes of the Internet Computer's fiduciary subnet, more than two-thirds of which must agree on the result — checks that the vault has expired and their delay has elapsed before permitting it. The returned vetKey unwraps the file keys, and decryption happens entirely client-side.

Looking ahead: quantum

The encryption protecting your files is strong against any computer that exists today, but the key-handoff step relies on cryptography that a future large-scale quantum computer could, in principle, break. A patient attacker could store your encrypted vault now and hope to crack it years from now — "harvest now, decrypt later."

If that risk matters to you, add your own layer: encrypt your files with a symmetric cipher before putting them in Bequest, and share that passphrase with your recipients out-of-band — in your will, or a sealed letter. Symmetric encryption of this kind isn't threatened by quantum computers, and because the passphrase never touches the network, there's nothing online for a future attacker to harvest.

And Bequest still protects you even then. The time-lock is independent of the encryption: until your vault actually opens, the files can't be retrieved at all — so even someone who already holds your passphrase gains nothing until the dead man's switch has run its course. You get both at once: encryption that guards the contents, and a time-lock that guards when anyone can reach them.

Check-in, expiry, and delays

Each vault carries an expiry timestamp; a check-in pushes it forward by your chosen interval. A timer-driven sweep on the index expires vaults past their deadline and notifies the primary recipients. Per-recipient delays live in a time-ordered index and are activated by a later sweep — and the first successful claim cancels any backups still waiting. After expiry a vault is retained for a configurable period (at least a year) before a purge sweep deletes it permanently.

Integrity

Each file's contents are committed to with an elliptic-curve multiset hash computed in your browser; the index stores the commitment, and returns it along with the files. File listings are returned as certified queries — backed by an Internet Computer certificate and a witness — so your browser can confirm that what it received reflects genuine consensus state, and that downloaded bytes match what was stored, rather than something substituted by a single misbehaving node.

Verifiability

Everything above describes code we deliberately can't override:

• The index canister's and claim app's running code is identified by a module hash anyone can compare against a build from the public source.
• The index canister, and the claim app for it, are placed beyond anyone's control by removing their controllers — after which the code can't be changed or halted, including by us. Planned, once we leave beta.
• For more paranoid users, we provide a small, easy-to-verify Rust claim tool that you can build from source on your own computer.
• We also provide tools to perform file encryption entirely offline, and to hash the recipient passcode offline as well — again as a small, verifiable Rust CLI.

The guarantees don't rest on trusting us. They rest on code you can inspect and a network no single party runs.