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:
- It is periodic. An audit confirms the system behaved correctly during testing, not during your session.
- It depends on trust. You trust the lab, the operator’s honesty about which software version is live, and, for offshore sites, a regulator you may never have heard of.
- It is unverifiable by players. No individual player can check a single result.
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
- The outcome exists before the round starts. Watching the curve, timing clicks, or tracking previous rounds cannot change a value that is already fixed.
- Each round is independent. A new nonce produces an unrelated hash. Ten low multipliers in a row say nothing about the next one.
- Prediction would require reversing SHA-256. No publicly known method can recover an unrevealed server seed from its hash.
- The real goal of these tools is to take something from you. Predictor apps and signal groups typically ask for payment, logins, or wallet access. Treat them as theft attempts.
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.