Updated September 2026

Provably Fair Verifier

1. Verify the seed commitment

This is the step that actually matters. Before you place a bet, the casino shows you a SHA-256 hash of a server seed it has already chosen. When you rotate your seeds, it reveals the seed itself. If the hash of the revealed seed matches what was published, the casino could not have changed the seed after seeing your bets.

2. Recompute the bet outcome

Nearly every major crypto casino derives results the same way: HMAC-SHA256 keyed with the server seed, over the message clientSeed:nonce:cursor. The output bytes are read four at a time and folded into a float between 0 and 1.

How the calculation works

Breaking it into the four steps the casino performs:

Step 1 — the commitment

The operator generates a random server seed and publishes SHA256(serverSeed). Because SHA-256 is preimage resistant, the hash reveals nothing about the seed, but the operator is now locked in: any later substitution produces a different hash.

Step 2 — the HMAC

For each bet, the operator computes:

HMAC_SHA256(key = serverSeed, message = `${clientSeed}:${nonce}:${cursor}`)

The nonce is your bet counter — it increments by one per bet, which is what makes every bet on the same seed pair produce a different result. The cursor only matters for games needing more than four bytes of randomness; for dice and limbo it stays at 0.

Step 3 — bytes to float

The HMAC gives 32 bytes. The first four are converted to a float in [0, 1) by treating them as a base-256 fraction:

float = b[0] / 256¹ + b[1] / 256² + b[2] / 256³ + b[3] / 256⁴

This is just a uniform random number with about 32 bits of precision. Using four bytes rather than one avoids the modulo bias you would get from a naive byte % 100.

Step 4 — float to outcome

This is the operator-specific part. A dice roll is typically:

roll = floor(float × 10001) / 100   → 0.00 to 100.00

A crash or limbo multiplier commonly uses the reciprocal, with the house edge applied as a direct multiplier:

multiplier = max(1, floor((1e8 / (float × 1e8 + 1)) × (1 − houseEdge) × 100) / 100)

The verifier above shows the raw float alongside both mappings, because the float is the part you can check against any operator. If your float matches but the final number does not, the mapping formula is the thing to chase — check the operator's own fairness documentation rather than assuming a generic formula applies.

What this does and does not prove

That last block is the part most sites skip. "Provably fair" is a narrow, genuine cryptographic guarantee about seed commitment. It is not a general statement that a casino is trustworthy, and it says nothing about whether you will be paid. Treat it as one input among several, not as a safety rating.

Verifying step by step

1. Rotate your seed pair first. A server seed is only revealed once retired. In most fairness panels, changing your client seed rotates the pair and exposes the old server seed.
2. Save the old hash before rotating. Once a new pair is active, some interfaces make the previous commitment harder to find. Copy it while it is on screen.
3. Check the commitment using section 1 above. If this fails, nothing else is worth doing — that is the finding.
4. Recompute a specific bet using section 2, with the exact nonce from your bet history. Off-by-one nonce errors are the single most common reason a verification "fails" when nothing is wrong.

Common verification mistakes

• Verifying against the active seed. The current server seed is not revealed yet — you can only verify retired pairs.
• Whitespace in a pasted seed. A trailing space changes the hash completely. The tool above trims input, but other calculators may not.
• Using the hash as the HMAC key. The key is the raw server seed, not its hash.
• Assuming one formula fits every site. The HMAC and float steps are near universal; the outcome mapping is not.
• Nonce starting point. Some operators start at 0, others at 1. If your result is off, try the adjacent nonce before concluding anything.

Frequently asked questions

What does provably fair actually prove?

That the casino committed to a server seed before you bet and did not swap it afterwards. It does not prove the house edge is fair, that the payout table is generous, or that the operator will pay you out.

Why does my calculated result not match the casino?

In order of likelihood: wrong nonce, seeds not yet rotated, whitespace in a pasted value, or an operator-specific outcome formula that differs from the generic one. Check that the raw float matches first — if it does, the discrepancy is purely in the mapping step.

Can a casino cheat a provably fair game?

Not by altering a committed server seed. The realistic risks sit outside the proof: how and when seeds rotate, which outcomes a float maps onto, bonus terms, and withdrawal handling.

Is it safe to paste my seeds here?

The computation runs entirely in your browser via the Web Crypto API. No request is made and no seed leaves your device — you can confirm this by opening your browser's network tab while using the tool. Retired seeds are not sensitive anyway, since they can no longer influence any bet.