Provably fair, implemented: HMAC, seed rotation and how to verify any casino

Our earlier article covered what provably fair means for operators. This one goes a level deeper: how the mechanism is actually implemented in production code, and how you — as a player, an operator, or a buyer evaluating a casino script — can verify an implementation instead of trusting a badge.

The commit-reveal contract

The entire system rests on one cryptographic promise: the casino commits to its randomness before any bet, and reveals it after, so the player can check that nothing changed in between.

Before betting, the player sees: SHA-256(serverSeed) — the commitment.
Each bet computes: HMAC-SHA256(serverSeed, clientSeed + ":" + nonce) — the roll.
After rotation, the player receives: serverSeed — the reveal.

Because the hash was published first, the casino cannot swap the server seed after seeing bets. Because the player controls the client seed, the casino cannot precompute favorable outcomes. Because the nonce increments per bet, every roll in a session is distinct and independently checkable.

From digest to dice roll

The HMAC digest is 32 bytes; the game takes the first bytes and maps them to a result. A dice roll, for example, takes four bytes as an integer and reduces it into the 0–9999 range for a 0.00–99.99 roll. Two implementation details separate correct code from subtly rigged-looking code: the reduction must avoid modulo bias (naively taking x mod 10000 over a range not divisible by 10000 makes low numbers fractionally more likely), and results must be derived from integer math, never floats. These are exactly the details we battle-tested in our own production casino before this engine shipped in the script.

Seed rotation done right

A player can rotate at any time: the current server seed is retired and revealed, a new seed is generated and only its hash is shown, and the nonce resets. Every historic bet under the old seed becomes verifiable that instant. An implementation that reveals seeds only "on request", or never resets nonces, or shows no pre-bet hash at all, is decorative fairness — and worth walking away from.

How to audit any casino in five minutes

• Is a server-seed hash visible before you bet? No hash, no commitment.
• Can you edit your client seed? If not, the casino controls both inputs.
• Rotate the seed: is the old seed revealed immediately?
• Recompute one bet yourself — any HMAC-SHA256 tool works — and compare against the game history.
• Hash the revealed seed and compare with the commitment you saw at the start.

If all five pass, the math is honest regardless of what you think of the operator.

Why this matters commercially

Crypto players check. Communities publish verifier tools, and a casino that fails a public verification is finished overnight. That is why fairness cannot be a skin-deep feature bolted onto a template: it has to be the core of the game engine, with the verification page proving it in public. Our platform ships exactly that — the same engine, hash chain and verifier we run in production — and you can click through it on the live demo before ever buying the licence. Questions about the implementation? Ask us the hard ones — we enjoy those.