An interactive guide to understanding how cryptographic hashing ensures casino games can't be rigged — and how you can verify every single result.
Show definitions
Hover or tap any dotted-underlined term throughout this page to see its definition, or expand this panel.
A hash function takes any input and produces a fixed-size output (256 bits / 64 hex characters). Even a tiny change to the input completely changes the output. This is called the avalanche effect — and it's why hashes are practically impossible to reverse or predict.
Try changing a single letter below and watch how the entire hash transforms:
Collision resistance
There are 2256 possible SHA-256 outputs — more than the number of atoms in the observable universe (~1080). Finding two different inputs that produce the same hash would take longer than the age of the universe, even with all the world's computers working together.
This is exactly why an operator can commit to a round by showing you the hashed server seed before you play. Since it is computationally impossible to find a different server seed that hashes to the same value, you are essentially guaranteed that the operator cannot swap out or change the server seed after the fact. The hash locks them in — if the revealed seed doesn't match the hash they showed you, you know they cheated.
Before any bets are placed, the operator commits to a server seed (the key) by publishing its SHA-256 hash. You (the player) can't see the actual seed yet — only the hash. This proves the operator can't change its seed after the fact.
You then provide your own client seed. The game combines the server seed (the key), your client seed, and a nonce (round number) into the message, then runs it through HMAC-SHA256 to produce the random output. The nonce acts as a salt — it ensures every round produces a completely different result from the same seed pair.
Why is this fair?
The operator can't change the outcome because they already committed to the seed hash. The player can't predict the outcome because they don't know the server seed (key). After the round, the operator reveals the seed and you can verify the hash matches — proving nothing was tampered with.
The 256-bit HMAC output is just raw bytes. To turn it into a game result, we take the first few bytes and convert them into a number within the game's range.
In Stake Engine games, the HMAC doesn't produce a simple small number like “slot 14”. Instead, it generates a very large random number (128 bits), and this number is mapped against a weighted lookup table that defines every possible outcome and its probability.
Each event in the table owns a range of values proportional to its probability. Rare outcomes (big wins) have tiny ranges. Common outcomes (losses) have large ranges. The random number simply falls into whichever range it lands in — no decisions, no manipulation possible.
Event 0: 0x (Loss)
(payout 0x)
The lookup table is published as part of the game — anyone can inspect the exact weights, verify the probability distribution, and confirm that the random number correctly maps to the outcome they were given. This is the final piece of the provably fair chain: the random number is locked by the HMAC, and the table is locked by the game definition.
How real lookup tables work
Real Stake Engine games use 128-bit random values and tables with hundreds of thousands of weighted events. The total weight (sum of all ranges) can be astronomically large, but the principle is identical to the example above: the random value mod the total weight lands in exactly one range, and that range determines the outcome. You can inspect any game's full lookup table on its detail page in the catalog.
After a game round ends, the operator reveals the actual server seed (key). You can then:
If any step doesn't match, the game was tampered with. This is mathematically provable — no trust required.
Provably fair is a powerful tool, but it's important to understand its scope.