Provably fair slots: how results are generated
Updated 5 Nov 2026. Examples use live figures from the Engine fairness API.
"Provably fair" describes a way of generating game results so that you can check, after the fact, that a round was decided by a process fixed before you placed your bet. It is a cryptographic method, not a marketing label, and it proves something specific and limited. This guide explains how it works on Stake Engine slots, what it proves and what it does not.
The idea in plain terms
In an ordinary online slot you have to take the result on trust. The provably fair approach changes that by splitting the randomness into parts that neither side controls alone, and by committing to the casino's part before the round begins:
- The casino picks a secret value, the server seed, and shows you a fingerprint of it (a hash) before you play.
- You have your own value, the client seed, which you can change whenever you like.
- A counter called the nonce goes up by one with every bet, so each round uses a different input.
The result of each round is calculated from those three values. Later, the casino reveals the server seed. You can then confirm it matches the fingerprint you were shown earlier and recompute every round yourself.
How a result is picked on Engine
Engine, previously called Stake Engine, works with published outcome tables. For each mode of each slot, the studio publishes a table listing every possible round outcome along with a weight that sets how often it is chosen. A round does not spin virtual reels in the moment; it picks one entry from that table.
The steps are:
- The server seed, client seed and nonce are combined with HMAC-SHA256, a standard keyed hash function. Its output is a long string of bits that looks random and cannot be predicted without knowing the server seed.
- Those bits are turned into a number in a fixed range covering the total weight of the table.
- That number lands on one entry of the table. Entries with larger weights cover a larger share of the range, so they are picked more often.
- The chosen entry contains the full round: the symbols, any features and the payout. The game client then animates it.
Because the table is published and the hash function is public, the same three inputs will always produce the same entry. That is what makes replaying a round possible.
What provably fair proves
When the verification checks out, it establishes three things:
- The casino's seed was fixed before your bet. The hash you saw beforehand matches the seed revealed afterwards. Finding a different seed with the same hash is not practically possible.
- Your own input was used. Your client seed is part of the calculation, so the casino could not have chosen a server seed knowing exactly which results it would produce for you.
- The result came from the published table. Replaying the inputs lands on a specific entry, and you can confirm that entry is what the round paid.
Together those mean the result of a round was not changed after you placed the bet and was drawn from the table that anyone can inspect.
What provably fair does not prove
It is just as important to understand the limits:
- It does not make a game good value. The mechanism proves results come from the table. It says nothing about whether the table is generous. A slot with an RTP of 90% can be exactly as provably fair as one with 97%.
- It does not mean you will come out ahead. The table's RTP is under 100%. A fair draw from it is still a draw from a game with a house edge.
- It does not check rounds you have not verified. The proof applies round by round. If you never replay a round, nobody has checked it.
- It does not cover everything outside the draw. Account handling, bet limits, which game versions a casino offers and similar matters are separate from the cryptographic process.
For example, Waylanders Forge by Valkyrie has a base-mode RTP of 98.00% and a top payout that appears 1 in 2,002,135 base rounds. Provably fair confirms each round came from that table; the RTP tells you its long-run price.
Does provably fair mean a game can't be rigged?
This question comes up often, so it is worth answering precisely.
What the mechanism rules out is changing a specific result after a bet is placed, or choosing results based on what you bet. If the server seed was committed in advance, your client seed was used, and the replay matches, then that round was decided by the stated process.
What the mechanism does not address on its own is the content of the table. The table defines the RTP, the hit rate and the max win odds. On Engine those tables are published through a public fairness API, so their contents can be inspected and their RTP recomputed independently. The figures on this site come from the fairness API's per-mode summaries, which are calculated from those same tables, and whenever we download a full table (for example for the simulator) we recompute the RTP and check it matches.
So the honest answer is that provably fair, combined with published tables, lets you check two separate things: that each round came from the table, and what the table pays on average. It does not change the fact that the average is below what each round costs.
Why a published table matters
Some provably fair systems only prove that a random number was generated fairly, while the mapping from number to payout stays inside the game code. Engine's approach goes further by publishing the outcome tables themselves. That means the full distribution of results, not just the randomness, can be examined.
We currently track 7,013 games from 1,927 studios this way.
Every game page on this site shows figures derived from those tables: RTP per mode, how often a round pays, how often it pays nothing and how rare the top prize is.
Checking a round yourself
Verification is a short process: reveal or rotate your server seed, note your client seed and the nonce of the round, and replay it. The step-by-step version is in the guide to verifying slot results.
Key terms
| Term | What it is |
|---|---|
| Server seed | The casino's secret input, committed by hash before play and revealed afterwards. |
| Hashed server seed | A fingerprint of the server seed, shown before play so it cannot be changed later. |
| Client seed | Your input to the calculation, which you can change. |
| Nonce | A counter that increases with each bet so every round uses a different input. |
| HMAC-SHA256 | The keyed hash function that combines the inputs into a random-looking output. |
| Outcome table | The published list of every possible round and its weight, one per mode. |