Provably fair: how to check a bet yourself

“Provably fair” means a game result can be recomputed by the player from values the casino committed to in advance. It does not mean the game is generous, the casino pays out or the licence is real. This guide explains the mechanism in plain terms – server seed, client seed, nonce and a hash function – walks through a small worked example you can recompute yourself, shows how a bet is checked in practice, and lists what the 15 casinos we profile say about provably fair games. We have not placed or verified bets at any casino; everything about a casino below is what it states in its own words.

The idea in one minute

An ordinary online game asks you to trust that the result was drawn fairly. A provably fair game splits the draw into three ingredients so that neither side can quietly steer it:

• Server seed – a long random value chosen by the casino. Before you bet, the casino shows you only its hash (a fingerprint), called the commitment. A cryptographic hash cannot realistically be reversed, so the fingerprint does not reveal the seed – but the casino can no longer swap in a different seed without the fingerprint changing.
• Client seed – a value that comes from you. Most casinos pre-fill a random one and let you edit it. Because you choose it, the casino cannot know the full input in advance.
• Nonce – a counter that rises with every bet made with the same pair of seeds (0, 1, 2 …), so each bet gets a different result from the same seeds.

The result is computed from these three values with a keyed hash. The most common building block is HMAC-SHA256: HMAC is the keyed-hash construction defined in RFC 2104, and SHA-256 is the hash function specified in NIST FIPS 180-4. Published test vectors for HMAC-SHA256 are in RFC 4231, which is how you can confirm that a tool computes the primitive correctly.

After you change (“rotate”) your seeds, the casino reveals the old server seed. You can then check two things: that its hash equals the commitment you were shown before betting, and that the results you were given follow from the seeds. If both hold, the casino did not change the seed after seeing your bets.

Important: there is no universal formula. How the hash output is turned into a dice roll, a crash multiplier or a card differs from casino to casino and from game to game, and each casino documents its own method. The example below is a neutral, generic illustration, not any casino’s implementation.

A worked example you can recompute

We use deliberately simple, made-up inputs. The scheme is: HMAC-SHA256(key = server seed, message = client seed + ":" + nonce); take the first four bytes of the 32-byte result, read them as a fraction between 0 and 1 (byte 1 ÷ 256, plus byte 2 ÷ 256², plus byte 3 ÷ 256³, plus byte 4 ÷ 256⁴), and turn that into a roll from 0.00 to 100.00 with floor(fraction × 10,001) ÷ 100.

• Server seed: 3f9a1c7e5b2d4086a1f0c3e9d7b5a2486c1e0f9d3a7b5c2e8d4f1a6b9c0e3d57
• Commitment (SHA-256 of the server seed, shown to the player in advance): 0c63e3cbe603c613650cfdb0a06694f4212442552cec038cf0164d8160b09372
• Client seed: my-own-seed-2026

For nonce 0 the full 32-byte output is 77e69b6f01705d0366c043a795c5cc1ea279fbf3f63512681653c7c55d46e0e1. We computed these numbers with three independent implementations (Node.js, OpenSSL and Python) and they agree; we also confirmed our setup against the RFC 4231 test case 2 (key “Jefe”, message “what do ya want for nothing?”, result starting 5bdcc146). The arithmetic for nonce 0 by hand: the first four bytes are 0x77, 0xe6, 0x9b, 0x6f = 119, 230, 155, 111, so the fraction is 119/256 + 230/65,536 + 155/16,777,216 + 111/4,294,967,296 ≈ 0.468363, and floor(0.468363 × 10,001) = 4,684, which reads as 46.84.

To reproduce it yourself with OpenSSL on a command line:

printf '%s' 3f9a1c7e5b2d4086a1f0c3e9d7b5a2486c1e0f9d3a7b5c2e8d4f1a6b9c0e3d57 | sha256sum
printf '%s' 'my-own-seed-2026:0' | openssl dgst -sha256 -hmac 3f9a1c7e5b2d4086a1f0c3e9d7b5a2486c1e0f9d3a7b5c2e8d4f1a6b9c0e3d57

Two details trip people up. First, in this example the seed is used as the literal text of the key (the 64 characters), not decoded into 32 bytes; a casino may do it either way, and the choice changes every output. Second, an extra space, a different separator or upper-case letters give a completely different hash. That is why you follow the casino’s own documented format exactly.

How to check a real bet, step by step

1. Find the casino’s fairness documentation first. It should say which hash function is used, what the message looks like, how the output becomes a result, and how seeds are rotated. If you cannot find a precise description, you cannot verify anything, whatever the label says.
2. Set your own client seed before you play, instead of keeping the pre-filled one. Changing it also usually triggers a rotation, so note down the hashed server seed (the commitment) that is shown afterwards.
3. Play, and note the nonces of the bets you want to check, or export or copy your bet history.
4. Rotate the seed pair (in most designs by changing the client seed or pressing a “new seed” button). The casino then reveals the previous server seed. Until you rotate, the seed in use stays hidden by design.
5. Hash the revealed server seed with SHA-256 and compare it with the commitment you saved. They must be identical.
6. Recompute the bet from server seed, client seed and nonce using the casino’s documented formula, ideally with a tool that is not the casino’s own verifier – for instance your own short script or a verifier written by someone else – and compare the result with what the game showed.

A casino’s built-in verifier is convenient, but it runs on the casino’s own page. An independent recomputation is what makes the check meaningful. If the commitment does not match, or your recomputed result differs, stop playing and write to support with the seeds, nonce and screenshots; see what to do when something goes wrong with a payout for the general complaint route.

What a provably fair check does – and does not – prove

• It proves that, for the bets you checked, the casino did not change the server seed after seeing your client seed, and that the displayed result matches the documented formula.
• It does not change the house edge. A game can be fully verifiable and still pay back less than you stake over time; the edge is part of the game’s design, not of the randomness.
• It does not cover everything on the site. Provably fair normally applies to the casino’s in-house “originals” such as dice, crash or mines. Slots and live-dealer games from third-party studios use certified random number generators or physical dealing instead, and cannot be rechecked with seeds.
• It says nothing about payments or terms. It does not tell you whether withdrawals are paid, whether the licence is genuine or what the bonus conditions are. Those are covered in our licence guide, the withdrawal-times guide and the bonus-terms guide.
• It is only as good as the check. Most players never verify a single bet. A casino that publishes a clear method and lets you set your own client seed has made verification possible; whether it holds is something only a recomputation shows.

What the 15 casinos we profile say

9 of the 15 casinos name provably fair games on their own pages. The table gives their wording as we recorded it – this is what the casino says, and we have not tested it. We did not audit any algorithm, place any bet or run any verifier. A casino marked “Not stated” may still offer it on a page we did not read; the profile shows what we checked and when. The list of casinos that name the feature is also on our provably fair crypto casinos page.

Frequently asked questions

Does “provably fair” mean I will win more often?

No. It concerns whether the result can be checked, not how favourable the game is. Each game keeps its house edge, and the long-run expectation is unchanged by the verification method.

Why do I have to rotate my seed before I can verify?

The server seed must stay secret while it is in use; if it were shown early, a player could predict upcoming results. Revealing it after rotation lets you verify past bets without exposing future ones.

Is SHA-256 the only function used?

No. HMAC-SHA256 is common, but some casinos use SHA-512, other constructions or additional per-game steps. Always follow the specific casino’s documentation rather than a generic formula, including ours.

Can I verify a slot from a big game studio this way?

Generally no. Those slots use the studio’s certified random number generator on its own servers. Provably fair games are, in the casinos we profile, mainly the casino’s own titles; a casino may also list individual third-party titles that include the feature, which its fairness page then describes.

Conclusion

Provably fair is a useful transparency tool: a commitment hash, your own seed and a counter make it possible to recompute results instead of taking them on trust. It is also narrow. Use it as one check among several – a confirmed licence, clear withdrawal terms and fair bonus conditions matter at least as much. If you try verification, set your own client seed, save the commitment, rotate, hash the revealed seed and recompute with a tool you control. Gambling is for adults (18+) and carries a risk of loss; if play is becoming a problem, the free, confidential help lines on our responsible gambling page can help, and our methodology explains how we record casino claims.

Sources

• H. Krawczyk, M. Bellare, R. Canetti, RFC 2104 – HMAC: Keyed-Hashing for Message Authentication (IETF), accessed 10 Oct 2026.
• M. Nystrom, RFC 4231 – Identifiers and Test Vectors for HMAC-SHA-224/256/384/512 (IETF), accessed 10 Oct 2026.
• NIST, FIPS 180-4 – Secure Hash Standard, accessed 10 Oct 2026.
• Each casino’s own provably fair or fairness page, as recorded in the profile linked in the table (casino says, with the date checked).