Provably Fair and RNG Certificates: How to Check the Evidence

You can personally verify some Provably Fair evidence, while a laboratory certificate adds independent assurance within the scope of its tests. These mechanisms complement each other: neither makes a casino universally safer or guarantees payment.

Start by separating four concepts. A random number generator (RNG) produces random values. Provably Fair is a protocol that lets you check specified relationships between committed inputs and a result. A certificate records the subject and scope of independent testing. An operating licence concerns permission to conduct particular activities in a jurisdiction. Provably Fair can use an RNG and undergo laboratory testing; they are not incompatible alternatives.

The practical question is not which badge looks better. It is what evidence is available for this game and version before you risk money.

What does each mechanism establish?

RNGs, Provably Fair protocols, certificates and licences answer different questions. Compare their scope, timing and evidence rather than assigning generic reliability scores.

Independent testing, issuing a certificate and conducting an ongoing audit are different activities. Read the evidence itself rather than treating all three as “certification”.

What does a laboratory test, and why do post-launch controls matter?

A laboratory can examine RNG code, statistical properties, scaling, game mathematics and the mapping of generated values to game results. Post-launch controls matter because software and settings can change after initial testing.

For example, Great Britain's requirements address acceptable randomness, unpredictability, nonadaptive behaviour and correct scaling. They do not require every prize to have the same probability: prize probabilities depend on the game mathematics. See the UK Gambling Commission's requirements for random outcomes.

Independent testing is required before release in specified circumstances. Testing includes RNG code review, statistical analysis and scaled outputs, with separate checks of game mathematics, theoretical return and outcome mapping. Reports identify software and versions; changes affecting fairness also require testing. See the pre-release testing procedure and detailed testing requirements.

For defined licensees, the British framework includes an annual audit covering a sample of updates, change controls, game lists and live monitoring. This does not mean every RNG is retested annually worldwide. Live return monitoring compares actual and expected results, considering volatility and tolerances; it is not a mechanism for forcing a win in your session. See also the annual audit scope.

Why are statistical tests alone insufficient?

Statistical tests can detect some deviations, but they do not replace analysis of cryptographic security. A plausible distribution of results does not, by itself, establish unpredictability or correctness of the entire game.

Original English NIST passage explaining the limitations of statistical testing

Original English passage from NIST SP 800-22 Rev. 1a, April 2010. The source page carries a 2022 notice that revision was planned. This is historical guidance, not a casino certificate.

The US National Institute of Standards and Technology (NIST) explains that statistical testing is not a substitute for cryptanalysis. That is a general limitation of the method, not an assessment or endorsement of a particular operator.

How do you verify an RNG certificate rather than a badge?

Check the document's origin and whether its scope matches the specific game you intend to play. A laboratory logo without these details is insufficient evidence about the current version.

1. Check the source. Use the laboratory's genuine domain rather than relying solely on a certificate image hosted by an operator.
2. Match the entity and product. The document may name a developer, component or game—not the casino as a whole.
3. Look for the version and code identification. Ask how the tested software corresponds to the version available to you.
4. Read the date, standards and limitations. Distinguish the certificate's issue date from testing dates and editions of referenced standards.
5. Identify what was tested. RNG generation, scaling, game mathematics and return to player (RTP) may have separate scopes.
6. Ask directly if public verification is unavailable. Request confirmation from the laboratory or operator. A missing public search result does not automatically establish forgery.

A useful historical example is the iTech Labs certificate for Igrosoft LLC dated 14 January 2020. It covers an RNG component and slot scaling, states that the certified code was fingerprinted, and limits its conclusions to component testing. It does not display a code fingerprint identifier. Its references include standards dated June 2017 and a Testing Strategy document dated November 2018; the latter is not the date of testing.

This document does not establish an individual game's RTP, today's deployed build or current certificate validity. It is a documentary example of how to read testing scope, not a product recommendation.

Check the operating licence separately. The UK Gambling Commission's public business register illustrates how to check operating permission in Great Britain. An entry does not establish whether you may legally play from another jurisdiction.

How can you personally verify a Provably Fair round?

Full verification requires a commitment saved before play, exact round data, the revealed seed and the algorithm for the relevant version. Commitment verification is only one stage; it does not replace result replay or a settlement check.

Use this sequence:

1. Save the commitment hash and protocol before betting. Record the source, when you obtained it and the documentation version. A hash copied only after play does not establish a prior commitment.
2. Record inputs, settings and history. Save the client seed, nonce—the counter used by the protocol—round identifier, game parameters and any other required data. Implementations do not all use the same inputs.
3. Wait for disclosure of the old server seed. This follows the documented rotation or other end condition, not necessarily each round.
4. Verify the commitment. Use the unchanged revealed string and the protocol's exact payload serialization: the precise representation of data to be hashed.
5. Replay the result. Apply the provider-specific algorithm with the correct version, encoding, settings and history.
6. Check settlement. Compare the result with the rules, paytable and account transaction record.

A hash match alone does not establish that the commitment existed before the bet, that the server seed had sufficient entropy—unpredictability—or that outcome selection was unbiased. Nor does it establish correct mapping, payment or operator honesty.

A fresh, unpredictable client seed can reduce opportunities for preselection if chosen after a binding server commitment and actually honoured by the protocol. That is conditional protection, not a guarantee. For more detail, see the Provably Fair verification guide and the technical explanation of Provably Fair and RNGs.

Practice: verify a seed commitment in your browser

This educational example checks whether the SHA-256 hash of a revealed server seed matches the entered commitment hash. It separately calculates a demonstration hash-based message authentication code (HMAC). It does not compare against a historical casino outcome or perform universal result replay.

The interface title “Universal Provably Fair Verifier”, its green verdict and its brand hints do not expand that scope. The algorithm selector changes only the HMAC calculation; commitment verification always uses SHA-256.

Which values should you enter?

Enter the four educational values below, select “HMAC-SHA256” and click “Verify Round”. These are public demonstration inputs, not real wagers or evidence about a casino.

In “HMAC ALGORITHM”, select “HMAC-SHA256”. SHA-256 is a hashing algorithm; HMAC-SHA256 uses it to calculate a keyed authentication code.

Four educational input fields with HMAC-SHA256 selected in the English tool

Actual screenshot from a local educational run, not a casino verification. The commitment hash field visibly clips part of the string.

Here is the full commitment hash for copying:

af44fbb9b3710c9bb38aec8a7ac0b25140f34033376c7bb894626d34cfa5a026

The revealed server seed is processed as a literal, unchanged UTF-8 string. Do not trim source data or change its case: changing the string changes its digest. Game seeds are not wallet recovery phrases; never enter a wallet recovery phrase here. This example also does not prove when a commitment was made.

What does the result mean?

“PASS” means only that the computed hash matches the entered commitment hash. It does not establish casino honesty, pre-bet commitment timing or payment.

Educational results panel showing a hash match and demonstration outcome values

Actual local educational result. “PASS” and “VERIFIED FAIR” are interface labels; the evidence here establishes only a hash match.

The demonstration HMAC for these inputs is:

164923c03bdddda005a0f12178e6b92855e8368c9b77a85d9db3ff63f4187df8

The tool uses the server seed as the key and reader-example:7 as the message. Its demonstration mapping produces 36.0251, displayed to two decimal places as 36.03 under “DICE (0-99.99)”. The 1.00x shown under “CRASH MULTIPLIER” is also a generic demonstration, not a verified historical crash result.

These numbers are not reproductions of Stake or Spribe games. For example, Stake's official implementation documentation describes a message containing a client seed, nonce and HMAC block counter: client:nonce:block. This tool uses client:nonce. The provider's documentation is a protocol description, not an independent laboratory conclusion.

The standalone Provably Fair tool can serve as a separate SHA-256 commitment-checking helper. Replaying a specific game still requires its exact algorithm; “universal” interface wording cannot substitute for that.

Why can a verifiable game still have a negative expected return?

Correctly following the rules does not imply positive expected net profit. A Provably Fair game and a laboratory-tested game can have the same house edge.

Consider a separate conditional model, unrelated to the synthetic HMAC example:

• Bets are independent.
• The probability of winning is 0.5.
• A win returns 1.98 times the stake, including the stake.
• A loss returns 0.

Under those assumptions:

RTP = 0.5 × 1.98 = 0.99 = 99%
House edge = 1%
For turnover of 1000, expected gross return = 990
Expected net result = −10

Turnover means the total amount wagered, not the deposit. These are expected values under the stated assumptions, not guaranteed personal results. RTP is not win probability: in this model, they are 99% and 50% respectively.

Neither a certificate nor Provably Fair changes the specified payout rules. A losing streak alone does not establish fraud, and a hash match does not promise future profit.

Can both mechanisms cover the same game?

Yes. A game can use an RNG, support Provably Fair and undergo independent laboratory testing. Different parts of one operator's catalogue can also use different verification mechanisms.

Check Provably Fair availability for the specific game and version, including any in-house game, rather than relying on a casino-wide badge. Likewise, do not extend a component certificate to the entire catalogue.

Physical cards and wheels in live dealer games do not become software RNGs merely because play is streamed online. The British testing procedure excludes physical live dealer devices from the relevant RNG statistical-testing row. That distinguishes testing scope; it does not mean no other requirements apply. See the testing procedure.

What should you do when evidence is missing or hashes do not match?

Treat the round as unverified, preserve the evidence and first rule out input or version errors. A missing reveal or mismatch means verification is incomplete; it does not, by itself, establish the cause.

Keep the original commitment, revealed seed, exact inputs, settings, round history and protocol documentation. Check encoding, case, whitespace, round identifiers and version compatibility. If the seed has not been revealed, confirm the documented disclosure condition.

Avoid new exposure while the issue remains unexplained. Ask support for an explanation and missing data. If the discrepancy persists, submit a documented complaint through the applicable operator, dispute-resolution or regulatory process, rather than automatically alleging fraud.

Before risking money, answer four questions:

• What exactly was checked? A component, game, version or individual round?
• What evidence is available? A laboratory document, prior commitment, revealed inputs or history?
• What remains missing? Version confirmation, commitment timing, result replay or settlement evidence?
• Is there appropriate operating permission? Check this separately for your jurisdiction.

If you cannot answer these questions, you lack sufficient evidence to consider verification complete. If you can, that evidence still supports only its stated scope—not absolute safety or profit.

18+. Gambling carries a risk of losing money. Checking evidence helps you understand the limits of assurance; it does not remove financial risk.