Time-locked notes: writing messages you literally cannot read until a future date

Write a note today, hand someone the link, and guarantee that nobody — including you and Flowvault — can decrypt it until a future moment. That's the shape of a time-locked note. The clever part is that the guarantee holds even against the person who made the note. This post explains how that's possible at all, using a public randomness beacon called drand and a construction called tlock.

The goal: sealed until a date

There's a useful primitive buried in cryptography literature under names like “timed-release encryption”: a message you can only read after a fixed future moment, where the lock is enforced by mathematics, not by someone promising to keep a key safely. Practical examples:

A birthday letter to yourself that unlocks next year.
A predictions envelope that opens six months later so nobody can argue you rewrote it retroactively.
A recovery envelope that becomes readable on exactly January 1, 2030, not before and not after.
A disclosure commitment to a journalist that can't be opened early even under subpoena, because the publisher doesn't have the key either.

The key property is “not even the sender can cheat.” Traditional approaches — handing the key to an escrow service, scheduling a Cloud Function to email yourself — all rely on a trusted operator. Time-lock encryption gives you a cryptographic alternative.

Meet drand: the public randomness beacon

drand is a production randomness beacon operated by a consortium of independent parties (Protocol Labs, Cloudflare, EPFL, Kudelski, and several others). Every 30 seconds, the consortium produces a signatureover the current round number using a threshold BLS signing scheme. The signatures are publicly reproducible but cannot be computed early — they require real cooperation across the quorum of operators.

Crucially for our purposes: the drand consortium commits to apublic key up front. That public key, combined with a future round number, forms an identity that an IBE (identity- based encryption) scheme can encrypt to. When the round hits, the signature is the private key that decrypts.

tlock: turning beacons into encryption

tlock (Drand-Based Time-Lock Encryption, Timelock.zone, 2023) is the scheme that puts the IBE layer on top of drand. The idea:

Sender picks a target round number on the drand beacon (equivalent to a target date, at 30-second granularity).
Sender uses the drand network's public key and the target round as an IBE “identity.”
Sender encrypts a random AES-GCM key using IBE-to-that- identity, then encrypts the message with the AES key normally.
The wrapped key sits in the ciphertext. Nobody can unwrap it until the drand network publishes the signature for that round.
On or after the target time, anyone with the ciphertext fetches the signature from drand (it's public), decrypts the AES key, then decrypts the message.

The construction is audit-worthy because the security reduces to the hardness of computing a BLS signature over a round before the quorum signs it. As long as the drand operators don't collectively collude to sign early, the message is sealed.

How Flowvault uses it

Flowvault's /timelock/new page is a thin UI over tlock. When you submit:

The client converts your chosen unlock time to the matching drand round number.
The client generates a fresh AES-256 key and encrypts your message with AES-256-GCM.
The client runs tlock: encrypts that AES key to (drand public key, round) using the IBE scheme. This produces a small wrapped key.
The client uploads onlythe ciphertext + wrapped key + round number to Flowvault's server. No password, no email, no account. Optionally, if you ticked “require a password,” it also wraps the AES key a second time with an Argon2id-derived password key, so both the time lock and the password must yield before the reader sees plaintext.

Flowvault stores the ciphertext until 30 days after the unlock time (default retention), then garbage-collects it. That's the extent of our involvement.

The read path

When someone opens the share link flowvault.flowdesk.tech/t/<id>:

If the unlock time hasn't arrived, the page shows a countdown computed from the target round, and no ciphertext decryption is even attempted.
If the unlock time has arrived, the browser asks a drand endpoint (we use drand.cloudflare.com and api.drand.sh as fallbacks) for the signature on the target round.
It verifies the signature against the drand public key (a constant baked into the client).
It runs tlock decrypt to recover the AES key.
If a password layer was enabled, it prompts the reader for the password and runs Argon2id + AES-GCM to unwrap the inner key.
AES-GCM decrypts the payload. The plaintext is displayed.

Nothing about the decryption touches Flowvault's servers in plaintext. We only ever hold the opaque ciphertext and the round number.

Why trust drand?

The security of this scheme depends on drand actually being a threshold beacon, not a single party. Current drand operators include:

Cloudflare
Protocol Labs
EPFL (École polytechnique fédérale de Lausanne)
Kudelski Security
University of Chile
C4DT
Tbtc / Thesis
emerald (and others)

The “League of Entropy” consortium is publicly audited and has been running continuously since 2019. The threshold is set so that a strict majority of operators must cooperate to produce each signature. For an early unlock, an attacker would need to compromise or coerce more than half of independent organisations in multiple jurisdictions simultaneously.

Clock granularity and drift

drand produces one signature every 30 seconds, so Flowvault rounds unlock times to the nearest 30-second boundary. If you pick “May 12, 2027 at 14:00:15,” the actual unlock is “May 12, 2027 at 14:00:30.” The UI shows the effective unlock moment clearly.

drand's round timing uses a public genesis timestamp; it's clock-drift-free for practical purposes. Flowvault relies on this by converting target datetimes to round numbers at creation time and never re-computing them.

Five real use cases

Future-self letters

Write a letter to yourself on your birthday, unlock it in one year. Share the URL with a friend so you can't lose it (they'll see a countdown until it opens). Or keep it in your vault as a tab. The math guarantees the envelope stays sealed.

Prediction commitments

You think a particular event will happen. Write down the prediction, lock it 180 days out. If you're right, you've got a cryptographic receipt that you called it before the fact. Useful for forecasting, research pre-registration, journalism commitments.

Dead-drop disclosures

You commit to disclosing something in three months unless circumstances change. Lock the disclosure now, share the URL with your counterparty. They can see the commitment exists (the URL resolves) but cannot read it. The deadline is externally enforced by drand, not by your willingness to release.

Recovery envelopes

Combined with the trusted handover, this is powerful. Create a recovery envelope today, lock it to some far-future date. Store the URL in your vault. Configure a handover so that when you go quiet, your beneficiary gets the vault, finds the URL, and either waits for the envelope to unlock naturally or knows what to tell your executor to expect.

Multi-party coordination

Several parties each create time-locked envelopes that unlock on the same date. All of them can publish their URLs up front (nobody can peek). On the date, everyone's content becomes simultaneously readable. This is the sealed-bid auction pattern, useful anywhere you want to prevent last-minute information leaks.

What this doesn't do

It doesn't enforce a maximum lifetime. A time-locked note is readable forever once the round hits. If you want “destroy after the deadline,” combine it with a lifetime cap on the storage side (we garbage-collect ciphertexts 30 days after unlock by default).
It doesn't prevent copying.The recipient can screenshot the decrypted text, just like any other encryption scheme. This is a “when it can be read” primitive, not a DRM primitive.
It isn't post-quantum.BLS signatures rely on elliptic-curve pairings; a future quantum attacker could theoretically break them. For any lock shorter than the “practical quantum computer” timeline, it's fine; for 50+ year time capsules, pick a different tool.
It depends on drand continuing to exist.If the League of Entropy disbanded tomorrow, locks using those public keys would never unlock. The consortium is stable and has been running for years, but it's a real dependency. Flowvault doesn't promise longer-than-drand durability.

Comparison: other time-release approaches

                         Flowvault tlock   Email scheduler   Bitcoin timelock
Needs a trusted operator no                yes (Gmail etc)   no
Sender can cheat early   no                yes (reschedule)  no
Cost per envelope        free              free              tx fees
Granularity              30 s              minutes           ~10 min
Post-quantum             no                (depends)         depends