What provably fair means and how to verify a bet

Provably fair means the casino locks in the result of your bet before you place it and hands you the means to check it afterwards. Before the bet you see a hash of a secret server seed; you add your own client seed; a counter called the nonce numbers each bet; after you rotate seeds the secret is revealed and you can recompute every result yourself. It proves the outcome was not changed after you bet. It does not prove the odds are good or that the cashier pays, and it only covers the operator’s own games, not third-party slots or live tables.

The scheme in four moves

Every implementation I have read is a variation of the same commitment scheme. Shuffle’s help centre describes it in the plainest terms, so I use its wording as the reference.

1. Commit. The server generates a secret seed (Shuffle: a random 64-character hex string), hashes it with SHA-256 and shows you only the hash. The hash is the commitment: the server cannot swap the seed later without the hash changing.
2. Contribute. You supply a client seed. Your browser generates one by default and you can edit it. This is your share of the randomness, so the operator cannot pick a server seed that beats a client seed it does not know yet.
3. Count. The nonce starts at 0 and rises by one with every bet on the same seed pair, so each bet gets a fresh result from the same two seeds.
4. Reveal. When you rotate to a new seed pair, the old server seed is shown unhashed. You hash it yourself, compare it with the commitment, then recompute each bet from server seed, client seed and nonce.

Cloudbet’s fairness page sums up the goal in one line: both sides contribute to the randomness, so neither can control the outcome alone, and the casino must prove it did not change its input after the fact.

The formula, worked once by hand

Shuffle publishes its implementation in code. The result of a bet comes from HMAC-SHA256, keyed with the server seed, over the message clientSeed:nonce:round. The 32-byte output is cut into eight groups of four bytes, and each group becomes a number between 0 and 1. A game that needs more than eight numbers moves to the next round and computes a fresh HMAC. For dice, Shuffle multiplies the first number by 10,001, rounds down and divides by 100, which gives a roll from 0.00 to 100.00.

Shuffle’s own documentation uses a toy example: server seed def, client seed abc, nonce 1. I recomputed it with Python’s standard hmac module to check the description against the arithmetic.

Real server seeds are 64 random hex characters, not three letters, but the steps are identical. The provably fair calculator runs this formula in your browser: pick the “Stake-style” formula, paste the three values, and the dice result comes out the same way. One caution on the commitment step: an operator may hash the seed as text or as raw bytes. If your hash does not match, check which one its documentation uses before you conclude anything.

What it proves and what it does not

The scheme answers one narrow question very well. The rest of the questions a player should ask sit outside it.

The edge point deserves a sentence of its own. Shuffle’s Limbo code sets rtp = 0.99 inside the function that turns the random number into a multiplier, a 1% edge written into the formula in plain view. A provably fair game with a 5% edge verifies just as cleanly as one with 1%. The scheme guarantees the dice are not loaded after the fact; it does not say how the dice were designed.

The edge cases that trip people up

A seed you never rotate is never revealed

The server seed only becomes public when you rotate the pair. Shuffle’s verification steps start with “rotate pair”, and its help page notes that client seed and nonce for past bets stay the same. If you play a thousand bets on one pair and never rotate, you have a commitment and nothing to check it against. Rotate after any session you might want to audit. Shuffle also asks you to finish any open game first.

Leaving the default client seed

The browser-generated seed is still a seed the server did not choose, so the scheme holds. Setting your own adds certainty that no script on the page picked it for you, at no cost. Cloudbet accepts up to 255 characters.

Multiplayer games use a shared chain instead of your seed

In a crash round everyone sees the same result, so there is no single client seed to mix in. Operators use pre-committed hash chains instead. Gamdom generated a chain of 10 million SHA-256 hashes per game, published the final hash, and plays the chain in reverse; you verify that the SHA-256 of each round’s hash equals the previous round’s hash. BC.Game uses the same idea for Crash, with a published formula and a verifier. Rainbet’s fairness page says its multiplayer games, Case Battles and EOS Roulette, take outcomes from EOS blocks.

Not every operator uses HMAC-SHA256

Cloudbet’s Originals use SHA3-256 for the commitment and the round signature, then SHAKE256 to produce the random stream, with rejection sampling so that no outcome is favoured by uneven division. That is a sound design, but it is a different formula. My calculator implements the HMAC-SHA256 family only, so a Cloudbet bet has to be checked with Cloudbet’s own game verifier and server seed verifier, which its fairness page provides.

Verifying a bet, step by step

1. Before you play, copy the hashed server seed and your client seed from the game’s fairness panel.
2. Place your bets. Note the nonce of any bet you want to check; the bet slip usually shows it.
3. Rotate the seed pair. The previous server seed is now shown unhashed.
4. Hash the revealed server seed with SHA-256 (SHA3-256 at Cloudbet) and compare it with what you copied in step 1. A mismatch is the only result that matters in this whole exercise.
5. Paste server seed, client seed and nonce into the calculator or the operator’s verifier, choose the game, and compare the result with your bet history.

Where the values live differs by site. Shuffle has a “rotate pair” control in the bet modal and a public verification tab. Wolf.bet has Overview, Verification and Implementation tabs, the last one showing the JavaScript for Dice. Gamdom links sample code for each of its eleven chain-based Originals. Roobet‘s fairness page has a tab for each of fourteen games, from Crash to Wheel. Rainbet has a “Game Verifier” tab and per-game algorithms. Duelbits publishes daily seeds and Node.js code for its Originals.

Third-party slots and live tables are a different system

A slot from an outside studio runs on that studio’s random number generator, and the casino cannot hand you a seed for it. Fairness there rests on lab testing, not on anything you can recompute. Gaming Laboratories International, one of the testing labs, lists RNG and RTP analysis among its iGaming services and publishes GLI-19, its standard for interactive gaming systems. A certificate is something an operator or studio either publishes or does not; a sentence in the help centre is not one.

Some of the sites I review show the gap clearly. SportsBetting.ag says its RNGs are approved by GLI but links no certificate. Bovada‘s fairness page is generic and names no lab. BetUS’s terms say random number generator software determines outcomes, with no lab named. Live dealer games are physical cards and wheels on camera, so a seed scheme does not apply to them at all. The live casino category and the slots category list sites by what they offer, not by provable fairness.

One partial exception: BitStarz says most BGaming titles it carries are provably fair and explains the method. That is the studio’s scheme, not the casino’s, and it covers only that studio.

Reading a fairness page critically

“Provably fair” is a phrase anyone can put in a footer. The test is whether you can actually verify a bet without an account and without trusting the operator’s word. I set the provably fair flag on a review only when a public verifier or published formula exists. Three cases from my research show why the rule matters.

Read on 2026-10-06. Questions worth asking of any fairness page: is the formula published, or only the word “fair”? Is there an algorithm per game, or one generic paragraph? Can you verify a bet after rotation, including old ones? Does the page say which games it covers? Stake’s help article, for instance, explains provable fairness for “Stake original games” specifically, which is the honest scope.

How it counts in my score

Provably fair sits inside “Games & odds”, which carries 15% of the score at the weights published on how I rate. It is one input to that part, alongside library size, providers, originals and sportsbook margins. Payout speed and reliability carry 25%, and reputation 20%. That weighting is deliberate: a verifiable dice game at a site that sits on withdrawals is still a site that sits on withdrawals. The provably fair page lists the reviewed sites that pass the verifier rule, and the crypto casinos category shows them in context.

The short version

Provably fair is a commitment: the hash you see before the bet locks the result, and the revealed seed lets you recompute it. Rotate your seeds after any session you might audit, set your own client seed, and check one bet with the calculator to see that it works. Then look elsewhere for what the scheme cannot tell you: the edge per game, whether the slots have a lab certificate, and whether the cashier pays. The scam guide covers the last part.