US guide to social and sweepstakes casinos. No purchase necessary. 21+. Availability varies by state.

What Is Provably Fair Gaming? How to Verify Cryptographic Outcomes Step-by-Step

Reviewed by PayoutAuditLab Testing TeamLast reviewed:

Skip to the free verifier tool

1. The Core Problem with Black-Box RNGs

Every digital casino game depends on a random number generator (RNG). In traditional online gaming, that RNG runs on the operator’s servers, and you never see it work. You click “spin,” a result appears, and you have no way to confirm it was not changed after you acted.

The industry’s answer has been third-party certification. Testing labs audit the RNG’s code and statistical output, then issue a certificate. This has real value, but it has three limits:

Provably fair systems replaced “trust the auditor” with “verify the math yourself.” Using cryptographic commitments, the platform locks in its part of the outcome before you act, then reveals it afterwards, so anyone can recompute the result.

2. How Provably Fair Actually Works

Every provably fair outcome is built from three inputs.

The server seed is a long random string generated by the platform. Before any rounds are played, the platform shows you only its SHA-256 hash, a 64-character fingerprint. SHA-256 is a one-way function: easy to compute from the seed, practically impossible to reverse, and practically impossible to match with a different seed. Once you have recorded the hash, the platform is locked into that server seed.

The client seed is supplied by your browser, and you can usually edit it. Because you control it, the platform cannot pre-select a server seed that produces bad outcomes for you.

The nonce is a counter that increases by one with every round, so the same seed pair produces a fresh result each time.

The HMAC-SHA256 math, in plain terms

The three inputs are combined using HMAC-SHA256, a keyed hashing function:

HMAC-SHA256( key = server_seed , message = "client_seed:nonce" )

Think of it as a blender with a lock. The server seed is the key that operates the blender; your client seed and the nonce are the ingredients. Identical inputs always produce the identical output, and changing even one character produces a completely different one. That output is converted into a game result using a formula the platform publishes, so anyone with the inputs and the formula can reproduce the result exactly.

3. Step-by-Step: How to Manually Verify a Round

The values below are real. You can reproduce every number with any HMAC-SHA256 tool. The conversion formula is a simplified version of one many dice games use; always check your platform’s own published formula.

Step 1: Record the commitment hash

Before playing, copy the hashed server seed from the fairness settings and save it outside the platform:

d725a7477a671bdf79591c26cb990f8a24e96f732b2f7d09a256b662b7f514e4

Set your own client seed, for example kamini_test_seed, and play. Note the nonce of the round you want to check: in this example, 42.

Step 2: Rotate seeds to reveal the server seed

When you rotate to a new seed pair, the old server seed is disclosed:

a3f1c9e27b8d4f60e5a2b7c19d3e8f40

Step 3: Verify the commitment

Run the revealed seed through any public SHA-256 tool. The output must exactly match the hash from Step 1. If it doesn’t, the platform changed the seed.

Step 4: Recompute the outcome

Enter the key a3f1c9e27b8d4f60e5a2b7c19d3e8f40 and the message kamini_test_seed:42 into an HMAC-SHA256 tool. The output is:

52aac5c1fa018bbc7eed89d786fe88dc16e347a2e62d790ed38e88c1417fbdfd

Then convert it into a dice result using the first four bytes:

INPUTS         server_seed a3f1c9e2...9d3e8f40
               client_seed kamini_test_seed
               nonce       42
                     │
                     ▼
HMAC-SHA256    52aac5c1fa018bbc7eed89d7...417fbdfd
                     │
                     ▼
FIRST 4 BYTES  52 | aa | c5 | c1  →  82 | 170 | 197 | 193
                     │
                     ▼
FLOAT          82/256 + 170/256² + 197/256³ + 193/256⁴ = 0.3229183
                     │
                     ▼
DICE RESULT    floor(0.3229183 × 10001) / 100 = 32.29

If the platform’s history shows 32.29 for nonce 42, the round is verified. Use a verifier that isn’t hosted by the operator, or run the calculation yourself in Python or JavaScript: a platform-hosted verifier only proves the platform agrees with itself.

4. Provably Fair vs Traditional Certified RNG

Criterion Provably fair Traditional certified RNG
Audit frequency Every individual round can be checked Periodic lab audits plus ongoing monitoring
Player verifiability Full: any player can recompute any result None: players rely on the certificate
House edge transparency Built into a published formula and exactly calculable RTP stated by the provider; the operator’s configured version may vary
Third-party dependency Minimal: open cryptographic standards High: lab, regulator, and the operator’s honesty about live software
Limitations Proves results weren’t changed, not that the formula is generous Covers complex games (slots, live tables) that are hard to make provably fair

Provably fair does not mean favourable. The house edge is still in the published rules, so read them.

5. Crash Games & Multiplier Math

In crash-style games, including Aviator, Limbo, and Bustabit-type games, the multiplier for each round is determined by the hash before the round begins. The rising curve is an animation of a number that already exists.

A common derivation, based on the open-source Bustabit model, uses the same output from our example:

1. First 52 bits (13 hex characters):  52aac5c1fa018
2. Convert to decimal, divide by 2^52: X = 0.3229183
3. Apply formula:                      floor(99 / (1 − X)) / 100
4. Result:                             floor(146.21) / 100 = 1.46x

The 99 in the formula is where the roughly 1% house edge lives. Small values of X produce frequent low multipliers; values near 1 produce rare, very high ones. Platforms differ in their exact formulas, and some games, including Aviator, combine seeds from several players in each round, but the commit-then-reveal principle is the same.

Why “timing algorithms” and “predictor bots” are scams

6. Where to Go Next

US readers: See provably fair Originals in a sweepstakes format in our Stake.us review, covering Stake Cash redemption speed, the mail-in AMOE, and state availability. Not available in all states. No purchase necessary.

Canadian readers (excluding Ontario and Alberta): Our Stake.com Canada review includes our own seed-verification test alongside timed crypto and Interac withdrawals.

Try it: Use the free verifier below to check any round with your own seeds. It runs entirely in your browser.

Provably fair technology verifies that results were not altered; it does not reduce the house edge or improve your odds.

Verify a round yourself

Paste the revealed server seed, your client seed and the nonce. Everything is calculated in your browser; nothing you enter leaves this page. The fields start with the worked example from this guide.

SHA-256 of server seed
—
HMAC-SHA256(server seed, "client seed:nonce")
—
Dice result (first 4 bytes, 0–100.00)
—
Crash multiplier (first 52 bits, 1% edge)
—

These are the simplified illustrative formulas explained above. Each platform publishes its own conversion formula, so use theirs when checking a real round.