Provably Fair Casinos

A provably fair game decides its outcome before you bet. The casino generates a server seed, hashes it, and shows you the hash. You supply or accept a client seed. A nonce counts up with each round. Combine the three, run them through a published algorithm, and you get the result. The hash goes out first, so the server seed cannot be swapped afterwards without breaking it.

That is the whole claim. It proves the round was fixed in advance and not altered once your stake was in. It is a tamper check, not a certificate of generosity.

The check matters because the alternative is trust. On a game with no published seeds you are taking the operator's word that the dice were not weighted against the size of your bet, or against your account in particular. Provably fair replaces that word with arithmetic you can repeat on your own machine.

The edge sits somewhere else entirely. Stake Originals run at 99% RTP, which is a 1% house edge. BGaming Crash is also 99%. Spribe Plinko is 97%. Those figures come from the game rules, not from the seed system. A provably fair game with a 3% edge is still a 3% edge game. What the seeds tell you is that the 3% was applied honestly, round by round, in the order the rules describe.

Rotate your seed when you like. Most implementations let you set a client seed by hand and reveal the old server seed when you change it. Once that server seed is revealed you can replay every nonce you played under it and confirm each result matches.

Verification takes four inputs: the hashed server seed you were shown before play, the unhashed server seed revealed afterwards, your client seed, and the nonce of the round you care about.

Start with the hash. Run SHA-256 over the revealed server seed. The output should match the hash the casino published before you started betting. If it does not match, the seed was changed and nothing else on the page is worth reading.

Then reproduce the outcome. The game combines server seed, client seed and nonce with HMAC-SHA256, then maps the resulting bytes onto whatever range the game needs: a tile in Mines, a peg path in Plinko, a multiplier in Crash, a number between 0 and 100 in dice. That mapping is written down in the game's fairness page. Feed the same inputs through the same function and you get the same result, or the operator has a problem to explain.

Our fairness verifier does both steps in the browser for the common Stake-style implementations. Nothing leaves your machine. You paste the seeds and the nonce, and it prints the outcome it derives from them.

Two habits turn this from theory into something useful. Copy the hashed server seed before you start a session rather than after, because after is too late to prove what was committed to. And rotate seeds periodically, since each rotation reveals the previous server seed and lets you audit a whole block of rounds in one pass.

If a site publishes no seeds, or publishes them only for its in-house originals and not for third-party studio titles, treat the third-party titles as unverifiable. That is not automatically dishonest. It means the check is unavailable, and you are back to trusting the studio and its testing house.

Provably fair says nothing about the house edge. European roulette pays 2.7% to the house whether or not you can hash the wheel, and American roulette pays 5.26%. A verifiable dice game with a 1% edge takes 1% of everything staked over enough rounds, and the seed check confirms only that it took it by the published rules. The edge is the price of the entertainment. Cryptography does not discount it.

It says nothing about whether the casino pays. Seeds are a game integrity mechanism. They do not touch withdrawal processing, account closures, bonus term disputes or source of funds requests. Those are operational questions, judged on payment records, published terms and how an operator behaves when a payout is large. Our methodology page sets out how we weigh them.

It says nothing about variance. Reproducing a losing streak byte for byte tells you the streak was honest. On a 16-row Plinko drop the outer 1000x bucket sits at roughly 1 in 32,768 per drop, because the bucket probabilities are binomial. A verified result will confirm you did not hit it. It will not shift the odds on the next drop, since each drop is independent of the last.

It also does not make any betting pattern profitable. Stake sizing, seed rotation and timing all leave the edge where it is, because the edge applies per round and the rounds do not remember each other.

Finally, verification is only as good as the published algorithm. If an operator documents its mapping function vaguely, or changes it without notice, your reproduction fails and you will not know why. Sites that version their fairness documentation, and keep the old versions readable, are doing something the marketing pages rarely mention.