What provably fair means — and what it doesn't prove

"Provably fair" means you can check, after the fact, that a game result came from inputs that were locked in before you placed your bet. It is a commitment scheme: the site publishes a fingerprint (a hash) of its secret seed up front, and reveals the seed later so you can confirm nothing was swapped. That is genuinely useful. It is also much narrower than the phrase suggests.

This guide draws the line between what the proof establishes and what it leaves untouched. If you only remember one thing: a valid proof says the dice weren't switched mid-roll. It says nothing about whether the dice were loaded in the house's favour by design.

The idea in one paragraph

Before you play, the site picks a random server seed and shows you its SHA-256 hash. You add your own client seed. Each bet uses a counter called the nonce. The result is calculated from all three with a published formula, usually HMAC-SHA256. Later, the site reveals the server seed. You hash it yourself; if it matches the fingerprint you saw earlier, the seed wasn't changed. Then you rerun the formula and confirm you get the same result. The moving parts are explained in server seed, client seed and nonce.

Why a hash works as a commitment

SHA-256 turns any input into a 64-character hex fingerprint. Two properties matter here: you can't work backwards from the fingerprint to the input, and a tiny change to the input changes the fingerprint completely. We ran this in Python with an example seed made up for this guide:

sha256("9f2c4e1a7b3d8e6f0a5c2b9d4e7f1a3c")
= a5e39de9361cb47dd6ccdf84bb0cbeff1e402575f217b91bb2e560cfe1ac582d

sha256("9f2c4e1a7b3d8e6f0a5c2b9d4e7f1a3d")   # last character c -> d
= 0d6cde9ccc103697990c667b979e7d632dfeca1441242f16ed9b2323c243b8ba

One character changed and the fingerprint is unrecognisable. That is why a site that has published a5e39de9… can't later claim the seed was something else: you'd hash their claim and immediately see the mismatch. And because the hash can't be reversed, seeing it before play doesn't let you predict results.

What a valid proof does establish

When a verification checks out, you've confirmed three specific things:

• The server seed was fixed before your bet. Its hash was published first, and the revealed seed matches it.
• Your input mattered. The client seed you chose (or could have chosen) went into the calculation, so the site couldn't pick a server seed tailored to a seed it didn't know.
• The result follows the stated formula. Running the documented method on those inputs reproduces the outcome you were shown.

Put together, that rules out one important kind of cheating: changing an outcome after seeing your bet.

What it doesn't prove

This is where the label tends to oversell. The table below sets the common assumptions against what the proof actually covers.

Two rows deserve emphasis.

The odds are a design choice. Imagine a dice game that pays 2x if the roll is under 49.50. The formula can be perfectly verifiable and still give the house a 1% edge on every bet. Provably fair systems are often used alongside a house edge, not instead of one. Verification confirms the roll; the edge is in the payout rule.

The proof covers the number, not the mapping to prizes. In a case-style game, the roll might be 77.61, and the site's table says rolls from 75.00 to 89.99 win a particular item. You can check the roll. Whether that table is the one actually applied, and whether its ranges match the advertised odds, is a separate check you have to do by reading the published table and comparing.

A worked check: what "verified" looks like

Here is a full check using example values made up for this guide. The method is one common convention (described in the step-by-step verification guide).

If the site showed you 77.61 for that bet, the proof holds. You can rerun every number on our verifier page, which uses the same inputs by default.

Now notice what the table didn't touch: whether 77.61 should have paid what it paid, whether the advertised odds match the range table, or whether the site will let you cash out.

How to use this in practice

1. Treat provably fair as a minimum, not a recommendation. Its absence is a warning sign; its presence doesn't make a game good value.
2. Set your own client seed where the site allows it, before you play.
3. Spot-check a few bets after rotating your seed, using the site's documented method.
4. Read the outcome table separately. Confirm the ranges add up and match the stated odds.
5. Look at the house edge. A verifiable game with a large edge still costs you money on average.
6. Watch for vague claims. "Our games are provably fair" with no documented formula can't be checked at all. See our red-flags checklist.

The bottom line

Provably fair is a real cryptographic guarantee about one thing: the result wasn't altered after you bet. It is not a fairness rating, an audit of the odds, or a promise about the site. Use it for what it proves, check the rest yourself, and remember that a verified loss is still a loss.