Provably fair, explained

Server seed. A random string generated by the site. Kept secret during play, revealed afterward. This is the site's contribution to the result.

Client seed. A string you control, usually editable in settings. Your contribution. It's the piece that prevents the site from precomputing outcomes it likes, because it can't know your seed when it generates its own.

Nonce. A counter that increments with every bet. Ensures identical seed pairs produce different results on each roll, so one seed pair covers a whole session.

Result = HMAC-SHA256(server seed, client seed : nonce)

The output is a hexadecimal string, converted to a number, mapped onto the game's outcome range.

Before any betting, the site shows you the SHA-256 hash of the server seed — not the seed itself.

A cryptographic hash is one-way. You can't derive the seed from the hash, so the secret is safe. But the site also can't change the seed afterward, because any different seed produces a completely different hash, and you're holding the original.

That's the commitment. The site has locked in its input publicly while keeping it hidden, and it can't revise it once it sees what you staked.

When you rotate seeds, the site reveals the old server seed. You hash it yourself, confirm it matches what you were shown, and re-run every result from that session. If any outcome doesn't reproduce, the site altered something.

1. Before playing: copy the hashed server seed shown in settings.
2. Set your client seed to something you choose. Don't leave the site's default.
3. Play. The nonce increments automatically.
4. Rotate the seed when you want to verify. The old server seed is revealed.
5. Hash the revealed seed with any SHA-256 tool and confirm it matches step 1.
6. Re-run the results using the site's verifier or an independent one, with each nonce.

Step 5 is the one people skip, and it's the one that matters most. Verifying that results match the revealed seed proves nothing if the revealed seed isn't the one that was committed to. Both halves are needed.

Results were predetermined. The outcome existed before you clicked, derived from inputs locked in beforehand.

The site can't react to your bet. It can't see a large stake and adjust the outcome, because the server seed was committed before it knew.

Results weren't altered retroactively. Any change breaks the hash.

Your seed contributed. The site couldn't have selected a server seed to produce a specific outcome, because it didn't know your client seed at generation time.

Those are meaningful guarantees. The scheme is genuinely good at what it does.

That the odds are fair. A case with a 40% house edge can be flawlessly provably fair. The system verifies the roll against the stated odds; it says nothing about whether the stated odds are reasonable.

That item valuations are accurate. On case sites, published item values determine the pool's expected value. Inflate them and the case looks better than it is. Provably fair doesn't touch valuations.

That the payout table is honest. Same principle. The mapping from result to outcome is defined by the site.

That you'll be paid. Verification confirms you won. It has no bearing on whether the withdrawal processes.

That the pool is what's advertised. If a site publishes one item pool and generates against another, the verifier — which the site also wrote — will happily confirm every result. Using an independent verifier addresses this; most players don't.

The last two are the practical gaps. Provably fair is a solved problem for outcome integrity and does nothing for counterparty risk.

→Where the actual cost lives: How case site odds actually work.

This is the framing worth keeping:

A site can pass the first perfectly and fail the second badly. Most do — provably fair is cheap to implement and excellent marketing, while a wide house edge is where the revenue comes from.

The presence of provably fair tells you the operator is technically competent and cares about looking trustworthy. It's a reasonable signal. It is not a substitute for calculating what the game costs.

Common: crypto casino originals (dice, crash, plinko, mines), CS2 case sites, mystery box platforms, coinflip games.

Absent: third-party slots and live dealer games. Slot outcomes are generated by the studio's RNG under lab certification, not by the casino, so the casino can't commit to a seed it doesn't control. Live dealer results come from physical equipment.

This is why a crypto casino can offer provably fair on its in-house games and not on its slot library. It isn't inconsistency — the operator genuinely isn't generating those outcomes.

For third-party games, the equivalent assurance is testing-lab certification from eCOGRA, GLI, iTech Labs or similar. Different mechanism, similar purpose, less transparent to the player.