How Provably Fair Works

Commit, then reveal

Provably fair systems on CSGOEmpire are built around a simple order of operations: lock something in before the result needs to be trusted, show a fingerprint of that lock, play the round, then reveal enough of the secret that anyone can repeat the calculation. Official help calls this a 0% trust / 100% verification model. In practice you still have to trust that you are on csgoempire.com, that you copied the right seeds, and that you used the current algorithm rather than an outdated gist.

The commitment is usually a cryptographic hash (SHA-256 or HMAC-SHA256 in the documented recipes) or a pointer to a blockchain block that has not been produced yet. Both are ways of saying: “this input is fixed, and we cannot silently swap it after seeing the bet,” without handing the full secret to players who could otherwise predict remaining rolls.

Hashed seeds

Roulette is the cleanest daily example. At 00:00 UTC the operator generates a server seed and a public seed, pre-computes the day’s rolls, and publishes a hash of the server seed while those rolls are still being issued. Official help notes that the hashed seed appears in a warning colour on the fairness page so you can see it is not yet revealed. If it were revealed immediately, anyone could reproduce every remaining roll for the UTC day.

The following day the server seed is unhashed. You can hash the revealed value and compare it to yesterday’s commitment. Then, for a given round number, you can combine server seed, public seed and round id the way the help article specifies and see whether the colour matches history.

Case openings use a related idea with a different lifecycle. The server seed stays hashed until you rotate it on the fairness Info tab. Until you rotate, new opens keep using that seed with an incrementing nonce. After rotation, the previous seed can be checked against its hash. That is why rotating seeds is part of verification, not a decorative setting.

Future public randomness

Coinflip and case battles cannot pre-generate a day’s results the way roulette does. The set of players is not known until someone joins. Official help therefore uses the EOS blockchain: after the table is full, the site selects a block that will be mined a few seconds later and treats that block’s id as a public seed.

Nobody at the table can know that id at join time unless they can predict the chain. After the block exists, explorers can show the timestamp. Help currently mentions bloks.io and the EOS Network’s list of explorers. Combined with a private or server seed created when the round or battle started, the future block is the public half of the recipe.

Player input on cases

Paid cases, bonus cases and daily cases add a client seed: a string you can leave random or edit on the fairness Info tab. The operator still holds the server seed. Your client seed is mixed into the message that is hashed so the ticket is not solely a function of operator-held bytes.

Changing a client seed only affects opens that happen after the change, with the nonce and server seed then in force. It does not rewrite history, and it does not let you “aim” at a skin. The mapping from hash to ticket is still determined by the algorithm and the case’s ticket table.

Why each mode differs

Roulette has a continuous stream of shared rolls. One server seed plus one public seed plus an incrementing round number is enough for a whole UTC day, as long as the server seed stays hidden until the day ends.

Coinflip is a two-party (or player-versus-bot) contract that starts empty. Generating a winner at table creation would let the creator know the outcome before a challenger joined. Waiting for a join, then for a future block, is the documented fix.

Cases are per-click inventory draws with published ticket ranges. They need a nonce so sequential opens under the same seeds differ, and a client seed so the player contributed an input. Bonus cases add a case-number field because tiers share the fairness pipeline but must not collide. Battles need both EOS timing (the lobby is not full at creation) and a player-position input so each seat can be verified independently, plus a special extra round when values tie.

What a check actually does

A complete check, done on the operator’s terms, looks like this in outline: collect the revealed seeds and identifiers for one round from csgoempire.com/fairness or from round history; confirm any published hash of a secret matches the reveal; run the documented combination (concatenation plus SHA-256, or HMAC-SHA256, depending on the mode); convert the digest the way the article describes (for example first eight hex characters to an integer, then modulo 15 for roulette); compare the output to the recorded result.

If it matches, that round is consistent with the published method. If it does not, something is wrong with the inputs, the algorithm version (help notes older case scripts for dates before April 2024), or the result record. CSGOEmpire.help will not tell you which of those it is, because we do not run the check.

Limits of the pattern

Commitment schemes answer a specific accusation: “the house picked the number after seeing my bet.” They do not answer “will I come out ahead,” “is this legal where I live,” or “did a third-party lab watch this server.” They do not cover match betting. They do not make the spinner a random number generator — official case help says the spinner only displays a result that already exists.

Read the mode-specific pages next: roulette, coinflip, cases, and case battles. For seed vocabulary, see server seeds, client seeds and nonces.