What Is Provably Fair and How Can You Verify a Game?

A round is lost, and the fairness window shows a server seed, a client seed, a nonce and a long string called a hash. Something in there is supposed to prove the game played honestly, but nothing on screen says what a player can actually check — or what a successful check would prove. This guide explains what provably fair means, how the verification scheme works, how to verify a round step by step, and where the limits of the check are.

What Does Provably Fair Mean?

Provably fair is a verification approach for casino games: the operator fixes the data that determines a round before you bet, follows a published algorithm, and reveals the hidden part afterwards so the result can be recomputed and compared. The check confirms consistency — the round matches the data that was committed before the bet.

Four separate things should not be blurred together. Verifiability covers the outcome of a single round. Randomness is a property of the number generation behind it. The game’s mathematical rules — including RTP, the return-to-player percentage a game pays back over a long run, and the house edge, its mathematical share on average — are set by the paytable, not by verification. And the reliability of the operator as a business is a question the scheme does not touch.

How Does a Provably Fair System Work?

Most implementations follow the same four phases: commitment before the bet, the game itself, disclosure of the hidden data, and verification afterwards. A useful mental image is a sealed envelope: the operator seals the outcome data before the round, hands you the sealed envelope, and opens it afterwards so you can compare the contents. The limit of the analogy matters, though — what is compared is a digital fingerprint of the data, not a physical envelope with a wax seal.

One common scheme works like this. It is an example of how such systems are built, not a single industry standard.

Server seed and hash

The server generates a server seed — a random string that will influence every round played with it. Before you bet, the game shows its hash: a one-way cryptographic fingerprint of the seed. A hash is not an encrypted version of the data; it cannot be reversed into the seed, but any later claim that “this was the seed” can be tested against it. In Stake’s documented implementation, the seed itself is revealed only after the player rotates the seed pair, and the hash shown before betting acts as the commitment.

Client seed

The client seed is the player’s contribution, usually a string you can set yourself in the fairness settings. Because the operator cannot know it in advance, it cannot pre-compute the results of your rounds. Its purpose is to remove any possibility of the house steering outcomes — not to let the player steer them.

Nonce and the game result

The nonce is a counter that increments with every bet made under the active seed pair, so each round combines the same inputs with a fresh number. Games that need more than one random value — blackjack deals, for example — take additional values from the same stream, with a cursor marking the position in it. Stake’s implementation uses HMAC SHA-256, a keyed construction, while BGaming’s provably fair games describe SHA-256 over a result plus a secret string — different algorithms serving the same purpose, which is exactly why a universal formula for all provably fair games cannot be given.

How to Verify a Provably Fair Game

The exact fields and formulas differ between platforms, so treat the documentation of the specific game as the source of truth. The sequence below follows the published workflow of documented implementations:

1. Before betting, save the commitment. Open the fairness window, find the hash of the active server seed, and note the game name and algorithm version if they are shown. The commitment has to exist before the bet — a hash that appears only after a round does not prove anything was fixed in advance.
2. Record your inputs. Save the client seed, the nonce or round number, and any other parameters the documentation requires. Do not assume the field set of one platform applies everywhere.
3. Get the disclosed data. After the round — or after you rotate the seed, which is when Stake reveals the server seed — collect the revealed values and the round record.
4. Check the commitment. Compute the hash of the disclosed data exactly as the documentation specifies — string format and encoding matter — and compare it with the hash you saved.
5. Reproduce the result. Follow the documented algorithm from the full data set, including the step that converts random values into a card, a dice number or a multiplier. This is a separate task from the hash check.
6. Compare and act. Match the recomputed result against the round record. If they differ, first re-check the seed, nonce, cursor, string format and game version before concluding anything — and keep the data for a support request.

A compact worked example makes the first check concrete. The following is a labelled teaching example using BGaming’s documented scheme — SHA-256 over a result value plus a secret string — not a record from a real casino round. Suppose the game committed to the hash f13d6868a091a367d1b53d00d66c6fcef5fc22cdfe8f71203d64fb4837dc5b36 before the round. After the round it reveals a result of 12 and a secret of 8m2v7t1a. Computing SHA-256 over the string “128m2v7t1a” in any standard SHA-256 tool returns exactly the committed hash, so the commitment check passes. What this example does not yet do is reproduce the game event: turning a raw value into a wheel position, a card or a multiplier follows the individual game’s documented rules, and that second check has to be made separately.

Provably Fair Calculator, Checker and Verifier

A provably fair calculator, checker or verifier automates the arithmetic of the previous section: you enter the revealed server seed, the client seed, the nonce and — where the algorithm uses one — a cursor, and it recomputes the hash and the result. What the tool does is arithmetic. A “generator” in this context produces test seeds and hashes for a committed scheme, and no tool name implies the ability to predict future rounds.

Compatibility is the practical catch. A checker reproduces one algorithm — often the HMAC SHA-256 scheme documented by Stake-style platforms — and a different implementation, such as BGaming’s SHA-256 construction, needs a different procedure. Tool fit depends on the operator, the game, the algorithm and its version, and there is no universal verifier for every provably fair casino. When a platform documents its algorithm well, any standard SHA-256 or HMAC tool is enough; when it does not, no tool can save the check.

Provably Fair Games in Crypto Casinos

The mechanism appears across the usual game set. Dice rolls map a random value onto a number range; crash draws the multiplier at which the curve collapses; roulette and blackjack versions use the stream of random values to pick pockets and deal cards. Some in-house games expose fairness parameters directly; in provider-made slots the equivalent checks, when they exist at all, follow the provider’s own documentation.

Card games show why per-game documentation matters. Stake’s game documentation describes its Hi Lo as drawing from the 52-card set with decks effectively unlimited — a rule of that specific version, not a description of card games in general. The same caution applies to craps and Bitcoin lottery titles: verification can be described in principle, but concrete claims about a specific product require that product’s documentation, which is why this guide stops at the mechanism.

One more distinction belongs here. Whether a game is played in BTC, ETH or BNB says nothing about how — or whether — its results are verified. The payment currency and the fairness mechanism are separate layers; the guide to what a crypto casino is covers that split in more depth.

Crypto Casino RNG vs Provably Fair

“Provably fair” and “certified RNG” answer different questions. A random number generator produces the values behind each round; certification is about the statistical quality of that generation. The UK Gambling Commission’s RTS 7, for example, requires outcomes in its regulated market to be acceptably random, unpredictable and conforming to theoretical probabilities, demonstrated through statistical analysis — regulator-level testing of the generator, not per-round disclosure. Provably fair instead gives the player a way to reproduce individual rounds. The two approaches can coexist, and neither makes the other redundant.

Ordinary RNG-based casinos should not be called opaque or dishonest by default — their fairness case rests on testing and regulation rather than on per-round disclosure, which is a different route to a similar goal.

How Blockchain Is Used for Provably Fair Gaming

Blockchain is not required for the scheme described above. The commitment, the game and the verification all run off-chain, on the operator’s servers — which is how most provably fair casinos work today.

Where blockchains genuinely add something is in making parts of the process publicly computable. Smart-contract games can record a commitment on-chain, import external randomness, or use a verifiable random function — a construction where the random output comes with a cryptographic proof that anyone can check on-chain before the value is used. Chainlink VRF is the documented example: an oracle generates the random value and its proof, and the coordinator contract verifies the proof on-chain before delivering the result. Even then, the verified proof concerns randomness — it is not an audit of the whole game or a guarantee of payouts.

Paying in BTC, ETH or BNB does not by itself put anything on-chain: the transfer record is public, but the round still ran on a server. A recorded transaction makes the movement of funds verifiable, not the game fair.

What to Check in a Provably Fair Casino

The label on the site is the beginning of the check, not the end of it. Before trusting a provably fair claim, look at:

• Per-game documentation. Which algorithm each game uses, with fields and formulas described — not just a general badge on the homepage.
• Commitment before the bet. The hash must be visible before you place a wager, and the disclosed data must stay retrievable after seed rotation.
• A reproducible algorithm. Rules precise enough to recompute the result yourself, including the conversion of random values into game events.
• Published RTP and rules. The paytable and rules for each game, plus the licence and withdrawal terms that govern the money side.

If only part of a library is documented as provably fair, treat the rest as standard RNG games. The games library on this site marks demo availability separately, and fairness details for provider games belong to the provider’s documentation.

Can You Win by Using Provably Fair?

No tool in this scheme improves the odds. A verifier checks the data you already have; it does not remove the house edge, and a favourable RTP figure describes the game’s long-run mathematics, not your next round. Changing the client seed changes which random values your rounds use, but because the outcome is unknown until the inputs are combined, no seed choice can promise a better result. And in a correctly built scheme, the secret server seed cannot be recovered from its hash by “decoding” it — resisting that reversal is exactly what a one-way hash is for. Verification gives you a way to detect manipulation, not a way to beat the game.

Before You Rely on the Label

Keep the commitment hash, your client seed, the nonce and the disclosed data for any round you might want to check, and use the game’s own documentation as the source for formulas. Verify one round end to end once, and the mechanics stop being mysterious. The check covers fairness only — the operator’s terms, licence and your local gambling rules still apply, so set limits before you play and treat the game as paid entertainment.

Frequently Asked Questions