How to run a verified random draw for a giveaway

In questa pagina

1. The trust problem with normal draws
2. How commit-reveal closes the gap
3. A 5-minute runbook for a giveaway
4. What the audience sees
5. Common mistakes that break the guarantee
6. What this is, and isn't
7. Try it

The fastest way to lose a giveaway audience is to draw the winner in private. Even if you're scrupulously fair, the chat will assume you weren't — because they have no way to check. A verified random draw fixes that. The technique is called commit-reveal, and it lets anyone in your audience replay the draw on their own machine, get the same winner, and confirm you didn't fiddle with the list afterwards. This post is a practical walkthrough you can run on a stream or in a Discord in under five minutes.

The trust problem with normal draws

A "normal" random draw on a streamer's machine looks like this:

1. The streamer collects entries.
2. The streamer clicks draw.
3. The screen shows a winner.

For the audience, step 2 is invisible. Did the streamer secretly remove three names before drawing? Add their cousin? Re-draw until a favourite came up? You can't tell. The streamer can't prove they didn't. Even good-faith streamers eventually face accusations because fairness you can't verify isn't fairness, it's just goodwill.

How commit-reveal closes the gap

A verified random draw splits the moment in two:

1. Commit. Before anyone knows who's entered, the streamer publishes a cryptographic fingerprint (a SHA-256 hash) of two things: the list of entrants and a secret random number called a "salt". The fingerprint reveals nothing about either input — but it locks them in.
2. Reveal. After entries close, the streamer reveals the secret salt. Anyone can take the entrants list + the salt, hash them, and check that the hash matches the one published in step 1. If the streamer had changed the list in between, the hash wouldn't match.

The list determines the winner, the salt determines the order, the hash makes both tamper-evident. Audience verifies; streamer can't cheat without getting caught.

A 5-minute runbook for a giveaway

This is the version you can actually do on stream:

1. Open entries. Collect entries however you normally do — chat keyword, Discord reaction, form. Stop accepting at a posted deadline.
2. Freeze the list. Export the entrants to a plain text file. One name (or wallet, or handle) per line. Sort alphabetically — this makes the file deterministic.
3. Generate the commitment. Open the verified draw tool. Paste the list. Click commit. The tool gives you a SHA-256 hash and a secret salt. Publish the hash on stream + in a pinned chat message. Keep the salt private until the draw.
4. Wait. A few minutes, an hour, a day — whatever your giveaway cadence is.
5. Reveal. On stream, paste the salt back into the tool. The tool recomputes the hash (so the audience can verify it matches the one you posted earlier) and announces the winner.
6. Share the verifier. A standalone JavaScript verifier — open source, runs in any browser — lets anyone in the audience plug in the list + the salt and rerun the draw on their own machine. Same winner every time.

The whole loop takes about as long as a normal draw, plus the ten seconds it takes to copy a hash into chat.

What the audience sees

From the chat's perspective the timeline is:

• T-0: "Here's the hash of my entrants list + salt: 8f3a…" → pinned in chat.
• T+1 hour (or whenever): entries close.
• T+1h05: "Here's the salt I committed to earlier: c1d9…. The tool reports the same hash. The winner is Alex."

Anyone who screenshots the T-0 hash can verify the T+1h05 claim independently. That's the entire point. They didn't have to trust the streamer; they could check.

Common mistakes that break the guarantee

• Publishing the salt before the deadline. If you leak the salt early, anyone who knows the list can compute the winner before draw time and game their entry.
• Editing the list after commit. Adding a single space changes the hash. The audience will spot it instantly.
• Reusing the same salt across draws. Each draw needs its own fresh random salt. A reused salt opens a tiny side channel.
• Hashing the list in a different format than the verifier expects. Whitespace, line endings, sort order all matter. The verifier and the committer have to agree on the exact byte stream.

What this is, and isn't

Verified random draw proves that you didn't tamper with the list or the result between the commit and the reveal. It does not prove that the list itself was complete (you could quietly leave out entries before committing), and it does not prove the entries were unique (you can still botted-enter your own giveaway). For high-stakes draws — regulated lotteries, prize laws — you still want a notary or an auditor in the loop. For a streamer giveaway, a verified draw is the right amount of rigour: fair enough that the chat can stop arguing.

Try it

The verified draw tool walks you through the commit/reveal flow with zero setup. Run a test draw on three dummy names before you go live; the muscle memory is worth ten seconds of practice.