Commit-Reveal Schemes: The Cryptographic Contract Behind Every Fair Bet

Every provably fair casino game reduces to one cryptographic move executed in two phases. Before you bet, the operator commits to a secret by showing you its hash. After you finish, the operator reveals the secret and you check that the hash matches. This is a commit-reveal scheme, and everything else in a provably fair implementation — client seeds, nonces, HMAC chains — exists to support that single exchange. Understanding what the commitment actually binds the operator to, and what it leaves open, is the difference between verifying fairness and trusting a badge.

The Two-Phase Protocol

The structure is the same across dice, crash, mines, plinko, and every other provably fair title:

• Commit phase. The casino generates a server seed — a random string — and publishes its SHA-256 hash before your first bet of the session. The seed itself stays secret.
• Betting phase. Each outcome is derived deterministically from the server seed, your client seed, and a nonce that increments per bet. You can set or change the client seed; the nonce you can observe.
• Reveal phase. When you rotate the seed pair, the casino retires the server seed and discloses it in plaintext. A new commitment is issued for the next seed.

Verification is then mechanical: hash the revealed seed and compare it against the commitment you were shown earlier, then recompute each past outcome from seed, client seed, and nonce and compare against your recorded bet history. If the hash matches and the outcomes reproduce, the operator could not have altered the seed after seeing your bets. If either fails, the session was not what it claimed to be.

Why the Hash Commitment Is the Load-Bearing Piece

The commitment works because of two properties of SHA-256 that no practical attack has broken:

• Binding. Finding a second input that hashes to the same value (a collision or second preimage) is computationally infeasible. Once the casino shows you hash(server_seed), it is locked to that one seed. It cannot retroactively pick a seed that would have produced worse outcomes for you, because no other seed matches the hash you already saw.
• Hiding. Recovering the seed from its hash (a preimage attack) is equally infeasible. You cannot read the commitment and predict future outcomes during the betting phase.

The ordering matters as much as the cryptography. The commitment is shown before you bet, and the client seed is under your control after the commitment exists. Because the operator fixed its seed before knowing yours, it cannot bias the combined derivation toward its advantage. This is why you should always set a custom client seed rather than leaving the default — a default known to the operator weakens the ordering argument, because the operator could have generated its committed seed with knowledge of the client seed it expected you to use.

What the Commitment Cannot Prove

A matching hash and reproducible outcomes prove consistency, not benevolence. Three things sit outside the scheme’s reach. First, it cannot prove the server seed was generated with good entropy — a weak RNG produces a committed seed that is still perfectly verifiable. Second, it proves nothing about unplayed outcomes beyond the deterministic chain you can recompute. Third, it does not verify the mapping from hash bytes to game result unless you recompute that mapping yourself using the documented formula; a verifier widget supplied by the operator is only trustworthy to the extent that an independent recomputation agrees with it.

Anatomy of a Verification

A complete post-session audit touches five elements. The table below is the checklist in compact form:

Step one is a single hash computation anyone can do in a browser console. Step five is where most players stop, because it requires implementing or trusting the derivation. The minimum viable audit — hash the revealed seed, check it against the commitment you saved — takes under a minute and already catches the most damaging failure mode: an operator that swaps seeds mid-stream.

Implementation Variants You Will Encounter

The core protocol is stable, but details differ across operators. Some issue a fresh commitment per session; others let one seed pair persist until you rotate it manually. Nonce conventions vary: per-bet counters, per-session counters, or combined bet-and-game counters. A minority of implementations anchor commitments on-chain, publishing the seed hash in a transaction so the timestamp is externally attested — a genuine improvement, because it removes any dispute about whether the commitment predated your bets. What matters for you is not which variant is used but whether each piece is disclosed: the hash algorithm, the derivation formula, the nonce convention, and the reveal procedure. Our guides library walks through the recomputation math for the major game types, and the casino reviews section notes where an operator’s documentation falls short of letting you verify independently.

What to Check Before You Trust the Badge

• A commitment exists before your first bet. Look for the hashed server seed in the fairness panel before wagering, and save it. If it only appears later, the ordering guarantee is gone.
• You can set the client seed. Change it from the default, ideally to something you generated. This restores the commit-then-learn ordering that makes the scheme sound.
• Rotation reveals the old seed. Trigger a rotation on a small session and confirm the reveal happens and hashes correctly. An operator that delays or complicates reveals is telling you something; related: news coverage of reveal-delay mechanics.
• The derivation is documented. A fairness page that shows a hash but not the formula used to turn it into outcomes is incomplete. You should be able to recompute at least one round by hand or script.
• Independent verifiers agree. Third-party recomputation tools are useful as a cross-check, but your own calculation outranks any of them.

None of this requires trusting the operator’s interface. It requires saving one hash, setting one seed, and running one SHA-256 — the rest is arithmetic.

FAQ

Can a casino change the server seed mid-session without me noticing?

Only if you never saved the commitment. If the hash you recorded before betting matches the seed revealed at rotation, the seed was fixed for the entire session. If the commitment displayed at any point differs from what you saved, or the reveal fails to hash to it, that is detectable proof of substitution. Saving the commitment at session start is the entire defense.

Does commit-reveal prove the outcomes were truly random?

No. It proves the outcomes were determined by a seed committed before your bets and could not have been adjusted against you afterward. Randomness quality — whether the seed had adequate entropy — is not provable from hashes alone. The practical mitigation is statistical: large outcome samples can be tested for distributional bias, which is a separate audit from seed verification.

Why must I rotate seeds before the reveal?

Because the hiding property is the only thing protecting unplayed rounds. If the casino disclosed the active server seed, anyone could compute future outcomes and bet with perfect foreknowledge. The seed is therefore only revealed once it is retired and a new commitment has replaced it. A delay between rotation and reveal is normal; a refusal to reveal at all is not.