RNG certification and provably fair verification answer different trust questions. Certification asks whether a defined game build and its random-number process meet a testing standard. Provably fair verification asks whether one disclosed result can be recomputed from inputs that were committed before the bet.
The distinction builds on FairDealer's guide to RNG, live and hybrid outcomes and its explanation of RTP, house edge and volatility. Randomness determines an outcome route, while the paytable determines its value. Neither a laboratory report nor a matching cryptographic calculation changes the game's house edge or promises a win.
The outcome still travels through several layers
A software game does not usually display the raw number produced by its RNG. The system generates data, scales it to the range a game needs, maps it to cards, reel positions or another event, and applies the rules and paytable. Fairness can fail at any of those layers. An RNG may produce sound data while a faulty mapping creates bias, or the correct game may be replaced by a different build after testing.
The UK Gambling Commission's RTS 7 therefore addresses both RNG output and game outcomes. It expects distributions to match theoretical probabilities, future output to be computationally unpredictable without the algorithm and seed, streams not to repeat or synchronize, seeding not to introduce predictability, and scaling to preserve the required qualities.
This scope is wider than checking whether a short sample looks mixed. A few varied results can come from a weak generator, and an excellent generator can be connected to incorrect game logic. Evidence has to follow the complete route used in production.
Certification is tied to a tested build
Independent certification begins with a defined scope. The Commission's testing strategy assigns pre-release RNG analysis to approved test houses and also calls for examination of game mathematics, source code, scaling, mapping and play against the rules where applicable.
The GLI-19 interactive gaming standard describes source-code review of the randomness, scaling and shuffling functions, looking for bias, implementation errors, malicious code and behavior that could corrupt the final selection. It also describes statistical tests and requires a gaming-platform RNG to be cryptographically strong against an informed attacker with modern resources.
Statistics are one part of the conclusion, not the whole certificate. The GLI submission requirements divide RNG analysis into source-code review, statistical data analysis and software verification. They explain that the conclusion applies only to the RNG identified through that verification. Key files and signatures are recorded so the tested software can be distinguished from another version.
That limitation matters to players. A certificate should identify the product, version, jurisdiction or standard, test laboratory, issue date and scope. A badge without a report reference does not show which build was examined. Material changes to the generator, platform, hardware or use outside the original scope can require further review.
Provably fair uses a commitment and a reveal
Provably fair is a family of cryptographic verification schemes rather than one universal casino standard. A common design starts with a secret server seed. Before play, the operator publishes a cryptographic hash that commits to that seed without revealing it. A client seed supplied or editable by the player and a nonce for the bet are combined with the server input. After the server seed is rotated and revealed, the player can check its hash and recalculate the same output.
One current published example is Stake's implementation documentation. It states that its verifiable bets use a server seed, client seed, nonce and cursor with HMAC-SHA256 to generate bytes. The pre-bet server-seed hash is later checked against the revealed seed, while the nonce changes with each bet. This is an example of one operator's method, not a claim that every product labelled provably fair uses the same encoding or conversion.
The underlying HMAC construction is a standard cryptographic tool. NIST FIPS 198-1 describes HMAC as a keyed message-authentication mechanism built from a cryptographic hash function. In a game scheme, using a recognized primitive is only the beginning. The exact byte encoding, order of inputs, cursor behavior, rejection rules and conversion from bytes to a game event must also be public and reproducible.
A player verifies a transcript, not a slogan
Useful verification starts before the bet. The player needs the committed server-seed hash, the client seed, the nonce and the exact game version. After the operator reveals the old server seed, the player hashes it and checks that it matches the earlier commitment. The published algorithm is then run with the same inputs, and its bytes are converted under the game's documented rule. The recalculated event should match the recorded result.
A calculator provided by the operator is convenient, but it is not independent evidence by itself. Open code or a separate verifier allows the same inputs to be tested without relying on the interface that displayed the bet. A mismatch can come from a changed seed, wrong nonce, different encoding, an undocumented cursor, a conversion rule or a transcription error. The original history should be preserved before investigating.
The hash comparison shows that the revealed server seed is the one committed earlier, assuming the hash function and displayed commitment are genuine. The recomputation shows that the published transformation produces the recorded result from those inputs. Those are precise and valuable checks.
What provably fair does not prove by itself
A matching calculation does not automatically establish that the server seed was generated with adequate entropy, that every bet used the displayed path, or that the front end never substituted data. It does not inspect account balances, withdrawal handling, access controls, game-change procedures or the operator's legal status. It also does not establish that a paytable offers a favourable expectation.
The operator's own overview describes the goal as allowing results to be verified through a commitment scheme and cryptographic hashing. That describes the transcript check, but broader assurance still depends on implementation, deployment and operational controls. The word provable should always be read together with the exact proposition being proved.
A scheme may also be technically reproducible while presenting probabilities poorly. If the conversion from bytes to an event introduces modulo bias, silently discards values or differs from the displayed rules, reproducibility alone will faithfully reproduce the same flaw. Public conversion code helps reviewers examine that layer, while a certification review can test it against probability and disclosure requirements.
The two methods can complement each other
Certification gives a specialist and regulator-facing view of a scoped product. It can inspect source code, statistical behavior, game mathematics, version identity and wider platform controls that an ordinary player cannot access. Its weakness for day-to-day transparency is that the player usually cannot reproduce the laboratory's complete review for a particular bet.
Provably fair verification gives a narrow player-facing check for a particular disclosed transcript. It can make post-bet seed substitution or an inconsistent calculation detectable when the scheme is complete and correctly used. Its weakness is scope. It sees the published proof path, not every operational and regulatory property around the game.
The strongest reading is not that one label replaces the other. A player should identify the exact certified version, confirm that the test house and report are real, read the provably-fair algorithm and conversion, save the pre-bet commitment, and verify a completed seed cycle with independent code where practical. If essential inputs or the reveal are unavailable, the advertised proof cannot be completed.
Neither method predicts the next outcome. Certification supports confidence in a tested system, and cryptographic verification can expose inconsistency in a recorded calculation. They are tools for checking process, not systems for overcoming probability or recovering losses.
