Provably fair is a cryptographic audit method for a defined game implementation. It can show that a committed secret and player input produced a result under a published algorithm; it does not prove game suitability, operator solvency or legal status.
Open the verified play routeBefore play, save the hash of the hidden server seed and the displayed client seed. A server seed revealed only after the result cannot prove that it was committed in advance.
Each bet usually increments a counter. Save game, round ID, nonce and any cursor or round component described by the implementation.
Use the platform’s seed rotation control after the sampled play so the prior server seed becomes visible. Never disclose wallet or account recovery secrets; game seeds are separate.
Apply the stated hash function to the revealed server seed and compare it exactly with the pre-game commitment. A mismatch fails the first verification gate.
Run the published algorithm with the server seed, client seed and nonce. Confirm both the raw random value and the mapping into the visible game result.
| Record | Capture | Decision use |
|---|---|---|
| Server-seed hash | Pre-game commitment | Prevents later seed substitution |
| Client seed | Player-visible input | Adds user-controlled material |
| Nonce | Round counter | Separates successive results |
| Algorithm | Value-to-result mapping | Makes reproduction possible |
A passing sample supports integrity for that recorded round and algorithm. It does not establish the advertised RTP, test every game, or rule out withdrawal and account problems. Preserve the verifier version and calculation so another person can reproduce the same outcome rather than trusting a green tick.
No. Round reproducibility and long-run return configuration answer different questions.
It proves the operator committed to the hidden seed before revealing the result.
Reproduce the documented calculation independently when possible and keep the algorithm version.