How a release actually happens

Heemnota separates three things that are easy to blur together: your sign-in, your vault passphrase, and the keys that open a release packet.

You write the map

The ledger holds reference information: providers, approximate amounts, document locations, and instructions. It is encrypted in the browser before upload. The hosted copy is ciphertext. A release packet is a second ciphertext, built only from what you select for that person.

You seal it to people, not to the server

Each recipient publishes a public release key, or you generate one and give them the private half through a channel you trust. The packet key is wrapped to that public key. If you add verifiers, the packet key is split. No single verifier, and not Heemnota, can reconstruct it alone. Verifiers confirm by re-wrapping their share to the recipient. They do not receive the packet.

You check in

Choose an interval such as 30, 60 or 90 days, a grace period, and when reminders should arrive. Checking in restarts the clock. Missing the date starts the grace period. During grace, and while verifiers are still confirming, Cancel release is one click. That puts the policy back to armed and discards verifier confirmations already submitted.

Release is access, then decryption

When the timer and the verifier rule are both satisfied, recipients are emailed a link. They decrypt locally. Heemnota still cannot read the packet. A download that already happened cannot be pulled back. Cancelling after release does not erase a copy someone has opened.

A public receipt, not a copy of the packet

When a policy is armed, cancelled, or released, Heemnota can submit a 32-byte commitment to the public OpenTimestamps calendars. Those calendars later anchor batches of hashes to Bitcoin. The commitment is a hash of the event type, the time, a hash of the check-in rule, and a salted hash of the policy id. The salt, the rule numbers, and the proof stay in a receipt you can open on the verification page. Names, email addresses, and packet contents are not in the commitment and are not sent to the calendar. A pending receipt means a calendar accepted the hash. It becomes a Bitcoin timestamp only after the proof is upgraded, which you can check with any OpenTimestamps client. Heemnota can still release without waiting for that confirmation, and a calendar can be offline without stopping the release.

What this does not do

It does not prove that someone has died. A missed check-in can mean a lost phone, a hospital stay, or a full inbox. The grace period and optional verifiers exist because a timer is a weak signal. It also does not replace a will, a beneficiary form, or a lawyer. Read the security notes before you store anything you would mind losing or exposing.