Provably Fair Gambling: How Verification Works

By monerogambler editorial desk · updated 2026-09-05 · facts checked 2026-09-05

table of contents

1. What provably fair actually is: a commitment scheme
2. The three ingredients
3. The math: from seeds to a roll number
4. What verification proves - and what it does not
5. Before you trust a "provably fair" casino
6. Verify it yourself

What provably fair actually is: a commitment scheme

Strip away the branding and provably fair is a commitment scheme - one of the oldest constructions in cryptography [1]. A commitment scheme has two phases: a commit phase, where a value is chosen and locked in while staying hidden, and a reveal phase, where the value is disclosed and checked against the commitment [1]. The construction guarantees two properties: the committed value cannot be changed afterwards (binding), and it cannot be read from the commitment itself (hiding) [1].

Mapped to a casino: the operator picks the server seed, publishes its hash, and that hash is the lock. The moment the hash exists, every result derived from the seed is already fixed. When the seed is revealed - typically when you rotate it or cash out - the reveal phase lets you recompute every bet.

The three ingredients

Every provably fair game derives its results from the same three inputs:

1. Server seed. Chosen by the casino, committed via its published hash before your first bet. This is the part you must be able to verify existed in advance [1].
2. Client seed. Yours, and usually editable. Because the casino committed to its seed before seeing yours, your input adds randomness the operator cannot pre-compute against.
3. Nonce. A counter that increments with every bet, so the same two seeds generate a fresh result each round.

The result of a roll is then derived from all three - typically by hashing them together and reducing the digest to a number. Changing any single input changes every downstream result.

The math: from seeds to a roll number

The dominant construction is HMAC - keyed hashing, standardized in RFC 2104: a message authentication code computed as nested hash applications over a key and the data, with the server seed acting as the key and the client seed and nonce as the message [2]. The hash function underneath is SHA-256 in most implementations [3], the standard specified for exactly this kind of digest generation [3]. The resulting digest gets reduced to a roll number - for example, by taking the first bytes of the HMAC output and mapping them onto the number range of the game.

Nothing here is exotic. The same primitives secure a large share of the internet's message authentication [2]; the casino merely publishes its side of the inputs. That is the entire trick: standard math, plus a public commitment.

What verification proves - and what it does not

Verification proves the narrow, important thing: the results of your historical bets match what the committed inputs mathematically produce. If your past rolls recompute exactly after the seed reveal, the operator did not alter outcomes mid-session [1].

It does not prove:

• Payout speed or honesty of withdrawals - a casino can verify bets perfectly and still stall your cashout; those live in our per-operator reviews, not in the math.
• The published RTP - provably fair ensures the mechanism is as coded, not that the game's configured house edge is friendly. House-edge math is its own topic, covered in our bonus math guide.
• That every game uses it - check which games are actually covered; verification badges on the homepage cover only what they cover.

Before you trust a "provably fair" casino

1. Confirm the server seed hash is visible before betting, and note it.
2. Set your own client seed instead of accepting the default.
3. Rotate seeds occasionally - that is what triggers the reveal.
4. After rotation, verify a sample of past bets with the revealed seed.
5. If the interface hides the hash, the "provably fair" label is decoration, not a mechanism [1].

Verify it yourself

Our provably fair verifier recomputes rolls from your seeds and nonce for the common dice and HMAC schemes - paste, pick the algorithm, compare. If the recomputed numbers match your bet history exactly, the game was fair as committed; if a casino's numbers fail verification, you have the strongest evidence a player can hold. For the money side of the same trust question, the deposit guide covers test withdrawals, and the wallet guide keeps your side of the flow clean.

FAQ

Is provably fair the same thing as Monero privacy?

No. Monero hides the payment, provably fair proves the game. They are independent layers, and a good XMR casino gives you both.

Can a provably fair casino still cheat?

Only around the edges - by hiding the pre-bet hash, rotating seeds silently, or applying verification to some games and not others. The math only covers what is committed to before your bets [1].

Do I have to verify every single roll?

No. Spot-checking is the practical pattern: verify a handful of historical bets after a seed rotation. If those recompute exactly, the mechanism works for the rest.

What is the server seed hash for?

It is the commitment. The hash pins the server seed before you play, so the casino cannot pick a "better" seed after seeing your client seed and bets [1].

Which hash algorithm do casinos use?

SHA-256 is the standard building block, usually inside an HMAC construction [2][3]. Our verifier handles the common variants.

Sources

1. Wikipedia - Commitment scheme (commit/reveal, binding + hiding) - accessed 2026-09-05
2. RFC 2104 - HMAC: Keyed-Hashing for Message Authentication - accessed 2026-09-05
3. NIST FIPS 180-4 - Secure Hash Standard (SHA-256) - accessed 2026-09-05

Keep reading

Tools for this