What Is Provably Fair? How to Verify Crypto Casino Games

The problem provably fair solves

At a traditional online casino you trust that the random number generator is honest, usually because an independent testing laboratory has certified it for a regulator. That is a sound system, but you cannot check any individual result yourself. You trust the lab, the regulator and the casino’s integration of the game.

Provably fair adds a player-side check. The casino locks in its part of the random input before you bet and shows you a fingerprint of it. After you play, it reveals the input. You can then confirm that it matches the fingerprint and that it produces exactly the result you got. If the casino had changed anything after seeing your bet, the maths would not line up.

The idea grew up with Bitcoin dice sites in the early 2010s, when players had no regulator to rely on, and it is now standard for casino originals at crypto casinos. Our explainer on how Bitcoin casinos work covers the wider set-up.

The building blocks: hashes, HMAC, seeds and nonces

SHA-256: a one-way fingerprint

SHA-256 is a hash function standardised by the US National Institute of Standards and Technology. It turns any input into a 64-character hexadecimal string. The same input always produces the same output, a tiny change to the input produces a completely different output, and it is computationally infeasible to work backwards from the output or to find a second input with the same hash. That is what makes it a safe commitment: publishing the hash reveals nothing about the seed, but ties the casino to it.

HMAC-SHA256: a keyed hash

HMAC is a standard way of combining a secret key with a message to produce a hash, defined in RFC 2104 in 1997. Provably fair casinos typically use the server seed as the key and a message built from your client seed and the nonce. The output is 32 bytes, or 64 hex characters, that look random but are fully determined by those inputs.

The three inputs

• Server seed: a secret random value the casino generates. Before you play you see only its SHA-256 hash.
• Client seed: a value you control. You can keep the default or type your own. Because the casino commits to its seed before it knows yours, neither side can steer the result alone.
• Nonce: a counter that starts at 0 at most casinos (some start at 1) and goes up by one with every bet on the same seed pair, so each bet gets a fresh result.

Some games need more random numbers than one 32-byte output provides, for example a plinko ball that makes 16 left-or-right decisions. Casinos handle this with a further counter, often called a cursor or round, that is appended to the message to produce additional blocks.

The commit–reveal cycle, step by step

1. The casino generates a server seed and shows you its SHA-256 hash. It also shows the hash of the next server seed it will use, so the following cycle is committed too.
2. You set your client seed. Ideally you type something new rather than accepting the default.
3. You play. Each bet uses nonce 0, 1, 2 and so on with the same seed pair.
4. When you want to verify, you rotate the seed pair. The casino reveals the old server seed and moves to the next one it had already committed to.
5. You hash the revealed seed and compare it with the hash shown before you played.
6. You recalculate any bet from that cycle using the seed, your client seed and the bet’s nonce, and compare with your bet history.

The order matters. If a casino let you set your client seed and only then generated a server seed, it could in principle choose a server seed that favours itself against your known client seed. Seeing the server seed hash before you set your client seed is what prevents that.

Worked example: verifying a dice roll with HMAC-SHA256

The example below uses a simple scheme of the kind many crypto casinos publish: HMAC-SHA256 with the server seed as the key and the message “clientSeed:nonce:0”, the first four bytes turned into a number between 0 and 1, and that number scaled to a dice roll between 0.00 and 100.00. The seeds are deliberately readable so you can reproduce every number. Real server seeds are long random strings, and each casino’s exact formula is on its fairness page.

To verify, you do two things. First, hash the revealed server seed and check you get 8549a6e3… exactly. Second, recalculate the roll for the nonce of a bet in your history and check it matches. If both pass, that bet’s outcome was fixed before you placed it.

Why 10,001 and not 10,000? The scale gives 10,001 equally likely outcomes from 0.00 to 100.00 inclusive. Some casinos use a different scale or a different number of bytes, which changes the numbers but not the principle. That is why you should always use the formula the casino publishes for the specific game.

Checking it yourself in one line

If you have Node.js installed, this command reproduces the roll for nonce 7 without any casino tool. Replace the seeds and nonce with your own:

• node -e "const c=require('crypto');const h=c.createHmac('sha256','bgb-example-server-seed-2026').update('my-own-client-seed:7:0').digest();let f=0;for(let i=0;i<4;i++)f+=h[i]/Math.pow(256,i+1);console.log(Math.floor(f*10001)/100)"
• To check the commitment: node -e "console.log(require('crypto').createHash('sha256').update('bgb-example-server-seed-2026').digest('hex'))"

Python’s built-in hmac and hashlib modules can do the same in a few lines. The point is not that you need to code. It is that the calculation uses public, standard functions, so anyone can check it.

How games turn the hash into a result

A trustworthy casino publishes the exact formula for every original game, including how many bytes it uses per number and how it scales them. If a casino advertises provably fair games but does not explain how outputs become results, you can check that the seed was not swapped, but not that your result was calculated correctly.

Same float, different game: a limbo example

The same random number can drive a different game. Limbo, for example, often converts the float into a multiplier with the house edge built in. A common form is multiplier = 0.99 ÷ float, rounded down to two decimal places. Because the float is uniform between 0 and 1, the chance of a multiplier of at least M is 0.99 ÷ M, the same curve used by most crash games.

This is illustrative. Casinos differ in how many bytes they read, how they cap the maximum multiplier and how they round, so check the formula on the game’s fairness page before relying on your own calculation.

Provably fair at Telegram and on-chain casinos

Provably fair is not limited to browser casinos. Many Telegram casinos run the same seed system inside a bot or mini-app, and the checks are identical: you need to see the server seed hash before betting, be able to set a client seed, and get the old server seed when you rotate. If a bot shows results with no way to see or export the seeds, there is nothing to verify.

A smaller group of games settle on a blockchain. Instead of a casino-held server seed, the randomness may come from an on-chain randomness service or a smart contract, and the result is recorded in a transaction anyone can inspect. That removes the need to trust the casino’s database, but it moves the trust to the contract code and the randomness source, which most players cannot audit. On-chain does not automatically mean fair, and it says nothing about the house edge either.

Whichever form it takes, the same questions apply. Can you see what the casino committed to before you bet? Can you reproduce the result with public tools? Does the payout table give a reasonable return? If the answer to any of these is no, the label alone is not worth much. Our deposits and withdrawals guide covers the other half of trusting a crypto casino: getting your money out.

Crash and other shared rounds: hash chains and salts

Multiplayer games such as crash work differently, because everyone shares one round and there is no individual client seed per bet. The common solution is a hash chain. The casino generates a long chain of hashes in advance, where each round’s hash is the SHA-256 of the next one, and publishes the final hash before play starts. Rounds are then played from the end of the chain backwards, so each new round’s hash, once revealed, can be hashed to give the previous round’s hash. The casino cannot change a future round without breaking the chain.

To stop the casino from knowing results in advance, many games mix in a public salt that did not exist when the chain was committed, typically the hash of a future Bitcoin block. The long-running crash site bustabit used exactly this approach in its fourth seeding event in September 2025: it kept its existing chain of 100 million hashes and announced that the salt would be the hash of Bitcoin block 917,000, which had not been mined when the announcement was posted. Its published code computes an HMAC-SHA256 of the round hash with that salt, takes the first 52 bits, and converts them to a crash point with a 1% edge.

Some third-party crash games use a hybrid approach. Spribe’s Aviator, for example, is widely described as combining a server seed with client seeds from the first three players to bet in each round, and lets you view those inputs from the round history. Other studios’ crash-style games rely on lab-certified RNGs and are not provably fair at all. Our crash gambling guide covers the maths of the game itself.

What provably fair does not prove

• The house edge. The edge is in the payout table, not the randomness. A dice bet with a 49.5% chance that pays 2x returns 99% in the long run; the same roll paying 1.9x returns 94.05%. Both are provably fair. Our RTP guide explains how to compare them.
• That the formula is the one actually used for payouts. You can recalculate the result, but you must also check that the amount credited matches the payout table for that result.
• Anything about third-party games. Slots, live dealer and most table games from studios are not provably fair; they rely on certified RNGs.
• That the operator is solvent or licensed. A perfectly fair dice game is no use if the casino will not pay out. Our licence guide covers that side.
• That you will be treated fairly in disputes. Bonus terms, account closures and withdrawal limits sit outside the cryptography.
• That results you cannot verify are fair. If the casino never reveals a server seed because you never rotate, or resets your history, you have nothing to check.

Red flags in a provably fair system

• You cannot change your client seed, or the casino sets it for you with no option to edit.
• The server seed hash is not shown until after you bet.
• Rotating your seed does not reveal the previous server seed.
• The fairness page gives no formula, or a formula that does not reproduce the results in your bet history.
• The only verifier is on the casino’s own site, and it accepts any input without showing intermediate steps.
• “Provably fair” is claimed for third-party slots or live games where no seeds are exposed.

None of these proves cheating, but each removes part of what makes the system verifiable. A casino confident in its implementation has no reason to hide the inputs.

Third-party RNG certification: eCOGRA, iTech Labs and GLI

Most games at any casino, crypto or not, come from third-party studios. Those games are tested by independent laboratories before regulators allow them to go live. The labs examine the random number generator, how its output is scaled into game outcomes, and whether the long-run return matches the stated RTP over very large numbers of simulated rounds.

A lab certificate tells you the game was tested in a particular version, for a particular jurisdiction, at a particular RTP setting. It does not tell you which RTP version your casino runs, since many studios offer several. Check the game’s own information screen for its RTP, and where possible look up the certificate on the lab’s own website rather than trusting a logo in the casino footer. For more on how RTP settings vary between casinos, see our guide to RTP.

Provably fair versus certified RNG

The two approaches aim at the same goal from different directions. A casino offering lab-certified third-party games and provably fair originals with published formulas gives you both kinds of assurance.

Using provably fair when choosing a casino

A casino that offers provably fair originals, publishes its formulas, shows the next server seed hash in advance and lets you set your own client seed is being open about how results are produced. Large operators with in-house originals, such as Stake, BC.Game, Roobet and Shuffle, market their originals as provably fair, as do newer originals-led brands such as Duel. Check each game’s fairness page yourself, because formulas and edges differ between titles even at the same casino.

Treat provably fair as one trust signal alongside licensing (see our casino reviews for each operator’s licence), clear withdrawal terms and responsible-gambling tools, not as a guarantee on its own. Our crypto casino rankings flag operators with provably fair tools, and our Stake alternatives guide compares originals-focused casinos.

If you find yourself checking results to prove the game is “due” to pay, that is a sign to take a break. Every round is independent. Our responsible gambling guide lists the limits and support available, and our safer play hub links to free help services.