One published hash, published too early to cheat
The commitment is the whole trick. The operator fixes a secret before knowing anything about your play, publishes a value derived from that secret, and can later prove the secret was the one it committed to. Everything else in the model depends on this step being done honestly and in the right order.
- Before playsha256(server seed)published as the commitment
- You chooseclient seedunder your control, editable
- Per roundhmac_sha256(seed, client + nonce)one digest per bet
- Mappingdigest to a number in rangeimplementation specific
- After rotationserver seed revealedhash must match the commitment
Why a hash instead of the seed
A hash function takes any input and returns a fixed-length output, and it is effectively impossible to run backwards: from the output you cannot recover the input, and finding a second input that produces the same output is not a practical option. That asymmetry is what a commitment needs.
Publishing the server seed itself would be useless, because anyone who read it could compute every future result. Publishing its hash instead gives two properties at once. Observers cannot derive the seed, so future results stay unknown. And the operator cannot later claim a different seed, because doing so would require finding a second input with the same hash. The seed stays secret until the reveal, and the commitment keeps it honest until then.
The order of events is the guarantee
The commitment only binds if it is published before you play, and this is the part worth checking rather than assuming. If the sequence were allowed to run the other way, with the seed chosen after your bets were known, an operator could search for a seed whose results suited the bets already placed, then publish a commitment that verifies perfectly. Every step of the arithmetic would be correct and the guarantee would be empty.
Three ordering details follow from that, and each is worth locating on a real page before you rely on any of this: the commitment must appear before the first bet of the rotation; your client seed must be settable by you and set before the bets in question; and the reveal must actually follow, exposing the server seed so the digest can be recomputed. A commitment without a reveal is a promise about a secret, not a check on a result.
The question that separates the two cases
Could the operator have produced this commitment after seeing my bets? If the answer is yes for any reason — the commitment is not timestamped, it can be edited retroactively, or the seed it commits to was not fixed in advance — then the arithmetic can still be flawless while proving nothing about your round.
What a valid commitment does not say
It does not say the mapping from digest to result is fair, because the mapping is a separate published step that the commitment does not constrain. It does not say the paytable pays what it claims, because the paytable is not in the hash. It does not say the seed you were shown is the seed that was actually used for your bet, only that it is the seed that was committed to, which is why the reveal has to be compared against the specific bets you are checking. And it does not say that a rotation you cannot inspect followed the same rules as the rotations you can.
None of that makes the commitment worthless. It makes it precise: a correctly ordered commitment closes one specific hole, the one where outcomes are chosen after the fact, and it is worth understanding exactly how large that hole was and what remains around it.
Disclosure: this page carries an affiliate link to gamdom.com/r/csgo2026. If you open an account through it we may earn a commission. It costs you nothing extra and it does not change what we write. 18+. Gambling involves risk and can cause serious financial harm. Provably fair is a transparency property, not an advantage: a verifiable result can still lose, and the house margin still applies.