Mechanics
drand: why your draw's randomness doesn't come from us
A draw your entrants can recompute themselves
Seed published before the draw, public drand randomness, shareable video. Free for entrants.
Create an accountVerify an existing drawAsked "where does the randomness come from?", most tools answer "from our generator". That answer asks for trust, and asks it from the person least placed to grant it: the entrant who lost.
At DrawSeal the answer is different: the randomness doesn't come from us.
The problem with in-house randomness
An internal generator, however excellent, shares one flaw with all the others: whoever runs it decides when to run it. They can call it, look at the result, and call it again. The generator keeps no record of how many calls were made.
This isn't a mathematical weakness, it's a positional one. No generator quality fixes it, because the problem isn't the value produced but the authority of whoever produces it.
The only way out is to take the randomness elsewhere, from someone who doesn't know what it's for.
What drand is
drand is a network of public randomness beacons. Independent organisations jointly produce, at regular intervals, a random value no single party controls. Each value carries a round number and a signature anyone can verify against the network's public key.
Three properties make it what we need:
- public: the value is readable by everyone, at the same moment;
- unpredictable: nobody knows the value of round 5,000,000 before it occurs;
- verifiable: the signature proves the value genuinely comes from the network and wasn't invented.
How we use it
When the draw is scheduled, DrawSeal announces which round will be used — a future number, chosen from the draw time. That is a commitment, exactly like the seed fingerprint.
Announcing the round in advance closes a specific door. Without it, an organizer could wait, compare several successive values, and keep the one designating the convenient winner. Naming the round forbids that choice.
At the appointed time, the value appears. It is combined with the revealed seed and the sealed list, and the winner is computed. Three inputs, exactly one possible output.
The ordering invariant, in two integers
What gives the mechanism its strength is a comparison of numbers, verifiable by anyone:
`sealRound < drawRound`
The list was sealed during a time window earlier than the one that produced the randomness used. In other words, when the pool was frozen, the randomness was not knowable — not even by us, who held the seed and the database.
This is not a promise. It is a `<` between two published integers.
What it changes for an entrant
They no longer have to believe us on two points. They can confirm the value used is indeed that of the announced round, and that this round is later than the list sealing. The network's signature secures the first; comparing two numbers gives them the second.
A third point remains — the list itself — and that is what the Merkle seal is for.
Key takeaways
An internal generator poses a positional problem, not a mathematical one: whoever runs it chooses when. DrawSeal therefore takes its randomness from drand, a public network whose values are signed, unpredictable and readable by all. The round used is announced in advance, and it is later than the list sealing — verifiable by comparing two published integers.
FAQ
What if drand is unavailable at draw time?
The draw waits for the value: it does not fall back on a backup source, which would mean using randomness nobody announced. drand unavailability raises an operational alert, and the draw runs as soon as the value is available.
Why not use a stock price or a lottery result?
Those are public sources, which is already something, but they are neither signed nor designed for this use. drand additionally provides cryptographic proof of origin: you verify the value came from the network, not merely that it was displayed somewhere.
Must an entrant understand drand to verify?
No. The verifier fetches the round's value, checks its signature and redoes the computation. Understanding the network's internals matters only to someone auditing the verifier itself — which is possible, and is the point.
Wouldn't the seed be enough?
No, and this is where many setups stop too early. A committed seed forbids changing it, but it comes from us. A second input we don't control is required, otherwise all the randomness remains internally sourced.