The four terms you need
| Term | Meaning |
|---|---|
| Server seed | A secret value used by the operator in the result calculation, revealed later under the system’s rules |
| Server-seed hash | A cryptographic commitment published before play; the revealed seed should reproduce this hash |
| Client seed | A value supplied or accepted by the player that contributes to the calculation |
| Nonce | A counter or other identifier that distinguishes successive games using the same seed pair |
Implementations differ. Some use additional inputs, multiple draws or a different commitment structure. The published algorithm—not the badge on the homepage—defines what can be verified.
How verification works, step by step
1. Record the commitment before the game
Save the server-seed hash, your client seed, the game identifier and the applicable rules. The commitment matters because it lets you detect whether the revealed server seed differs from the one committed before play.
A hash supplied only after the outcome is known does not establish that prior commitment.
2. Keep the result and nonce
Save the recorded roll, nonce and outcome. For case openings, retain the item-probability table or version used for that opening. A valid random number is only part of the process: its mapping to a particular item also matters.
3. Wait for the server seed to be revealed
Many services reveal a seed after it is retired through a seed rotation. Do not expect to verify an active secret seed before its disclosure. Follow the documented process rather than sharing account credentials with a third-party verifier.
4. Recalculate the commitment and outcome
Hash the revealed server seed using the documented method. It should match the saved commitment exactly. Then run the published result algorithm with the correct inputs, ordering, encoding and nonce.
Some implementations use HMAC-SHA256, but that name alone is not an executable specification. You also need the exact message format and the conversion from output bytes to a game result.
5. Compare the item mapping
Confirm that the reproduced roll falls in the interval assigned to the displayed item under the rules recorded for that game. A matching seed hash does not prove that the item-probability mapping was applied correctly.
A worked example of the last step
Suppose a fictional case converts its result into one of 10,000 equally likely integers, numbered 0 through 9,999:
| Integers | Number of outcomes | Probability | Item tier |
|---|---|---|---|
| 0–7,999 | 8,000 | 80% | Common |
| 8,000–9,799 | 1,800 | 18% | Uncommon |
| 9,800–9,999 | 200 | 2% | Rare |
If the documented calculation reproduces 9,850, the recorded outcome should belong to the rare tier. If the site displayed a common item instead, the mapping would not match these rules.
This example explains probability intervals, not a real operator’s algorithm. Generating uniformly distributed integers also requires a correct conversion method; careless rounding or modulo conversion can introduce bias.
Why a verified result can still lose money
Fair verification and favorable odds are different things. Imagine a fictional opening priced at $10 with an average item value of $9.20 under its probability table. Its modeled return is 92%, leaving an 8% house edge on that valuation basis.
A correctly implemented verification system can faithfully produce those unfavorable odds. The result is verifiable; the average return is still below the price.
That 8% is not a guaranteed loss on each opening or a forecast for your next session. Actual results vary, and displayed item values may differ from obtainable sale proceeds.
What “provably fair” does not establish
- Withdrawal reliability: reproducing a roll does not demonstrate that a promised item will be delivered.
- Solvency or account treatment: a result calculation says nothing about the operator’s ability to meet obligations.
- Legal eligibility: verification does not establish permission to gamble in your location.
- Complete implementation security: seed generation, commitment timing and the mapping algorithm still need scrutiny.
A practical review separates result verification, published probabilities, withdrawal terms and player-protection controls. None substitutes for all the others.
If your verification does not match
First confirm the seed pair, nonce, algorithm version and input formatting. A mismatch can come from a copying error or incorrect verifier as well as a faulty implementation. Preserve the inputs and screenshots, ask support for an explanation and pause further play while the discrepancy remains unresolved.
Frequently asked questions
Does provably fair mean there is no house edge?
No. A verifiable result can still come from a game whose average payout is lower than its entry cost.
Can I verify a result before the server seed is revealed?
Usually not in the common commit-and-reveal model described here. You can save the commitment before play, but reproducing the result requires the revealed seed and the documented inputs.
Does changing my client seed guarantee better outcomes?
No. Changing a seed is not a strategy for improving the published probabilities of a correctly implemented random game.
Set limits before playing and never chase losses. For confidential support and help options, visit Gambling Therapy.