Mechanics
The sealed seed: why its fingerprint is published before the first entry
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 drawBefore a DrawSeal giveaway accepts its first entry, one value is already published: the fingerprint of a number nobody knows yet. It is the simplest piece of the mechanism, and the one that closes the widest door.
What a seed is
A draw needs a starting value — a seed. From it and a known method, the computation is fully determined: the same seed, the same list and the same randomness always yield the same winner.
That property is what makes a draw replayable. It is also what makes it dangerous if the seed stays free: whoever chooses it after seeing the list chooses the winner.
The fingerprint, and the two properties that matter
When the draw is scheduled, DrawSeal publishes not the seed but its fingerprint: `sha256(seed)`.
A hash function has two useful properties here:
- it cannot be reversed: the seed cannot be deduced from the fingerprint. Publishing one reveals nothing of the other, and the draw stays unpredictable;
- it cannot be worked around: producing a second seed yielding the same fingerprint is out of reach. Whoever published the fingerprint is therefore bound to their seed.
The commitment is made before entries open, and cannot be taken back. At reveal, anyone recomputes `sha256(seed)` and compares it to what was published: the two match, or the draw is invalid.
What the fingerprint doesn't prevent on its own
This is where many "provably fair" setups stop, and it is not enough.
The fingerprint binds the seed. It says nothing about the list or the randomness used. An organizer bound to their seed can still:
- add or remove an entrant after seeing what the seed would produce;
- wait, among several possible randomness values, for the convenient one.
Hence the mechanism's two other commitments: the drand round number announced in advance — which randomness, and no other — and the list seal published at closing, before that round exists.
The three commitments do not substitute for each other. They close three different doors, and all three are needed.
The timeline, which is everything
| Moment | What is published | What it closes |
|---|---|---|
| Scheduling | `sha256(seed)` + target drand round | Changing seed, changing randomness |
| Entries close | Fingerprint of the sealed list | Altering the pool |
| Draw time | The drand value appears publicly | — |
| After | The seed is revealed | Full verification |
This table reads in one direction only: each row is published before the next becomes knowable. That ordering, not the cryptography, carries the guarantee.
The freeze window
A practical detail completing the setup: in the twenty-four hours before the draw, the giveaway's rules can no longer be edited. A commitment made on the seed would lose its meaning if the conditions accompanying it could be rewritten the day before.
Key takeaways
The `sha256(seed)` fingerprint is published before the first entry. It does not reveal the seed — the draw stays unpredictable — and it forbids presenting a different one later. On its own it isn't enough: it prevents neither altering the list nor choosing among several possible randomness values. It only has value combined with the announced drand round and the list seal published at closing.
FAQ
What happens if the revealed seed doesn't match the fingerprint?
The draw is invalid, and this is established without argument: the check is a comparison of two strings. It's a binary test, which the verifier runs first.
Does the organizer know the seed before the draw?
It is held by the platform, not the organizer, and revealed only afterwards. But the question needn't be settled by trust: even knowing it, nothing can be done with it, since the drand randomness used doesn't yet exist.
Why not publish the seed directly?
Because the draw would become predictable: anyone could compute in advance who wins, and decide whether to enter accordingly. The fingerprint gives the commitment without giving the information.
Is sha256 still secure?
For this use, yes, comfortably. The required property is second-preimage resistance — producing a different seed with the same fingerprint — for which no practical attack is known.