Provably Fair Gambling: How Verification Works and Its Limits

Provably Fair is a way to verify a completed game through cryptographic commitment, later disclosure, and result replay under a documented protocol. You can check whether revealed data matches a commitment hash saved before the bet and, with the exact algorithm, whether the calculated outcome matches the recorded result. It does not guarantee profit, withdrawals, or an operator’s overall fairness.

Its main benefit is the ability to test a specific claim about a specific round instead of relying on a “fair game” badge. The strength of that evidence depends on what you saved, when you received the hash, and whether the relevant algorithm version is available.

What does Provably Fair verification prove?

Commitment verification checks whether revealed data matches an earlier saved hash; result replay checks which outcome those inputs produce under the game’s rules. These are two distinct levels of verification.

At the first level, you hash the revealed input and compare it with the commitment hash. Under the relevant cryptographic assumptions, a match supports the claim that the disclosed data is the data previously committed to. A hash obtained only after the bet, however, does not establish that the commitment existed beforehand.

At the second level, you need every required input and the exact algorithm: how numbers are generated, how they map to a game outcome, and sometimes the player’s action history. A hash match alone confirms neither the winning number nor the payout.

A hash is not encrypted data. SHA-256 produces a fixed-length digest from a message; revealing that message is not decryption. The underlying hash standard is FIPS 180-4.

Which inputs and terms matter?

The required inputs depend on the protocol. A server seed, client seed, and nonce are common, but not every implementation needs all three.

RFC 2104 describes HMAC as a cryptographic construction, not the rules of any particular casino game.

Where the protocol allows it, choose your client seed after receiving the server commitment hash. The order matters: an operator that knows the required inputs can calculate the results. Outcomes are therefore not necessarily unpredictable to the operator. For more on these roles, see client seed vs server seed.

How do you save and verify a completed round?

Start with the specific game’s official fairness rules and save its commitment hash before betting. You can verify an existing historical round without placing another bet if the necessary records are already available.

1. Open the official verification rules. Find the algorithm, protocol version, input scheme, and disclosure schedule. A Provably Fair badge is not enough.
2. Save the commitment hash before the bet. Also save the rules version and input scheme. Retain evidence that the hash was available before play.
3. Choose a client seed where supported. Use the game’s client seed control after receiving the server commitment, if the protocol permits that order.
4. Save the round record. Record the round ID, available seeds, nonce, and outcome. Depending on the game, also retain the byte-stream cursor and player actions.
5. Wait for the documented disclosure. This may happen after a round or after server seed rotation. Do not assume that every bet is followed by a seed reveal.
6. Verify the commitment. Hash the exact data in the representation required by the rules.
7. Replay the result. Use the precise algorithm and the mapping for the selected game.
8. Compare the outcome and payout separately. Matching the outcome does not replace checking the payout table and the amount actually credited.

Without the necessary data or algorithm version, full verification remains unavailable. The step-by-step Provably Fair verification guide covers the procedure in more depth.

Why can’t you mix different providers’ protocols?

Different protocols commit to different data and convert it into outcomes in different ways. Entering seeds into a single generic algorithm is not a substitute for following the specific game’s documentation.

Stake’s implementation documentation describes 32-byte blocks and server seed disclosure after rotation. Its conversion documentation separately explains fractions derived from four bytes and game-specific conversions. These are descriptions of the documented protocol, not evidence that we verified an actual Stake round.

BGaming’s documentation describes the different approach illustrated below. That example should not be treated as proof about every BGaming product.

Dice, crash, mines, card games, and slots each need their own mapping from inputs to outcomes. A shared technology label—or the presence of a nonce—does not make those mappings interchangeable.

A published BGaming example: checking the full hash

You can reproduce the SHA-256 digest of BGaming’s published roulette payload and compare the entire hash. This is a public educational example, not our wager or an audit of an actual historical round.

The official BGaming page provides the roulette example’s data and explains the subsequent result transformation.

BGaming’s published roulette example showing the Result + Secret JSON payload

The official source image remains in its original English. The two English tool screenshots below were captured on localhost: they show input and hash comparison, not verification on the production site or proof of an actual wager.

The exact compact payload is:

{"server":2,"game":"AmericanRoulette","secret":"290fb3c9fbfc2afa5339bf27e5c25cbb"}

The published full hash is:

f88e5c0943740b0269b21347fa26c59b1717ee200584ac40e1c56edd49ad82b8

Here, server contains the original server result, 2; game identifies the game; and secret contains the secret string. The hash commits to the entire payload, not just one of these values.

This compact string was independently checked in Node.js and a browser: its SHA-256 digest matches the published hash in full. The source page uses typographic quotation marks and line breaks in its presentation. The ASCII-quoted compact string above is confirmed for this published example only. It is not permission to normalize your own round exports, which must preserve the exact original bytes.

How to enter the example in the ToolsGambling verifier

Paste the full hash into SERVER SEED HASH and the entire payload into SERVER SEED. Leave CLIENT SEED empty and NONCE at 0.

Open the Provably Fair verification tool and fill in these controls:

English verifier inputs with the full commitment hash, the BGaming payload, an empty client seed, and nonce 0

The entire committed payload goes into SERVER SEED, not just the value of secret.

Click VERIFY HASH. Compare the computed and provided hashes in full, from the first character to the last.

English verifier result showing matching computed and provided SHA-256 hashes

The green GAME IS FAIR banner means only that the hashes match in this implementation. It is not certification of the game or operator.

The tool hashes the entered UTF-8 string with SHA-256. This check does not calculate BGaming’s final result, and the tool does not universally replay Stake or other providers’ games. Do not use its built-in illustrative game-number calculation as the verification algorithm for this example.

Exact bytes matter: adding one space after the first comma produces a different hash. For the example above, copy the payload without adding spaces, typographic quotes, or a trailing newline. For your own round data, follow the provider’s export rules rather than “correcting” the string yourself.

Where does the example’s result of 7 come from?

BGaming’s documentation applies the client value 5 to the original server result 2, producing 2 + 5 = 7 in the published example.

This is a separate stage from commitment verification. You can compare it with the provider’s published example, but our tool does not calculate that stage.

One example does not establish a general formula for all values or roulette variants. No range-wrapping edge case is verified here, so there is no basis for inventing a modulo rule.

How does Provably Fair compare with an RNG audit or live dealer stream?

Provably Fair lets you check committed data and, with a complete protocol, replay a specific outcome. An independent RNG audit and a live dealer stream provide different kinds of evidence; neither replaces that procedure.

Provably Fair and RNG are not mutually exclusive. A random number generator can be part of a system whose data and outcomes can subsequently be verified.

As an example of randomness requirements, UKGC RTS 7 addresses the quality and mapping of random outcomes. The standard is not a certificate for a particular operator or evidence that every game complies. Such a conclusion requires a relevant report and a review of its scope. See Provably Fair vs RNG certification for a fuller comparison.

Even successful result replay does not, without additional assumptions, prove unbiased seed selection, that all deployed code matches the published implementation, or that every payout mapping and RTP claim is correct. It also says nothing about the operator’s financial strength, licence, legal status in your jurisdiction, or ability to process withdrawals.

Why doesn’t a verifiable outcome guarantee profit?

Verifiable calculations do not remove the house edge. RTP—the theoretical return to player—depends on probabilities and payouts, not on whether you can replay an outcome.

Consider a conditional model with a stake of 1, a 50% win probability, a gross payout of 1.98 on a win, and 0 on a loss. The gross payout includes the returned stake.

The expected gross return per unit staked is 0.5 × 1.98 = 0.99. That gives this model a 99% RTP and a 1% house edge. Across total turnover of 1000, the expected gross return is 990 and the expected net result is −10.

These are expected values for an assumed model, not a named game’s RTP or a forecast of your session. Actual results can vary, and fees are excluded. The calculation uses the stated values without intermediate rounding. A 50% win probability does not mean 50% RTP: payout size matters.

With the same stake and win probability, a gross payout of 2 would give this model a zero house edge. Whether an outcome is verifiable and whether the payout offers fair odds are separate questions; neither guarantees a profitable session.

What should you do if verification does not match?

A mismatch calls for checking the data and algorithm before alleging fraud. An error may occur before the game-specific conversion even begins.

Check the following:

• Are you using the revealed server seed from the correct historical seed pair, rather than the current active seed?
• Was the commitment hash saved before the bet?
• Do encoding, spaces, line breaks, quotation marks, and field order match?
• Should a hexadecimal string be hashed as text, or decoded into bytes first?
• Have you confused the nonce with the round ID?
• Are the byte-stream cursor, HMAC block counter, and protocol version correct?
• Do the client seed and other input values match?
• Have you used the right game mapping, rounding rules, and action history?

If the hash matches but the outcome does not, check the conversion from input data to the game result separately. Commitment verification does not establish that you selected the correct game algorithm.

Without round history, revealed data, or the required rules version, a full check is not possible. Preserve the original inputs, commitment hash, round details, and comparison result, then contact official support. Pause real-money betting while the discrepancy remains unexplained. A satisfactory resolution is not guaranteed.

Can the hash predict the next result?

A public hash and past outcomes should not reveal the next active outcome when strong cryptographic primitives are used and the required secrets remain secret. That is a conditional security claim, not a promise that the entire system is unhackable.

Leaks, implementation flaws, and failures in commitment timing cannot be ruled out by the Provably Fair label. An operator that has all required inputs can perform the calculation, so claiming unpredictability for every participant would be incorrect.

Changing a client seed does not increase RTP or turn verification into a method for finding winning bets. The practical value of Provably Fair is saving evidence at the right time, checking completed rounds against exact rules, and understanding what the resulting proof leaves unanswered.