Do not trust us. Check us.
Every Free Roll number is generated from seeds we are committed to in advance. The verifier further down runs the whole algorithm inside your browser, using the same inputs we used, and tells you whether it lands on the number we paid you. It never asks us for the answer.
Commit, roll, reveal
1. We commit
Before you can roll, we generate a 32 byte server seed, keep it secret, and publish its SHA-256 hash. The hash gives away nothing about the seed, but there is exactly one seed that produces it, so from that moment we are locked in.
2. You roll
Your roll mixes our committed seed with your own client seed and a nonce that counts up by one each time. You can set the client seed to anything you like, which is what stops us choosing inputs that suit us.
3. We reveal
Rotate your seed and the old server seed is published. Anyone can now hash it, compare it to the commitment we showed you first, and recompute every roll it produced. If we had changed a single roll, this step would expose it.
The exact algorithm
No paraphrase. This is what the server runs, line for line.
serverSeed 32 random bytes as hex. We publish SHA-256(serverSeed) first.
clientSeed yours, and changeable at any time.
nonce 0 for your first roll on a seed pair, then 1, 2, 3 and so on.
cursor 0, and advances only once all 32 bytes it produced have been read.
bytes = HMAC-SHA256(key: serverSeed, message: "clientSeed:nonce:cursor")
32 bytes per cursor, read as one continuous stream
n = the next 4 unread bytes of that stream, big endian, as an unsigned 32 bit integer
if n >= 4294960000, discard it and take the next 4 bytes of the same stream
(8 draws come out of each cursor before the cursor advances)
raw = n mod 10000
roll = raw / 100 which is 0.00 through 99.99Two details are worth calling out, because they are where a fair looking scheme usually goes wrong. The server seed is used as the HMAC key as text, exactly as it is printed, not as the bytes its hex spells out. And 232 is not a multiple of 10000, so taking the remainder of the full range would leave 7296 outcomes very slightly more likely than the rest. The bias is around 0.0002%, far too small for anyone to notice, which is precisely why it is worth removing: provably fair has to mean provable, not unnoticeable. Draws at or above 4294960000 are discarded and the next four bytes of the same stream are used instead. A rejected draw does not advance the cursor, and that is the detail an independent verifier is most likely to get wrong: each cursor yields 32 bytes, so eight draws come out of it before the next one is requested.
Verify it in your browser
Paste a revealed seed pair, or look a roll up by its id and let it fill the form.
Check a roll yourself
This form recomputes the roll in your browser. Nothing is sent to us, so what you see is your own machine agreeing with us, or not.
Look up a roll by id
Fetches the seed data we recorded for one roll. Once its seed pair has been retired, the server seed comes back with it and loads into the form on the left.
What this does and does not prove
It proves the roll was not tampered with
A server seed that hashes to the commitment you were shown first, and produces the roll you were paid, cannot have been chosen after the fact. There is no room in between for us to have picked a cheaper prize.
It does not prove the ladder is generous
Fairness is about the draw, not the prizes. The bands are published in full on the Free Roll page and they are read from the same constant the payout engine uses, so judge them on their own terms.
A seed is only published once its pair is retired, because publishing a live seed would let anyone predict every roll still to come on it. Rotating your client seed retires the pair immediately, so you never have to wait for us to decide when you are allowed to check.