Verifying a raffle seed yourself

The weekly raffle is drawn from a seed that is committed to before entries close and published in full afterwards. That structure means you do not have to take anyone's word for the result — including ours. Here is how to check it.

The commitment scheme

The idea is old and simple. Before the draw, we publish sha256(seed) — a fingerprint of a secret we have already chosen. After the draw, we publish the seed itself. Anyone can hash the revealed seed and confirm it matches the fingerprint published earlier.

Because SHA-256 cannot practically be reversed or collided, we cannot have picked a different seed after seeing the entry list. The hash locks us in.

What gets published, and when

1. Before entries close: the seed hash, the draw number, and the entry deadline.
2. At close: the final entrant list and total ticket count, frozen.
3. With the result: the raw seed, the winning index, and the winner.

Step 1 — check the hash matches

Hash the revealed seed and compare it to what was published beforehand. On macOS or Linux:

printf '%s' "THE_SEED_HERE" | shasum -a 256

On Windows PowerShell, or in any browser console:

crypto.subtle.digest('SHA-256', new TextEncoder().encode('THE_SEED_HERE')).then(b => console.log([...new Uint8Array(b)].map(x => x.toString(16).padStart(2,'0')).join('')))

If the output does not match the hash published before entries closed, the draw is invalid. Say so publicly and we will void it.

Step 2 — reproduce the winning index

The winning ticket is derived deterministically from the seed and the draw ID:

winningIndex = int(sha256(seed + drawId), 16) mod totalTickets

Concatenate the seed and the draw ID, hash the result, read the digest as a base-16 integer, and take the remainder modulo the total ticket count. In Python:

import hashlib
h = hashlib.sha256((seed + draw_id).encode()).hexdigest()
print(int(h, 16) % total_tickets)

Every input is public. Two people running this on the same published numbers get the same answer, or something is wrong.

Step 3 — map the index to an entrant

Tickets are allocated in entry order. An entrant with 12 tickets occupies 12 consecutive positions. Walk the frozen entrant list, accumulating ticket counts, until the running total passes the winning index — that entrant holds the ticket.

What this does and does not prove

It proves the seed was fixed before the entrant list was final, that the index follows from public inputs, and that the mapping from index to winner is mechanical rather than discretionary.

It does not prove the entrant list itself was honest. Commitment schemes secure the draw, not the roster. That part rests on the entrant list and ticket counts being published in full at close, so anyone who entered can confirm they appear with the right number of tickets. If your entry is missing or your count looks wrong, raise it before the draw — after it, the list is frozen.

Reporting a mismatch

Post the numbers in the Discord rewards channel: the published hash, the revealed seed, your computed digest, and the index you derived. A verifiable mismatch voids the draw and it is re-run with a fresh committed seed. Bring the arithmetic and it gets taken seriously.