Don’t trust the flashing green “Fair” checkmark on your casino profile. This universal verifier lets you grab your raw seeds and independently audit the cryptographic randomness of your bets outside the operator’s system.
Every modern crypto-casino (including Stake, BC.Game, and Roobet) utilizes the exact same cryptographic primitives to guarantee game results aren’t altered mid-bet. To audit any specific game round, paste these values directly from your bet history panel (read our guide on how to verify provably fair outcomes):
I spent years assuming provably fair systems explained in marketing materials were just high-level wrappers to keep players quiet. But once you break down the mathematical flow, the cryptography is actually elegant. The system relies entirely on one fundamental algorithm: HMAC-SHA256.
The game takes your client seed, your nonce (bet number), and a cursor value (to handle games that need multiple numbers, like cards or mines boards). It joins them together using colons to create a clean message string:
Message = "client_seed:nonce:cursor"
Next, it runs the message and the revealed server seed through a Keyed-Hash Message Authentication Code (HMAC) using the SHA-256 hash function. This outputs a 64-character hexadecimal signature:
Signature = HMAC-SHA256(Server_Seed, Message)
This signature is mathematically locked. A single character shift in your client seed or server seed results in a completely unrecognizable, random-looking hash.
To turn this 32-byte signature into readable multipliers or card indices, the algorithm takes the bytes in groups of 4 (32 bits). It converts each group into a decimal fraction between 0 and 1:
Float = (Byte_1 / 256^1) + (Byte_2 / 256^2) + (Byte_3 / 256^3) + (Byte_4 / 256^4)
The verifier runs this identical math stream. By matching the output floats generated here with the cards, dice rolls, or crash points shown in your game history, you can prove if the operator is running a legitimate RNG.
Casinos aren’t stupid. They know most players will never look at their seeds, let alone write code to audit them.
You don’t need to check every single wager. Instead, develop a strict auditing habit: rotate your seeds after a big win or an unusually long losing streak, copy your active history, and paste them here.
If the casino ever outputs a result that doesn’t match this universal cryptographic stream, you have immediate, undeniable proof of fraud.
Before you place a bet, the casino shows you a SHA-256 hash of the active server seed. Because it is hashed, you cannot read the seed or predict outcomes. However, it acts as a commitment. When you rotate seeds and the raw seed is revealed, hashing it must produce that exact same digest. If it doesn’t, the casino cheated by swapping seeds mid-session.
No, not if you change it. When you generate a new custom client seed (e.g., typing a random sentence or using a local random number generator), the casino has no way of knowing what it will be until your bet is submitted. This makes it mathematically impossible for the casino to pre-determine a losing outcome.
Different games require different quantities of random numbers. A single dice roll only needs one float. A Plinko round needs one float per peg row. A mines board needs up to 25 floats to randomize the tile positions. Deriving multiple floats allows this tool to audit any game style.