Provably Fair: What It Covers and How to Check It

Provably fair is the one claim a crypto casino makes that you can test yourself, in about two minutes, without trusting the casino, the regulator or us. It is also narrower than the phrase suggests, and the narrowing happens per game rather than per casino.

TL;DR

• Provably fair lets you verify two things: that the operator honoured a cryptographic commitment made before your wager, and that the outcome you saw matches the published algorithm and inputs. It says nothing about the house edge, the paytable or whether the operator pays out.

• Checking the hash alone is only half the job. A matching hash proves the revealed seed is the one committed to. Reproducing the result proves the outcome followed from it.

• If the game lets you, set your own unpredictable client seed. That stops the operator choosing both main inputs and strengthens what the scheme gives you.

• Coverage is per game, not per site. It is most common in casino Originals and crypto-native titles, but some third-party studios implement it too, including for slots.

• The badge is not the mechanism. The question worth asking is not whether a homepage says "provably fair", but which specific games expose a commitment, the inputs, a published algorithm and a verifier.

What does "provably fair" actually prove?

That the operator committed to a secret before your wager and could not change it afterwards, and that the result you were shown follows from that secret plus the inputs. Nothing beyond that, and the "nothing beyond" is the part that gets lost.

The mechanism is a commitment scheme borrowed from cryptography. Before you play, the operator generates a secret server seed and shows you its hash. A hash is a one-way fingerprint: you cannot work backwards from it to the seed, but once the seed is revealed you can hash it yourself and confirm it produces the fingerprint you were handed earlier. That single property does the work. The operator has pinned itself to a value it can no longer change without the mismatch becoming obvious to you.

You then contribute a client seed, and a counter called a nonce increments with each bet. The result is derived from those inputs through a published algorithm.

Implementations differ in what exactly gets committed, and it is worth knowing which one you are looking at. In the server-seed and client-seed model used by most casino Originals, the commitment covers the server seed, and the outcome is computed deterministically once your seed and the nonce join it. In BGaming's model the round's outcome is calculated first and the hash covers that outcome: the studio's own documentation states that "before any bet placed we already calculated the outcome of the round", and the player receives Hash(Result + Secret) beforehand. Both are provably fair. They commit to different things, and the verification steps follow the scheme in front of you.

What none of it touches: the house edge, the paytable, the odds the game was designed around. A dice game can be flawlessly provably fair and still be built to return 96% over time. Verification tells you the deal was not rigged mid-hand. It does not make the game generous, and no amount of hashing changes the maths of a game you are expected to lose over a long enough session.

How do you verify a provably fair bet, step by step?

Six steps, all of them yours. On an operator that implements this properly, every one is available in the interface.

1. Set your own client seed if the game allows it. This prevents the operator from choosing both main seed inputs and strengthens the assurance the scheme provides. Where the seed is system-generated and cannot be changed, you can still verify everything below; you are simply relying on the commitment alone rather than on a value you contributed.

2. Save the hash shown before the round. This is the commitment. Copy it somewhere outside the operator's interface, so the value you compare against later is one you control.

3. Place the bet and note the nonce and any round number. Every bet under one seed pair carries its own counter, and you need it to reproduce that specific result.

4. Obtain the revealed seed. When this becomes available depends on the implementation. Some operators reveal the previous server seed only when you rotate the seed pair, because the current one is still in play. Others surface the last round's server seed straight after the spin. Crypto-Games does the latter, exposing the last game's server seed with a built-in verify step.

5. Verify the commitment. Hash the revealed seed and confirm it matches the string you saved in step 2. Any SHA-256 tool does this in a browser.

6. Verify the outcome. Use the operator's published algorithm or its verifier, with the server seed, client seed, nonce and any game-specific inputs, and reproduce the exact result you saw.

Steps 5 and 6 answer different questions, and stopping at step 5 is the most common mistake. A matching hash tells you the revealed seed is genuinely the one committed to. It does not tell you the operator derived your result from it correctly. Only recomputing the outcome does that.

Where an operator publishes its algorithm you can follow it exactly. Thunderpick's documentation for Thunder Mines, published on 16 July 2026, computes HMAC-SHA256 with the server seed as key and clientSeed:nonce:round as the message, converts the resulting bytes into floating-point values and runs a Fisher-Yates shuffle to place the mines, with a verification script players can run themselves. Bitsler publishes its algorithm and code for its in-house games alongside a verifier and a seed-settings page. Crypto-Games documents a commit-reveal flow in which the player sets a custom client seed, sees the hash of the next server seed before play, and validates the result afterwards with a built-in verify button.

Which games does provably fair actually cover?

Specific games, not whole casinos, and this is the distinction the marketing flattens.

Provably fair is most common in casino Originals and crypto-native titles: dice, crash, plinko, limbo, mines. The operator builds those games, controls the whole chain and can commit to an outcome. Wolfbet's scheme, as we read it, covers its in-house games rather than third-party slots. Bitsler's covers its own Bitsler games. Dustbit publishes a verification guide that applies to the operator's own titles. Wild.io markets a library of 8,000+ games from 60+ providers, and its provably-fair coverage sits with the Wild Originals collection, listed on its own site as crash games, dice, plinko and limbo.

It is not limited to Originals, and the common shorthand that slots can never be provably fair is wrong. Some third-party studios implement their own schemes. BGaming publishes a provably-fair system covering its slots and documents the slot verification process, generating a reel model per reel and letting the player apply a client seed to a pre-computed result. 7Bit Casino's fairness page describes provably-fair slots, card games using a Fisher-Yates shuffle, and roulette using a Mersenne Twister, and names BGaming as the developer that first integrated the approach into its games.

So the useful question is never "is this a provably fair casino". It is which of the games you actually intend to play exposes a commitment, the inputs, a published algorithm and a verifier. A player who reads "provably fair" on a homepage and then opens a slot from a studio with no such scheme has verified nothing, and the same player opening a BGaming title has a verification path in front of them.

Where does the phrase sit among the other fairness claims?

It is the only one you can settle alone, which is why it is worth the two minutes.

Provably fair needs nobody's word. One layer out is RNG certification, where an independent laboratory tests the random number generator, and there you are reading a claim about a document rather than the document itself. Cloudbet's support page states that "all RNG-based games available on Cloudbet carry an official Certification of Random Number Generator (RNG) Evaluation conducted by GLI (Gaming Laboratories International) and issued through Curaçao eGaming". That is a specific laboratory and a specific issuing route, which is more than most operators give you, and it is still a claim rather than a certificate you can open. Bitcasino.io and Livecasino.io describe internal testing plus External Compliance Testing in their terms. BC.Game's site states that "our provably fair systems and audited RNG protect every bet"; on our review we did not locate a publicly accessible certificate behind that claim, which is a gap in what is published rather than evidence that no audit exists.

A layer further out is the return-to-player figure, and it is the thinnest of the three. On the operators we have read on this field, we found published RTP figures in some cases but did not locate a publicly accessible audit of those figures.

Stacked up, the picture is straightforward. One mechanism you can verify yourself, on the games that implement it. A certification layer that is mostly self-reported. A payout layer where the audit, if it exists, is usually not published. The further a fairness claim sits from something you can hash in your own browser, the more of it rests on trust.

What can you check in five minutes, before depositing?

Four things, none of which needs an account or a deposit.

• Is there a fairness page, and does it name a mechanism? A page saying "our games are provably fair" and stopping is not a mechanism. A page with a hash, the inputs, an algorithm and a verifier is.

• Which games does it cover? Look for the scope. If it names Originals or specific titles, that is the honest version, and it tells you which parts of the lobby sit outside it. If it names a studio, check whether the games you play come from that studio.

• Can you set your own client seed? Where you can, do. Where you cannot, the commitment can still be checked, but the operator has chosen both inputs.

• Is there a verifier, or a published algorithm you can rerun? Operators that provide one make this a two-minute check. Operators that provide neither are asking you to take the claim on trust, which is the exact thing the claim exists to remove.

None of this makes an operator safe. It settles one specific promise, which is a smaller question than "can I trust this casino" and a far easier one to answer. The bigger question runs through licensing, ownership and what the terms permit an operator to do with your balance, and those are covered in how to check a crypto casino licence and in our guide on what to do when a casino refuses to pay.

How we read these documents

Two kinds of statement appear above, and they are not interchangeable. Where a sentence is in quotation marks, it is verbatim from the source named next to it, read on 13 August 2026. Where it is not, it is our reading of what an operator publishes, recorded in that operator's profile field in the BullsRank catalogue with its source URL and the date it was read. We do not dress our summaries as operator quotes. Where our line falls between a stated claim and a checked one is set out in our methodology.

Two limits, stated plainly because they change how the examples should be read. First, these are operators whose fairness fields we have already read, not a census: our catalogue is still being filled, and an operator absent from this guide has not been read on this field rather than been found lacking. Second, no share or percentage of our catalogue appears here for the same reason. A denominator that reflects how far our collection has got is not a measurement of the market, and publishing one as if it were would be the kind of number we exist to catch other people making.

Where we could not read a page, we say nothing about its contents rather than treating an unread page as an empty one.