How to Verify Provably Fair from Commitment to Outcome

To verify Provably Fair, perform two separate checks: first compare the hash of the revealed data with the commitment hash saved before the bet, then replay the outcome using the provider's exact protocol. A matching hash alone does not confirm the game outcome, payout or complete sequence of actions.

Provably Fair is a mechanism for checking that revealed data matches a prior commitment and repeating the calculation specified by a protocol. It is not a certificate or licence. For the underlying concept, see the Provably Fair introduction; this guide focuses on a repeatable verification procedure.

What order should you follow?

Preserve the evidence first, obtain the revealed old inputs, compare the hash, and only then replay the game outcome.

1. Identify the provider, game and protocol version. The game name alone is insufficient: you need the rules for constructing inputs and converting the generated bytes into an outcome.
2. Save the complete commitment hash and available inputs before the bet. Record the time, round identifier and source. You do not need to place a new wager to test verification.
3. Preserve the inputs for the specific round. These may include the old client seed, nonce, game settings and action history. The current seed pair does not replace the old pair.
4. Complete active games if the provider requires it. Follow its protocol to reveal the retired server seed or other committed data.
5. Verify the commitment hash. Hash precisely the data specified in the documentation, using the specified method.
6. Replay the outcome and check settlement separately. Use the complete inputs, exact mapping and action history.
7. Record the scope of your conclusion. For example: “The hash matches; the outcome has not been replayed because the dealing history is missing.”

Hashing is not encryption: revealing a server seed is not “decrypting the hash.” SHA-256 is a hash function described in the NIST standard.

What evidence should you save?

Save complete strings and the old round's inputs, not just a screenshot of a green verdict. Both the content and the time at which it was recorded matter.

Without a pre-bet record, a current match cannot retrospectively prove when the commitment hash was shown. It establishes only that the two values available now correspond.

A nonce is a provider-defined counter. It is not necessarily a round ID, a byte-stream cursor or an HMAC block counter. See the client seed and server seed guide for the distinction between gaming inputs.

How do you use the provider's own verifier?

Follow the documented route for the specific service. Shuffle's route is to complete active games, rotate the seed pair, return to the old bet and verify it with the old inputs.

The Shuffle verification instructions describe this sequence:

1. Complete active games.
2. Open the seed-management interface and use its seed-pair change control.
3. Return to the old bet in your history.
4. Open its verification view and use the revealed old server seed, old client seed and nonce.

Do not substitute the new pair or make a deposit or new wager to perform this check. These steps summarize the documented route, not an account test. If the interface differs, ask the provider for its current procedure; an interface difference alone is not evidence of fraud.

Protocols can differ fundamentally. BGaming, for example, describes per-round commitments containing a result and secret. Its Next Game and Last Game interface labels refer to the next and previous game respectively. That process cannot automatically be replaced with another provider's seed-rotation procedure.

How can you repeat the public BGaming example?

Compute SHA-256 of the complete payload string, not just its number or secret, then compare the digest with the published value.

The BGaming page provides a published educational roulette example. It is not our wager or a historical round we tested.

Official BGaming source fragment showing the payload paragraph for its published roulette example

The official source fragment is in English and shows the example's payload paragraph.

Use this exact compact ASCII JSON string:

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

Its complete SHA-256 digest is:

f88e5c0943740b0269b21347fa26c59b1717ee200584ac40e1c56edd49ad82b8

The source page uses smart quotes. The compact representation above uses ordinary ASCII quotes and reproduces the published digest. Do not normalize your own exported round data: verification requires the exact payload serialization, including spaces, field order and UTF-8 encoding.

Here, server contains the source result 2, not a server seed. Separately, the provider's worked example gives a client value of 5 and a final result of 7: 2 + 5 = 7 in this example. It demonstrates no boundary or wrapping case, so it does not establish a general modulo or boundary rule. No rounding is needed for this supplied integer example.

How do you enter the example in ToolsGambling?

In the Provably Fair tool, enter the expected digest and full JSON payload. This use of the tool checks only the string's SHA-256 hash.

1. Paste the complete expected digest into SERVER SEED HASH.
2. Paste the entire JSON string into SERVER SEED. Here this field serves as a generic SHA-256 text input; the BGaming payload is not a standalone server seed.
3. Leave CLIENT SEED blank.
4. Set NONCE to 0.
5. Click VERIFY HASH.

ToolsGambling inputs with the BGaming expected hash, complete payload, blank client seed and nonce set to 0

The tool screenshots in this guide are actual captures of the local localhost build, not production-site captures or tests of an account or real wager.

ToolsGambling result showing matching full hashes for the published BGaming payload

The green verdict indicates a hash match only. Even if the interface describes the game as fair, this check establishes only that the entered string matches the expected digest.

The tool does not calculate BGaming's final result of 7 in this check. Any derived game values displayed alongside it are educational tool calculations, not automatic validation of the provider's outcome. The source's transformation of 2 and 5 into 7 remains a separate part of its example.

How can you check the payload independently?

Use Node.js's built-in crypto module to calculate SHA-256. With Node.js already available, no additional packages, dependency installation or secrets are required.

Save this code as verify-bgaming.cjs:

const { createHash } = require('node:crypto');

const payload = '{"server":2,"game":"AmericanRoulette","secret":"290fb3c9fbfc2afa5339bf27e5c25cbb"}';
const expected = 'f88e5c0943740b0269b21347fa26c59b1717ee200584ac40e1c56edd49ad82b8';
const computed = createHash('sha256').update(payload, 'utf8').digest('hex');

console.log(computed);
console.log(computed === expected);

Run it from the directory containing that file:

node verify-bgaming.cjs

It prints the complete digest above followed by true. The code checks only the public example's commitment hash; it does not replay the game or calculate a payout.

Never enter a wallet recovery phrase into a verifier. A gaming seed and a wallet recovery phrase are different kinds of data.

Why does result replay require the exact protocol?

Matching input names do not imply matching calculations. Result replay requires the exact key, message, algorithm and game-specific conversion.

For example, the Stake implementation generates a byte stream using HMAC-SHA256:

• The key is the server seed.
• The UTF-8 message is:

  ${clientSeed}:${nonce}:${currentRound}
  

• currentRound is the HMAC block counter, calculated as Math.floor(cursor / 32).
• cursor is the byte-stream cursor, not the nonce.

The third message component must not be omitted. This describes the documented format; it is not verification of a historical bet.

The Stake conversion documentation forms a fraction from four bytes by summing byte[i] / 256^(i+1) for i from 0 to 3. The subsequent mapping depends on the game. This step is not a universal roulette, Dice or Crash algorithm.

Verification also does not prove that a server could not calculate an outcome after receiving all necessary inputs. Its narrower purpose is to check the saved commitment and repeat the documented calculation.

What do the embedded checkers confirm?

The verifier below supports SHA-256 commitment verification and an educational HMAC calculation, not complete provider outcome validation. Its green verdict is controlled by the hash match.

Its educational HMAC message uses client:nonce, with a choice of HMAC-SHA256 or HMAC-SHA512. That is not the complete Stake format described above. Its Dice and Crash outputs demonstrate conversions; they do not confirm outcomes from Aviator, Stake or another provider. A universal-sounding widget title does not extend that scope.

The blackjack checker below also has an educational scope: it checks SHA-256 and demonstrates a partial single-deck calculation using HMAC-SHA512.

Its green verdict likewise means a hash match only. It does not validate a real provider's complete shoe, every player action or settlement. Replaying a real hand requires the deck model, card mapping, dealing rules and complete action history.

What additional inputs do different games require?

The required inputs depend on the specific game and protocol version. A seed pair and nonce alone may be insufficient.

Do not apply one game's formula across a provider's entire catalogue. If the necessary mapping is undocumented, record the outcome as not replayed rather than fitting a formula to the known answer.

What should you do when a hash or outcome differs?

Check the old inputs and exact string first. A mismatch requires diagnosis, but does not by itself prove fraud.

Input strings are case-sensitive: changing a letter can change the digest. Letter case in a displayed hexadecimal digest may be ignored. The main ToolsGambling tool also ignores outer spaces in the expected hash, but not changes to the payload being hashed.

How can one space produce a mismatch?

Add exactly one ASCII space after the first comma in the public example. The JSON meaning remains the same, but the string's bytes and digest change.

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

Its complete SHA-256 digest is:

64711caedf7f2156f8504bcd7f0087ec1233d98f6246892b7d854802dc050a6e

To repeat this in the Node.js example, replace only payload with the modified string and leave expected unchanged. Run the same command: it prints the new digest and false.

In the tool, retain the original expected hash, replace only the string in SERVER SEED, and click VERIFY HASH again.

Hash mismatch after adding one ASCII space after the first comma in the BGaming payload

The additional space changes the payload bytes and hash. The original compact example matches the published digest; the space-added variant does not.

How should you document an unresolved discrepancy?

Preserve reproducible evidence and request the missing protocol or export. Do not create more wagers to debug the problem.

Save:

• The old commitment hash, recording time and round ID.
• The exact revealed-data export, old client seed and nonce.
• Additional parameters, settings and action history.
• Calculation documentation or source code with its version.
• Expected and computed hashes, plus recorded and replayed outcomes.
• Screenshots of the inputs and discrepancy.

Redact sensitive identifiers and account details in shared copies while keeping an unchanged original for your own checks. If the reveal is missing or a mismatch remains unresolved, the appropriate status is unverified. Ask support for the exact protocol, exported inputs and their connection to the saved commitment. This procedure implies no universal response deadline or guaranteed withdrawal.

One matching hash or a selected history check does not prove the fairness of an entire casino. A reproducible outcome also does not establish payout, licensing, RTP—the theoretical return to players—or the absence of biased seed selection. See the comparison of Provably Fair and certified RNG for the difference in scope.

Verification does not change RTP, and changing a client seed does not improve it. An educational HMAC output is not a prediction of future play. The useful conclusion is a precise statement about preserved inputs and a calculation, not a promise of winnings or an “unhackable” system.