For years, a line like “certified by GLI” or “tested by eCOGRA” has served as a mark of legitimacy in online gambling. The badges are familiar and reassuring. They also raise a question most players never ask: what, specifically, is being certified, and how that compares to what a provably fair game lets you check yourself?
The two approaches were built for different purposes, in different eras, to answer different questions. Understanding what each one actually does, and where each one stops, is the clearest way to understand how fairness is established in modern online gambling.
What “audited” usually means
Most players assume a testing badge means a game has been fully examined, the random number generator, the return-to-player percentage, and the complete game logic, and that the result is fair in a way they could rely on.
That is not quite how traditional auditing works. Lab certification is designed primarily to satisfy licensing requirements. It confirms to a regulator that a game performs within defined parameters. It is not designed to give the end user a way to verify anything independently. The player is still asked to trust; the difference is that the trust is now extended to the lab and the regulator rather than to the casino alone.
Provably fair games take a different approach. Instead of resolving trust by adding a trusted third party, they aim to reduce the need for trust at all: the player is given the cryptographic material to check an individual result themselves. These are two genuinely different philosophies of fairness, and each has real strengths and real limits.
Traditional testing labs: built for regulation
Third-party testing labs are the compliance backbone of licensed online gambling. Their role is to validate that a game functions within regulatory parameters before it is allowed onto a licensed platform.
Every gambling regulator maintains a list of approved test houses. The UK Gambling Commission’s list, for example, includes BMM Testlabs, eCOGRA, Gaming Associates, Gaming Laboratories International (GLI), and several others. The process is broadly consistent across labs: a developer submits a game or RNG engine, the lab tests it internally, often simulating millions of rounds to validate the RNG and the RTP, and, if it passes, a certificate is issued. The game then goes live.
This model does its job well within the context it was built for. But that context has specific limits:
- It is a one-time approval. Certification happens before deployment. There is no continuous verification that the live game still matches the version that was tested.
- The methodology is private. The testing process and detailed results are shared with the regulator, not published for the public.
- The scope is often narrow. A certificate frequently covers the RNG specifically, rather than the complete game logic around it.
- There is no player access. An end user cannot independently verify the outcome of any individual round they played.
None of this makes lab testing dishonest or unnecessary. In strictly regulated markets such as the UK, the Netherlands, Germany, Sweden, New Jersey and Ontario, it is a regulatory requirement and a meaningful one. It simply predates the point at which public, round-by-round verifiability became technically possible. The labs were built to answer a regulator’s question, not a player’s.
It is also worth noting the model carries real cost. Games are often certified in market-specific versions to comply with local rules on bet sizes, spin speeds and bonus features, and that testing is expensive for providers. Some jurisdictions, among them Curaçao, Anjouan and Kahnawake, do not require extensive game testing at all, which means a game’s testing status can vary widely depending on where the operator is licensed.
The provably fair model: built for verification
The provably fair model emerged alongside blockchain-based gambling, in an environment where players were not willing to extend trust by default. Rather than relying on a third-party certificate, it gives the player the tools to check each round themselves.
The mechanism rests on a few components working together:
- A commit–reveal structure. The casino commits to a server seed, by publishing its hash, before play begins, so it cannot select a favourable seed afterward.
- A player-controlled client seed. The player can set their own seed, contributing input the casino cannot predict. Because this seed feeds directly into the function that produces the outcome, the result is not generated from the casino’s input alone: the player has genuine influence over the randomness of every round, and the casino cannot have pre-selected a server seed to force a particular result.
- Round-by-round reproducibility. Once the server seed is revealed, the player can recompute the result and confirm it followed from the seeds and nonce.
- Open verification tools. The game logic and a verifier can be inspected and re-run independently.
This model is most established for simple, in-house games such as dice, crash, plinko, mines, limbo and roulette, which do not depend on proprietary visual engines or layered slot mechanics and are therefore straightforward to reason about completely. It is widely used across crypto gambling platforms. As auditing techniques have matured, though, the range of games that can be independently verified has widened well beyond this starting point, as the rest of this article describes.
Where provably fair stops
Here is the part of the story that often goes unmentioned: a game being “provably fair” does not, on its own, mean it is honest.
What the provably fair protocol proves is narrower than it sounds. It proves that, given a particular set of input seeds, the outcome those seeds were fed into can be cryptographically verified: the randomness was generated honestly and was not swapped after the fact. What it does not prove is what happened next. The seeds produce a random value, and that value is then passed into the game’s logic, its probability tables, payout curves, and round-resolution rules, to produce the actual win or loss. That layer is frequently opaque. The RNG can be cryptographically sound while the player has no visibility into how the game logic turned the verified random value into a result.
A verifier built by the casino does not close this gap. It will confirm that a bet’s outcome matches the seeds, and the result will check out, but it shows the player a matching answer without showing how that answer was calculated internally. The cryptographic layer is verified; the game logic sitting on top of it is taken on trust.
In practice, the gap between those two things is where problems occur. Documented cases have shown casinos that implemented the cryptographic protocol correctly while the game above it did something else: probability tables quietly modified so the advertised return-to-player no longer held; a public “fairness checker” running different logic, or a different RTP, than the live game; a client seed accepted from the player but never actually used in the outcome. In each case the casino’s own verification continued to pass. The cryptographic layer was intact. The honesty was not.
The reason this can happen is structural. When a casino builds its own game, runs its own verifier, and publishes its own fairness tool, every part of that system shares one author. The pieces are consistent with each other by construction. That consistency is what the player’s verification confirms — and consistency is not the same property as honesty.
What independent auditing adds
This is the gap that independent third-party auditing is built to close.
An independent audit does not simply re-run the casino’s verifier — that would only confirm the casino is consistent with itself. It rebuilds the game from its published specification, in a separate implementation, and then checks that the casino’s real, live game matches what it publicly claims. It recomputes large samples of real bets to confirm conformance, derives the theoretical RTP from first principles rather than trusting the casino’s stated figure, and tests the system’s behaviour under conditions ordinary play would not reach.
In other words, traditional lab testing answers a regulator’s question, provably fair answers a player’s question about a single round, and independent auditing answers the question neither fully covers: does the live game actually do what the casino says it does, across every game and every configuration, in a way anyone can re-check?
| Traditional Lab Testing | Provably Fair | Independent Auditing | |
|---|---|---|---|
| Built for | Satisfying regulators | Player self-verification | Verifying the casino’s claims |
| Player can verify a result | No | Yes, one round at a time | Yes, plus the whole game |
| Checks complete game logic | Often RNG only | Protocol layer only | Full game logic and RTP |
| Ongoing after launch | No, one-time certificate | Continuous, per round | Re-runnable at any time |
| Methodology public | No, private to regulator | Partially, verifier only | Yes, fully open source |
| Confirms odds match the claim | At test time only | No | Yes, RTP derived independently |
| Catches a verifier that doesn’t match the live game | No | No | Yes |
ProvablyFair.org Certification was built to provide exactly this layer — independent, open-source audits of provably fair games, with the full framework and per-game results published openly. The audit methodology sets out how each game is tested.
The IP question is really an incentive question
It would be incomplete to discuss this without acknowledging why full transparency is not equally straightforward for every game, and why, for some operators, it is far more straightforward than the conventional wisdom suggests.
The standard objection to open auditing is intellectual property. A single online casino game typically costs between $50,000 and $500,000 to develop, and considerably more for licensed titles involving a film or music brand. Proprietary mechanics, such as the Megaways engine or the layered designs from studios like Nolimit City, Pragmatic Play and Hacksaw Gaming, represent years of investment, and publishing full game logic raises a genuine risk of cloning. That concern is real. But it is not equally real for everyone, because openness is not a moral question — it is an incentive question, and the incentives differ sharply by business model.
Consider a game studio. Its product is the game itself, licensed to many operators and run across dozens of casinos under different brands. The proprietary engine is the asset being sold. For a studio, protecting that code is not caution — it is protecting the revenue. Its commercial relationships are with operators and regulators, not directly with the player. Openness, for a studio, has a real cost and an unclear return.
A crypto casino with its own in-house games sits in almost the opposite position. Its games are not licensed out; they run in one place, under one brand. That brand is what the player chooses to trust or not, and trust is the entire conversion. For this kind of operator, verifiable fairness is worth more than code secrecy, because the code was never a licensable asset in the first place, while trust is the whole business. This is why, in practice, the casinos that have embraced provably fair are often relaxed about disclosure: some share game code with auditors directly, and much of their game logic is already published on their own sites. The IP “barrier” turns out, for this part of the market, to be largely not a barrier, because the operator has every incentive to lower it.
This is also why independent auditing has been able to reach genuinely complex games, not just simple ones. We have audited a 5×6 cluster-pays slot with cascading (tumbling) reels, wild substitution, and a multi-stage free-spin bonus with sticky multipliers, a game with exactly the kind of layered mechanics usually associated with proprietary slot engines. Every base spin, every cascade round, and every multiplier in that audit reproduces byte-for-byte from public seeds; the game was independently rebuilt and verified end-to-end against its specification and a large sample of captured live bets. The full audit, including the verification code, was published open source, so the result is not something a reader has to take our word for either. Complexity, it turns out, is not the limiting factor that the “simple games only” assumption suggested.
This works because of how the audit itself is structured. An independent audit of this kind depends on having the game’s source code: the logic has to be examined and independently rebuilt, not guessed at. And because a ProvablyFair.org audit is published open source, that code does not stay private. At publication, the game logic, the verification code, and the full results are all public, as part of the audit. There is no version of this where the source stays secret. Transparency is the product.
For a studio that licenses one engine to dozens of operators, that is a genuine cost, and the conventional IP objection holds: the engine is the asset, and publishing it has a real downside. But for a crypto-native casino running its own in-house games, the calculation runs the other way. The code was never a licensable product; the brand and the player’s trust in it are the whole business. These operators are not reluctantly tolerating disclosure, they are choosing it, because a fully public, independently verifiable audit converts more players than keeping the source code secret ever would. In the cascading-slot audit described above, we had complete access to the game’s source code, and it is now public alongside the audit. That is not the exception that proves a difficulty. It is the model working as intended.
A better definition of fairness
The honest summary is that neither model is complete on its own. Traditional lab testing provides regulatory assurance but no player verifiability and no ongoing check after launch. Provably fair provides round-level verifiability but cannot, by itself, confirm the implementation is honest or the advertised odds are real. Independent auditing addresses that conformance gap, and, as the audits of more complex games now show, it is no longer confined to the simplest titles.
This is no longer a theoretical direction of travel. In April 2026, Stake Engine, the remote gaming platform that lets independent studios build and launch slot titles for Stake.com, converted its underlying engine to a fully provably fair model across its catalogue of more than 1,200 games. A shift of that scale, covering proprietary slot content from many different developers rather than a handful of simple in-house games, is the clearest signal yet that verifiable fairness can operate at the scale of a mainstream game library. The pattern this article describes is now playing out in real time, and at real scale.
The likely direction is convergence: traditional labs adopting more open and continuous methods, and provably fair frameworks extending to handle more complex games. What should not change is the underlying principle. Fairness in gambling has historically been something a player is asked to take on trust. The more useful definition, and the one the industry is slowly moving toward, is that fairness should be something a player can see demonstrated, and ideally re-check, every time they play.
See how the audits work
The full ProvablyFair.org methodology, every test, every pass criterion, every worked example, is published openly.
Read the methodology

