Provably fair gambling explained: what checking a result proves
Last reviewed · Editorial policy
How commit-reveal schemes, hash functions & on-chain proofs let a player check a single result, & how that differs from lab-tested random number generators.
The trust problem online
Online, a player cannot watch a deck being shuffled or a wheel being spun. The result arrives as output from software, so trust depends on how that software produces random numbers & turns them into outcomes.
The traditional answer is a random number generator (RNG) tested against a written standard. The Gambling Commission’s RTS 7, part of the remote technical standards issued under sections 89 & 97 of the Gambling Act 2005 & last updated on 7 May 2024, says random number generation & game results must be “acceptably random”.
The Commission defines that as being able “to demonstrate to a high degree of confidence” that outcomes are random, for example through statistical analysis using generally accepted tests. RTS 7 applies to gaming (including bingo), lotteries & betting on virtual events.
Gaming Laboratories International (GLI), a testing laboratory, publishes GLI-19, its standards for interactive gaming systems. Version 3.0, with a revision date of 17 July 2020, has a chapter of RNG requirements covering general requirements, RNG strength & monitoring, & mechanical RNGs.
Under that version, a laboratory issues a certificate of compliance once testing succeeds. From a player’s side, though, a certificate is a statement by others about a system the player still cannot inspect. Provably fair schemes try to close that gap by letting the player check individual results.
Commit-reveal in plain English
Commit-reveal is a two-step idea. First, the operator commits to a secret by publishing a fingerprint of it before the bet. Later, it reveals the secret itself.
Anyone can then run the revealed secret through the same fingerprinting process & compare the answer with what was published earlier. If the two match, the secret was not swapped after the bet was placed.
The fingerprint here is a hash digest. The US National Institute of Standards & Technology (NIST) says digests “are used to detect whether messages have been changed since the digests were generated”, which is exactly the property a commitment needs.
What is the secret? RTS 7 helps explain why it matters. The Gambling Commission says that for a software RNG it should be “computationally infeasible to predict what the next number will be without complete knowledge of the algorithm and seed value”. A seed is the starting value an RNG works from.
So a scheme that publishes a digest of its seed before play, & reveals the seed afterwards, gives the player a way to recompute results once the seed is known. The player still has to know the algorithm, which is why documentation matters.
The cryptography underneath
A hash function is an algorithm that turns a message of any kind into a value called a digest. NIST’s FIPS 180-4, the Secure Hash Standard published in August 2015, specifies hash algorithms used to generate such digests & to detect whether messages have changed.
NIST records that on 7 March 2023, after two rounds of public comment, it decided to revise FIPS 180-4. Readers citing the standard should check its current status.
The second building block is HMAC, set out in NIST’s FIPS 198-1, The Keyed-Hash Message Authentication Code, published in July 2008. As the name says, it is a message authentication code built on a hash function & a key. It superseded FIPS 198, dated 6 March 2002.
A planning note dated 23 June 2025 says a Federal Register Notice sought feedback by 23 July 2025 on NIST’s plans to withdraw FIPS 198-1 & move its content to a new publication, SP 800-224.
What GLI’s draft standard covers
GLI has published a draft of GLI-19 version 4.0 with a revision date of 7 July 2026. Its chapter on RNG requirements includes a new section 5.5 titled “Provably Fair” RNGs, alongside general RNG requirements, RNG strength & monitoring, & mechanical RNGs.
The version 3.0 RNG chapter has no such section. Placing provably fair RNGs in the same chapter as other RNG types suggests GLI treats them as something to be tested by a laboratory, not as a replacement for testing.
The draft also says operators & suppliers are expected to give the testing laboratory documentation, credentials & access to source code & a production-equivalent test environment. After successful testing, the laboratory provides a report evidencing the evaluation or certification.
The document is marked as a draft, & GLI describes GLI-19 as “a living document”. The detailed wording of section 5.5 is not in the source text used for this guide, so its specific requirements are not summarised here.
What provably fair doesn’t prove
A matching digest shows one thing: the committed secret was not changed after it was published. It does not, on its own, show that the rules turning that secret into a result are fair.
RTS 7 shows how much more a regulator looks at. It says any scaling (converting raw RNG output into game outcomes, such as a card or a reel position) must maintain the RNG’s qualities, & that the mapping of random inputs to outcomes should follow “prevailing probabilities, pay tables, etc.”
The Gambling Commission also bars adaptive behaviour, meaning “a compensated game” that changes the probabilities of outcomes during play. It says random numbers must be used in the order received & not discarded because of adaptive behaviour.
Other parts of RTS 7 cover game design. Games may not falsely display near-miss results, a simulated coin must land heads with probability 0.5 every time, & rules, payouts & probabilities may not be changed while a game is available except as its rules provide, with changes brought to customers’ attention.
None of these checks is answered by recomputing a single digest. A result can be untouched after the bet & still come from a scaling method or pay table the player has not examined.
On-chain randomness (VRF)
A verifiable random function (VRF) produces a random value together with a cryptographic proof of how it was made. Chainlink’s documentation describes Chainlink VRF as “a provably fair and verifiable random number generator (RNG)” for smart contracts, programs that run on a blockchain.
Chainlink says that for each request it generates one or more random values & a proof, & that the proof “is published and verified onchain before any consuming applications can use it”. It says this helps ensure results cannot be manipulated by any single entity, including oracle operators, smart contract developers, users, miners or block builders.
The documentation carries a caveat. Chainlink says that “in the unlikely event” an adversary compromises the randomness-generating secret key & gains the ability to construct blocks on the target chain, “they could strongly bias the result”.
Chainlink lists blockchain games & NFTs among its use cases, along with tasks such as randomly assigning judges to cases. It says VRF v2.5 lets users pay for requests in LINK or native tokens, through either a subscription account or direct funding.
Provably fair vs licensed RNG testing
The two approaches answer different questions. A commitment lets a player check, after the event, that one result was not altered. GLI-19 is a standard against which an independent testing laboratory evaluates a system, with chapters on RNG requirements & game requirements, & the Gambling Commission’s RTS 7 sets requirements covering the RNG, its seeding & re-seeding, its scaling & the game rules as a whole.
RTS 7 itself values outside verification in one setting. Where a lottery uses external events to decide its result, the Gambling Commission says those outcomes must be “unpredictable and externally verifiable”, & unable to be influenced by the lottery operator.
Reading a fairness page with the sources in mind suggests some neutral questions. Which standard, if any, was the system tested against, & by which laboratory? Is the full algorithm documented, including how raw numbers are scaled into outcomes?
Other questions follow from the cryptography. Is the digest published before the bet? Can the revealed secret be checked with an independent tool, not only the operator’s own page? For on-chain randomness, is the proof verified onchain before the value is used, as Chainlink describes?
Questions
What does provably fair mean?
It describes schemes that let a player check that a result was not changed after the bet, usually by comparing a secret revealed afterwards with a hash digest published beforehand. GLI’s draft GLI-19 version 4.0, dated 7 July 2026, includes a section titled “Provably Fair” RNGs.
Why does a hash show that a result wasn’t changed?
NIST’s Secure Hash Standard says hash digests are used to detect whether messages have changed since the digests were generated. If the revealed secret produces the digest published before the bet, it was not swapped afterwards.
Does provably fair replace lab-certified RNG testing?
Not on the sources here. GLI’s draft places provably fair RNGs inside its RNG requirements for laboratory testing, & the Gambling Commission’s RTS 7 covers matters such as scaling, pay tables & adaptive behaviour that a single digest check does not address.
Can on-chain randomness be manipulated?
Chainlink says its VRF proof is verified onchain before applications use the value. It also says that if an adversary compromised the secret key & could construct blocks on the target chain, they could strongly bias the result.
Sources
Sources checked 10 October 2026. Information only. 18+.
Discussion
Ask a question, add useful context or share a source. Keep it relevant & respectful.
Add a comment
Comments are reviewed before publication.