The problem verification solves
Every casino game is a claim: “this result was random, and we didn’t pick it after seeing your bet.” In a physical room you audit that claim with your eyes — fresh decks, transparent dice, a wheel you can watch. Online, the randomness happens on someone else’s computer. Provably fair is the cryptographic replacement for watching the dealer’s hands.
The core mechanism is commit-reveal. Before you bet, the house locks its randomness in place and shows you a fingerprint of it — a SHA-256 hash of the server seed. A hash works one way: the house can’t find a second seed matching the same fingerprint, and you can’t read the seed out of it. After the seed is later revealed, you check it against the fingerprint you were shown, and recompute every round it produced.
The three inputs of every round
| INPUT | WHO PICKS IT | WHAT IT DOES |
|---|---|---|
| Server seed | The house — committed as a hash before play | The house’s half of the randomness |
| Client seed | You — editable in the fairness panel | Your half; the house can’t predict it |
| Nonce | Nobody — it counts 0, 1, 2, … | Makes every round unique under the same seeds |
The round’s raw randomness is HMAC-SHA256(server seed, client seed-nonce-cursor) — a keyed hash mixing both parties’ inputs. Because your client seed enters the mix, the house would have needed to predict your choice to bias a result; because the server seed was committed first, it can’t be swapped afterward without breaking the fingerprint you already hold.
From that digest, bytes become numbers. Our engines read the first bytes as a uniform value in [0,1) — with the rounding done bit-for-bit the same way in the generator and the verifier — and each game maps uniform values to outcomes through its published rules: a dice roll curve, a card draw from a shrinking pool, chinchiro dice at fixed cursor positions.
The walkthrough
- Open any original and open the fairness panel. Note the current server seed hash — this is the commitment. Set your own client seed if you like.
- Play a round or two. Each settled round records its (hash, client seed, nonce) triple in your bet record.
- Rotate your seed pair in the panel. Rotation retires the old server seed and — this is the key moment — reveals it.
- Hash the revealed server seed with SHA-256 and compare it to the fingerprint from step 1. They must match exactly.
- Recompute the round: HMAC-SHA256(revealed seed, "clientSeed-nonce-cursor"), map the digest through the game’s published rule, and compare with the result you were paid on.
- Any independent tool works for steps 4–5 — an online SHA-256 calculator, three lines of Python, or the open-source provably-fair-verifier script, which uses the same byte-to-number construction as the panel. The math has no opinion about who runs it.
Limbo is the cleanest game to verify first: one uniform draw, one multiplier, instantly recomputable.Limbo →
What verification does not claim
Honesty requires marking the limits. Provably fair proves that results were fixed at commitment time and mapped through the published rule. It does not prove the rule is generous — a game could be provably fair and still pay terribly, which is why we publish every paytable and house edge alongside it. It does not prevent losses, shorten losing streaks, or make any promise about the next round; it promises only that the next round was not chosen against you.
And it cannot verify what it cannot see: the scheme covers game outcomes, not, say, the order in which live external events resolve. Where one of our games depends on an external feed, the fairness page says so explicitly rather than stretching the claim.
Glossary
| TERM | MEANING |
|---|---|
| SHA-256 | A one-way hash: any input → a 256-bit fingerprint; infeasible to reverse or collide |
| HMAC | A keyed hash — mixes a secret key (server seed) with a message (client seed-nonce-cursor) |
| Commit-reveal | Publish the fingerprint first, the value later; the fingerprint proves the value never changed |
| Nonce | “Number used once” — a counter making each round’s digest unique |
| Seed rotation | Retiring a seed pair: the old server seed is revealed for auditing, a new commitment begins |
Do I need to know cryptography to verify a round?
No. The manual path needs nothing beyond pasting strings into any SHA-256/HMAC calculator. Understanding why it works takes a paragraph; performing it takes a minute.
Why do I have to rotate my seed to verify?
Because the server seed must stay secret while it is still producing rounds — revealing it early would let a player compute future results. Rotation ends the seed’s life, which is exactly what makes it safe to reveal and audit.
Could the house generate a lucky seed for itself?
The commitment blocks the useful version of that: the seed is fixed before your bets and mixed with a client seed you control. The house would need to predict your seed, your bet, and your timing — at which point it is no longer running a casino but a mind-reading act.
Is provably fair the same as being licensed or audited?
No — they answer different questions. Audits and licenses are institutional trust; provably fair is mathematical trust in each individual result. We publish the math and our full paytables so the two claims are never confused.
- HMAC — RFC 2104, the keyed-hash construction used per round
- SHA-2 family — FIPS 180-4, the commitment hash
- Betkyo engine source: shared RNG primitives and the single generator/verifier derivation modules
- Open-source verifier: github.com/betkyo-open-labs/provably-fair-verifier
