Provably Fair Audits: What a Real Audit Report Should Contain
the author
ProvablySmart Research Desk
date post
Aug 28, 2026
Share
Anyone can display a badge that says “provably fair.” A real provably fair audit report is a different object: a set of claims about deterministic code, seed handling, and data retention, each of which you can independently verify in principle. This article defines what such a report should contain and how to read it critically in 2026.
What a Provably Fair Audit Actually Verifies
Traditional RNG audits test a black-box device for statistical randomness. Provably fair audits test a documented, deterministic process. The audited system must prove that the operator cannot change a result after a bet is placed, and that the player can verify every outcome using public inputs.
Seed lifecycle and commitment scheme
The report should describe the full seed lifecycle. A server generates a secret server seed; only a hash of that seed is published before betting. The player picks a client seed. A nonce increments for each bet. After seed rotation, the server seed is revealed, and a verifier recomputes historical outcomes. If the report does not mention a committed server seed hash per round or per rotation, the system is not provably fair.
Output derivation
A deterministic function maps seeds to outcomes. Most casinos use HMAC-SHA256(server_seed, client_seed:nonce) and then map the digest to game-specific ranges. The report should include exact pseudocode or a link to a reference implementation. If the algorithm is not specified, you cannot verify anything, so the report fails its primary purpose.
Core Sections of a Real Audit Report
A useful report, whether produced by an internal team or a third party, should include the following sections. A lack of any of them should lower your confidence.
| Section | What it should contain | Why it matters |
|---|---|---|
| Scope & assets | Which games, versions, seed rotations, and date ranges are covered | Without scope, a “site-wide certified” claim is vague and unverifiable |
| Methodology | Audit steps, code review, test vectors, replay scripts | Shows that the audit can be repeated by another party |
| Source code or verifier hash | SHA-256 digest of the verifier or a repository commit | Lets you confirm the deployed verifier has not changed |
| Sample verification | Five to ten worked examples with seeds, nonces, and expected outcomes | Enables you to reproduce the derivation yourself |
| Seed rotation logs | Server seed hashes and revealed seeds, with timestamps or block numbers | Provides evidence that the commit-reveal scheme was actually followed |
| Statistical analysis | Simulated RTP, probability checks, confidence intervals | Confirms that the game logic is not just deterministic but also economically sound |
| Limitations & exclusions | What was not tested: live jackpots, side bets, bonus logic | Prevents you from assuming the audit covers more than it does |
| Date, signatures, version | Who performed the audit, for which client version, and when | Determines whether the audit is still relevant |
What to Check Yourself in 2026
Casino operators often provide a web-based verifier. That is a convenience, not an audit. You should also perform a separate baseline check using the seeds and hashes from your own session.
Check the scripts, not the summary
Every report should include a canonical way to verify results without visiting the casino’s web page. Reproduce the algorithm in Python, Node, or any other language using the published seeds. If the report only gives you a web tool, save the tool’s source before and after a session and compare its SHA-256 digest. A report that lacks source code is a sales sheet, not an audit.
Reproduce at least three test vectors
Take the report’s sample outcomes. Run the provided inputs through your own implementation. If they match, you have verified the derivation logic. If they do not match, discard the report. This one step takes less than ten minutes and prevents you from relying on an opaque summary.
Red Flags in Provably Fair Reports
- No server seed hash shown before play
- A client seed that the player cannot set
- No nonce or explicit bet identifier in the derivation
- Algorithm described as “encrypted” rather than deterministic
- RTP results without sample size or confidence interval
- Claims signed by unnamed “experts” or an unverifiable organization
- No date, version, or commit hash for the verifier
- Phrases such as “100% fair” with no mathematical derivation
RTP and Fairness Simulations
An audit report should also include a simulation of the game’s theoretical RTP, computed from the actual game logic, not from a few thousand live rounds. For example, a crash game with a house edge of 1% should have a long-run expected RTP of 99%. A simulation of one million rounds should produce a confidence interval that contains 99%, although variance depends on payout structure. The report should make its simulation code available, so a skeptical reader can reproduce the confidence interval and confirm the rounding behavior.
Conclusion
Read a provably fair audit report as you would read product documentation: check what can be checked, and ignore claims that cannot be tested. We maintain casino reviews with verification checklists for each operator. The guides section explains the underlying arithmetic in more detail. For practical context on how fairness affects volatility and session risk, see our bankroll management material. Updates on verification practices and audit standards appear under news.
FAQ
What is the difference between a provably fair audit and an RNG certificate?
A traditional RNG certificate tests the randomness of a closed system. A provably fair audit examines a deterministic seed-based derivation and a commit-reveal scheme. A real report should include both forms of evidence if the game uses any RNG component.
Can I verify a provably fair result without coding?
Yes, if the casino provides a verifier page and the report shows the exact input fields. However, to be sure the verifier itself is not making up results, you should at least compare game history entries with the seed, nonce, and hash listed in the report. A report that lacks source code or test vectors is not an audit.
How often should a provably fair audit be published?
It should be version-specific and re-run whenever game logic changes. A static report from years ago does not cover a current game. In 2026, look for a report dated for the current client version, and check seed rotation timestamps during your own session.
