Provably fair,
explained.
The cryptography that makes a dice roll, crash multiplier, or Plinko outcome verifiable after the fact. What it proves, what it doesn’t, and how to check a hand yourself in 30 seconds.
What provably fair actually proves
A provably-fair casino lets you verify, mathematically, that the outcome of every house-game round was computed from inputs that were committed to before you played. The operator cannot retroactively change the result to their favour, because the commitment is a cryptographic hash that can only be opened one way.
The system does not prove the game has a fair RTP. It does not prove the house edge is what the operator claims. It proves one specific thing, that the dice / multiplier / tile sequence you saw was generated honestly from the seeds at hand. That is more than every legacy casino offers, and less than a true open audit.
Provably fair is integrity, not honesty. It catches operator-side tampering. It does not vouch for the operator.
Commit, reveal, verify
Three inputs control every round. The operator owns one, the player owns one, and a counter tracks bet sequence.
Inputs
server_seed ← chosen + hashed by the operator BEFORE play
client_seed ← chosen by the player (or default, you can rotate it)
nonce ← integer counter, increments each bet on the seed pair
Commit
the operator publishes H = SHA-256(server_seed) before play
this is the "commitment"; you copy it now
Play
for each bet:
raw = HMAC_SHA-256(server_seed, client_seed:nonce)
map raw bytes to the game outcome
increment nonce
Reveal
when the seed pair retires, the operator publishes server_seed
you compute SHA-256(server_seed) yourself
compare against the H you copied earlierIf the operator changed the server seed mid-stream, the hash you stored at commit time will not match the seed they reveal. That mismatch is the proof.
Mapping the bytes to a roll
Dice is the cleanest example because the output is a single number 0–99.99. Most operators use the first few bytes of the HMAC output as a rolling fraction.
Setup
server_seed = "f3a8...7c2" (operator chose, hashed = H)
client_seed = "lance-2026-04" (you chose)
nonce = 0 (first bet on this pair)
Compute
raw = HMAC_SHA256(server_seed, "lance-2026-04:0")
→ 256 bits of bytes
take first 4 bytes as uint32
→ e.g. 0x4F3A99B2 = 1,329,927,602
modulo and divide
→ roll = (1329927602 mod 10000) / 100
= 7602 / 100
= 76.02
Game payout
bet : roll under 50, payout 1.98×
roll : 76.02
outcome: loseEvery input is recoverable. After the seed pair retires, you can paste server_seed + client_seed + nonce into any HMAC-SHA-256 tool and get the same byte string. The hash of server_seed must also match the H you saved at commit time. Both checks pass, the round was honest. One fails, you have proof of tampering.
Multiplier from the same primitive
Crash uses the same HMAC output, but maps it to a multiplier through a distribution function. The most common shape is a heavy-tailed inverse:
raw = HMAC_SHA256(server_seed, "client_seed:nonce") take first 13 hex chars → e.g. 0x1F0C4A2B83E1A divide by max 13-hex → fraction in [0, 1) let h = (1 / (1 - fraction)) for the heavy tail let m = floor(h × 100) / 100 round to 2 decimals instant crashes (1.00× exactly) come from a small probability hard-coded into the function (typically 1-in-33 or 3.0%)
Two implications worth holding onto. The same server_seed + client_seed pair produces the same sequence of multipliers, every time. And the small-probability instant crash is part of the EV math, not bad luck. A 1-in-33 instant-bust rate contributes around 3% to the house edge regardless of the published RTP.
Verify any hand in under a minute
Before you place your first bet on a fresh seed pair, copy the published SHA-256 of the server seed. It is shown on every provably-fair casino under fairness or game settings.
Bet as normal. The operator increments the nonce per bet. When you are ready to verify, request a seed rotation. The old server_seed is then revealed in plaintext.
Hash the revealed server_seed yourself (any SHA-256 tool, even your terminal). It must match the commit hash. Then use the casino's verification tool to replay any individual round.
Most operators ship a self-serve verification page that accepts server_seed, client_seed, and a nonce, and shows you the resulting outcome. Stake’s, BC.Game’s, and Shuffle’s tools all work this way. If an operator says they are provably fair but does not provide such a tool, that is a yellow flag.
The honest limits
Operators with active provably-fair stacks
These operators publish their provably-fair algorithm and ship a self-serve verification tool. Coverage varies, most of them only apply provably-fair to in-house "Originals," not third-party slots.
When to care, when to move on
Use provably fair the way you would use a tamper-evident seal on a medicine bottle. It does not tell you the pills inside are good. It tells you nobody opened the bottle between the factory and you.
For house games (dice, crash, plinko, mines, limbo, hilo) provably fair is the floor. Operators that don’t offer it are choosing not to. That is information.
For third-party slots, provably fair is mostly absent. The trust signal there is provider audit (eCOGRA, GLI, BMM) and operator track record on withdrawals, not cryptography. Don’t conflate the two.