How it works

Three pieces, and which one does what, because somebody deciding whether to build on this needs the mechanism rather than the pitch.

How it works

Your app encrypts locally with batched threshold encryption (BTE) and sends a ciphertext. The coordinator stores it and holds no key that opens it. When the moment arrives, three of the five operators each publish a decryption share, the whole batch opens at once, and everyone reads the same result.

your app or agent bid, vote, quote, forecast encrypted here plaintext never leaves coordinator holds ciphertexts only no key that opens one batch of 64, padded with decoys 5 operators any 3 can open any 2 cannot ciphertext shares unreadable by anyone, including us the condition fires a time, or a block height everything opens at once, for everyone merkle root over the set
Encryption happens in your process. Nothing between it and the deadline can read the payload, and opening it takes three operators acting together.
open

Anyone can seal. Nothing is readable, including the count of what is inside.

closing

The deadline passed. The batch is frozen and padded; operators are producing shares.

opened

Every payload is public in the same instant, with a merkle root over the set.

A round can also say what it is, so somebody deciding whether to take part can see it before anything opens. That part is public from the moment the round exists, which is exactly the opposite of the payloads sealed to it:

Signed tour poster open

One of a kind, ships worldwide.

opens_at 2026-09-12T18:00:00Z · seals 14 · tag my-app

Three details worth knowing. How many sealed is not published while a round is open. seals and slots_including_decoys come back null until it opens, and the list of seal ids with them, because a live count is the number a competitor in a sealed auction most wants and the deadline is exactly when it is worth something. You read your own back with GET /v1/seals/{id}, using the id your own submission returned.

Then every batch is padded to 64 with decoys the coordinator seals to itself, so once a round has opened, a round with three submissions still does not announce that it had three; decoys come back flagged is_dummy. And slot positions are derived from the ciphertext hashes rather than arrival order, so a batch cannot be reordered after the fact.

Why Peal, not drand tlock

If you know timelock encryption you know drand tlock, and you should ask this before reading further. tlock is free, the drand beacon it rides on has run since 2020, and its own docs list the same applications this site does: sealed-bid auctions, MEV prevention, voting, responsible vulnerability disclosure. It is also the same primitive family as Peal, threshold BLS over BLS12-381, run by the League of Entropy: Cloudflare, EPFL, Protocol Labs, Kudelski Security and around twenty other named organisations. If a public unlock at a wall-clock time is all you need, use tlock.

drand tlockpeal
what opens itthe beacon's BLS signature for a round number: a point in wall-clock time, every 3 s (quicknet) or 30 s (default)a condition you define: a deadline, or a block height on a chain you name
the unitone ciphertext; each opens on its own, for everyone, once the round signature is publica round of up to 64 payloads; one 48-byte share per operator opens the whole batch at once
what an observer learns before the cuehow many ciphertexts were encrypted to that round, if they can see themnothing about the count: the batch is padded with decoys, and the count stays padded after it opens
committee traffic per revealone signature per round, shared by every ciphertext aimed at itone 48-byte share per operator per batch, constant while the batch fills
a chainnone needednone needed; three HTTP calls, and a chain only if you anchor a root to one
who holds the keys todaythe League of Entropy, around two dozen named organisationsfive independent operators, Meridian Assay, Halcyon Registry, Northwind Trust, Ardent Notary and Vantage Archive, none of them trusted; in v0 their shares were dealt by one ceremony, and DKG replaces the dealer
post-quantumno, and drand says sono; the same pairings

Two honest notes. Batching buys coordination and bandwidth, not pairings: the paper behind Peal is explicit that decryption costs a few pairings per ciphertext in every scheme, its own included, so do not read the table as a compute win. And the row that favours tlock is the one that matters most for value: until the keys come from a distributed generation, tlock's trust model is the stronger one.

Sources: drand, timelock encryption · drand/tlock · drand, about · Policharla, A Simple Batched Threshold Encryption Scheme, ePrint 2026/760.