Provably fair explained: How to verify a crypto game yourself

After you play a round, provably fair gives you a cryptographic way to check how its result was generated. The necessary verification data and the algorithm used must be accessible. You check whether the displayed result can actually be calculated from the committed inputs.

This check has clear limits: a verifiable result tells you nothing about payout practices, licensing, or your probability of winning. Even a correctly calculated game can have a house edge. We first explain server seeds, client seeds, and nonces, then show you which data to save before walking you through reproducing a completed round.

In brief: With provably fair, the casino commits to a secret server seed through a hash before your round and reveals it later. You then use the server seed, client seed, and nonce to calculate the result yourself.

Provably fair makes certain game results verifiable

Provably fair lets you trace how a particular game result was calculated from fixed inputs. In a common method, you receive a cryptographic verification value before the round; the initially secret data is revealed later. With that data and the documented calculation method, you can reproduce the result yourself.

Commit first, reveal later

Before you place your bet, the operator provides the hash of its secret server seed. This hash serves as a commitment: once the server seed is revealed, you calculate its hash again and compare it with the value you saved earlier. If they match, this supports that the operator used the same seed it committed to beforehand.

A cryptographic hash function is not encryption that you reverse with a key. It turns an input into a fixed-length verification value. With suitable methods and sufficiently unpredictable seeds, deriving the secret seed from that value is practically infeasible.

How this differs from an ordinary random number generator

An ordinary random number generator might produce a number between 0 and 99. That number alone does not let you reproduce how it was generated. Provably fair adds a verifiable process, but it does not automatically prove that the seeds were actually chosen randomly.

A blockchain is not required: hash comparisons and result calculations can take place off-chain. A Bitcoin deposit does not provide proof of a game's fairness, either. Payment methods and result verification are separate topics; learn the technical basics of payments in Understanding crypto payments.

Server seed, client seed, and nonce form the foundation

To verify a round, you need its inputs and the exact calculation instructions. The server seed, client seed, and nonce work together to supply the starting data from which the game algorithm calculates a result, such as a dice value.

Which inputs you need for verification

The server seed is an initially secret input supplied by the operator. Before playing, you usually receive only its hash as a digital commitment; you need the revealed seed later to verify it.

Tip: Set your client seed only after saving the server seed hash. The operator then cannot tailor its seed to your already known input.

The nonce separates consecutive rounds that otherwise use the same seeds. It does not have to start at 0 or increase according to the same pattern everywhere: what matters is the counting method documented for that game.

How hashes, HMAC, and the game algorithm work together

A hash maps an input to a verification value, allowing you to check the original commitment. HMAC, by contrast, is a keyed cryptographic function that processes a key and a message. HMAC-SHA256 is one possible method, not a universal standard for every game.

The key assignment, input order, separators, and character encoding, such as UTF-8, all matter. The same visible text can produce different bytes, and therefore a different result, if processed differently.

The game algorithm then converts the output into a result, such as a value between 0 and 9,999. You also need to reproduce this conversion: a matching server seed hash alone does not confirm the displayed game result.

Save the verification data before your first round

Without the server seed hash saved before the round, you cannot use your own records to check whether the operator committed to the corresponding server seed in time. This hash is the commitment: it binds the operator to an initially secret value. Save it before playing, for example as both a screenshot and copyable text.

What to include in your records

Create a record with the following details for each round you want to verify. You need this data to check not just the hash but also how the displayed result was calculated:

• Game and version or ruleset: Which game rules and result calculation apply?
• Round ID: The unique identifier of the completed round.
• Server seed hash: The commitment saved beforehand.
• Client seed: The value actually used for this round.
• Nonce: The counter value used in the calculation.
• Bet and displayed result: Include the unit, such as USDT.
• Documented verification algorithm: Save the description, including the input format and conversion into the game result.

Follow this order: save the commitment first, then change the client seed if needed and record its final value. After the round, add the round ID, nonce, bet, and result; check the old server seed only after it has been revealed.

Understanding seed changes and disclosure

Find out beforehand where and when the server seed used will be revealed. This may happen only after a seed rotation: a new secret seed takes over for future rounds, while the old one can be revealed for past rounds. Whether the nonce resets or continues in another way depends on the implementation.

Warning: A game seed is not a wallet seed phrase. Never enter a seed phrase or private key into a game verifier. You need neither a deposit nor wallet credentials to check the calculation.

Verify a completed round in six steps

For a complete check, you need the server seed hash saved before the round, the round data, and the server seed revealed later. While that seed remains secret, you cannot fully reproduce the calculation. An operator's verification screen can help you get started, but an independently run verifier with code you can inspect provides a stronger cross-check.

Check the commitment first, then the result

1. Match your saved data to the correct round. Have the round ID, original server seed hash, client seed, nonce, and recorded game result ready. Include additional inputs if the method requires them. The key is the hash you saved before the round: a value displayed only afterward does not prove that prior commitment.

2. Check the revealed server seed against the commitment. Process it using the documented hash function and specified encoding. Then compare the entire calculated hash with your saved value, not just its beginning and end. If they match, the revealed seed matches the prior commitment; the game result has not yet been verified.

3. Copy every input exactly. Copy the client seed, nonce, and any other values without changes. Even an extra space or an uppercase letter instead of a lowercase letter can produce a different result. Also pay attention to character encoding and number format: the text string “01,” for example, is not the same input as “1.”

4. Run the documented cryptographic calculation. If the method uses HMAC, the key and message must be in their specified positions. Separators and input order are also part of the specification. Joining the server seed, client seed, and nonce together however you choose is not a substitute for this calculation.

5. Convert the calculated value into the game result. Use the published conversion method, such as the conversion into a dice number or card sequence. Check rounding rules and indexing: does counting start at 0 or 1? If the game needs multiple random values or additional draws, you must reproduce all of those steps as well.

6. Compare the result and document your findings. Compare your calculated result with the recorded round result, and save the inputs, algorithm version, and verification output. A match confirms the calculation you reproduced for that round. It proves neither that every other round is correct nor that payouts are reliable.

Narrow down discrepancies systematically

If you find a mismatch, first check the round assignment, nonce, encoding, and algorithm version. An outdated conversion rule can produce a different result just as a copying error can. A discrepancy is therefore not automatically proof of fraud.

If the mismatch persists, save the original data and contact support with the round ID, expected output, and your calculation. You can pause further betting until it is resolved. If only the operator's own interface says “verified,” that is not an independent cross-check - even if you open it in a second browser window.

A worked example shows the conversion into a game result

A matching seed hash alone is not enough to verify a game result: the conversion of the cryptographic output must also be correct. Here we use an explicitly educational example unrelated to any operator. We assume the number 173 is a byte from a cryptographic output; it is not an HMAC actually calculated from specific seeds here.

Turning one byte into a number from 0 to 99

A byte can have 256 different values, from 0 to 255. Our example game, however, should produce exactly 100 possible results: the numbers 0 to 99. To make them equally likely, the example method accepts only byte values from 0 to 199.

Values from 200 to 255 are rejected. The algorithm then uses the next value according to a predefined rule and checks again whether it falls within the allowed range. This method is called “rejection sampling”: unsuitable values are discarded rather than assigned to a game result.

For an accepted value, we calculate the remainder after division by 100. Specifically: 173 mod 100 = 73, because 173 divided by 100 is 1 with a remainder of 73. The example result is therefore 73.

Among the 200 accepted values, each remainder from 0 to 99 occurs exactly twice. For the result 73, the starting values are 73 and 173; for the result 0, they are 0 and 100. Provided the source bytes are uniformly distributed, the 100 game results remain uniformly distributed as well.

Why conversion can bias the result

If we simply applied modulo 100 to all 256 byte values instead, the result would be biased. Results from 0 to 55 would each have three possible starting values; for example, 0 would come from 0, 100, and 200. Results from 56 to 99, by contrast, would have only two.

For your verification, this means you also need to be able to trace which bytes the game uses, which it rejects, and how it produces the result. This conversion must match the documented game. Our example explains the principle but does not replace a game-specific verifier.

Provably fair removes neither the house edge nor the risk of loss

Provably fair makes the calculation of certain game results reproducible; it does not make gambling profitable. If you correctly reproduce a dice round, you have checked its calculation - but you have not established favorable payout rules or the operator's ability to pay.

A correct result can still come from an unfavorable game

An example game costs €10 per round and has a 49% probability of winning. A win returns €20 in total; a loss returns nothing. The €20 total payout already includes your stake, so your net profit on a win is €10.

Mathematically, you receive an average of 98% of your wagers back, even though every result may be correctly verifiable. Over 100 rounds at €10 each, that would mean €1,000 in total wagers and an expected loss of €20. This expected value is not a prediction for an individual session: your actual result can differ substantially.

What verification does not tell you about the operator

Provably fair alone does not verify a license, bonus terms, KYC procedures, or payout practices. It also does not establish solvency or verify the entire process behind the user interface. A correctly calculated round, for example, says nothing about whether or when your balance will be paid out.

Verification also applies only to the specific game and implementation checked. A verifiable dice game does not automatically establish that every slot, live casino game, or sports bet on the same platform can be checked this way.

Regardless of the technical checks, set fixed loss and time limits - for example, no more than €30 in losses and 45 minutes of play - and end the session as soon as you reach either limit. Even after several correctly verified rounds, your chance of recovering previous losses does not automatically increase. We explain how to plan these boundaries in Limits and gambling breaks.

Provably fair games in our reviews

Provably fair is found almost exclusively in in-house games, known as Originals. Slots and live tables from external studios, by contrast, use certified random number generators. In our reviews, these casinos offer verifiable Originals:

Tip: Find an overview organized by features in Provably fair casinos. Before your first bet, check whether the casino displays the server seed hash, client seed, and nonce for each round.

Use this checklist to assess the implementation

A provably fair method is independently verifiable for you only if you can trace the path from the commitment published beforehand to the round result. Five features matter - not the fairness badge beside the game.

Features of a reproducible verification process

• Commitment before the round: The server seed hash is visible and can be saved before play begins. This lets you check later whether the revealed seed matches the prior commitment.
• Traceable inputs: The client seed, nonce, and any additional inputs are clearly assigned to the relevant round.
• Defined disclosure process: The documentation explains when and how you receive the server seed used, such as after a seed change.
• Complete algorithm: The description covers both the cryptographic calculation and the conversion of its output into a dice number, card sequence, or other game outcome.
• Independent reproduction: Your saved data lets you calculate the result outside the built-in verification feature, for example with a script whose operation you can inspect.

Warning signs are not automatic proof of fraud

A fairness badge without a technical explanation is not sufficient evidence. Other warning signs include missing round assignments, an old server seed that remains inaccessible after its scheduled disclosure, or a verification feature that merely reports “fair” without revealing the inputs and calculation.

“Not independently verifiable” does not automatically mean “proven to be manipulated.” Missing information prevents a positive fairness verification for the round in question, but it does not prove fraud on its own. Additional bets will not supply the missing verification data and will only increase your risk of loss.

Check the documentation first, then save the commitment before a round. Afterward, reproduce a round you have already played; you should not sign up or deposit solely to perform this check.