FRFair Roll commitment · seeds · nonce · digest Partner site
Fair Roll / Mechanic 04
Two different questions

Verifiable is not the same as favourable

These two ideas get merged constantly, and the merge is the most common way a transparency feature is mistaken for an advantage. One is an audit property of how a result was generated. The other is a statistical property of what the paytable pays over a long run.

  1. Before playsha256(server seed)published as the commitment
  2. You chooseclient seedunder your control, editable
  3. Per roundhmac_sha256(seed, client + nonce)one digest per bet
  4. Mappingdigest to a number in rangeimplementation specific
  5. After rotationserver seed revealedhash must match the commitment
Property A

Provably fair

Answers: was this outcome generated from the committed seed, with the inputs as published, rather than chosen after my bet? It is checked per result, using arithmetic, and it is either satisfied or it is not.

Property B

Return to player

Answers: across a very large number of rounds, what proportion of staked value does the paytable return? It is a property of probabilities and payouts, not of any single result, and it cannot be checked by hashing anything.

Why a valid digest cannot speak about the paytable

A digest is downstream of a probability distribution and upstream of a payout. It tells you which outcome was drawn. It says nothing about the probability of each outcome having been set as claimed, and nothing about how much each outcome pays. A game could use a perfectly honest generator to draw from a distribution that returns ninety percent of stakes, and every single digest would verify.

That is not a technicality, it is the substance of the distinction. The return comes from the paytable and the probabilities attached to the symbols; the commitment only fixes the sampling. When a page presents verification as evidence that play is worthwhile, it is using a genuine property of one mechanism to imply a conclusion about a different one.

What the margin means over a volume of stakes

The relevant structure is straightforward. Each stake has a distribution of outcomes, and that distribution is set so that its average return is slightly below the stake. Over a single round the difference is invisible; over a large volume of stakes it becomes the dominant term, because it applies to every unit staked rather than to a single result. Nothing about generating results verifiably changes that arithmetic.

This is also why a run of losing rounds is not evidence of a broken implementation, and why a run of winning rounds is not evidence of a favourable one. Both are ordinary samples from a distribution whose average is below the stake. Verification is simply not the instrument for judging that; the published paytable and its stated probabilities are, and even then only averaged over a volume no individual session will reach.

The honest summary

Provably fair removes one doubt, that a result was invented after the fact, and leaves the arithmetic of the paytable exactly where it was. If a game is unfavourable, it is unfavourable whether or not you can verify it, and verifying it more thoroughly will not change a single expected outcome.

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.