Provably Fair Explained: Seeds, Hashes and Limits

"Provably fair" is a method for checking, after the fact, that a game's result was not altered. The operator publishes a fingerprint of a secret number before you play, then reveals the secret afterwards, and you can recompute every result to confirm it matches. It proves the operator did not change the draw. It does not prove the odds are generous, and it is not how Cashout Arcade works: our results are decided on our servers and our fairness rests on published odds, not on a per-round hash.

The idea: commit, then reveal

The core of the scheme is a promise you can check later, built from two tools:

• A hash function such as SHA-256 turns any input into a fixed-length fingerprint. The same input always gives the same fingerprint, a tiny change gives a completely different one, and nobody can work backwards from the fingerprint to the input.
• Committing to a secret means publishing its fingerprint. You cannot change the secret afterwards without the fingerprint changing, and the fingerprint reveals nothing about it.

A provably fair game runs in three steps, as summarised in Philipp Dubach's analysis of provably fair casino maths:

1. Commit. The operator picks a secret server seed and shows you only its hash.
2. Combine. Each bet mixes the server seed with a client seed you control and a nonce, a counter that increases with every bet. The result is computed from that combination.
3. Reveal. At some point the operator reveals the server seed. You hash it to check it matches the fingerprint you were shown, then recompute every bet to check each result.

If the operator had changed the server seed after seeing your bets, the hash would not match. If they had picked results to suit themselves, you could not reproduce them from the seeds.

Server seed, client seed and nonce

Each part has a job:

The client seed matters more than people think. If the operator alone chose everything, they could grind through server seeds until they found one that suits them. Letting you set the other half means they cannot know the final combination when they commit.

A worked example you can reproduce

The scheme is simple enough to run by hand. This is an illustrative example with made-up seeds, not any real casino's system.

• Server seed: demo-server-seed-0001
• Its SHA-256 hash (the commitment, published first): 2897b560ce43d71ed95d003e2d58d345a8ae2fbdfb3dc21bba0e7dd015594a03
• Client seed: my-client-seed

For each bet, compute HMAC-SHA256 with the server seed as the key and client-seed:nonce as the message. Take the first 13 hex digits (52 bits) and divide by 2^52 to get a number u between 0 and 1. Then apply the game's rule. For a crash-style game with a 3% edge, that rule is multiplier = 0.97 / u, rounded down to two decimals, with a minimum of 1.00.

(The first row shows an instant bust: 0.97 / 0.989 is below 1, so it is raised to the 1.00x floor.) Anyone with the revealed server seed and the client seed can re-run this and get the same five numbers. That is the whole mechanism. Real systems differ in the hash used and the exact conversion, so this is a model of the method, not a description of any particular site.

Notice the shape: u is uniformly random, and 0.97 / u produces the same curve that Crash games use, where the chance of reaching x is 0.97 divided by x. The Dubach article states the same property, P(multiplier at least m) = r / m for a game returning r, and notes that a 97% game reaches 2x about 48.5% of the time and 10x about 9.7% of the time.

Hash chains

Some crash games go one step further (implementations vary, so treat this as the general pattern): the operator generates a very long chain by hashing a seed, then hashing the result, millions of times, and publishes the last link first. Games are played in reverse order, so each round's hash is the preimage of the one before. Because hashing only runs forward, the operator cannot reorder or replace rounds without breaking the chain. The effect is the same as commit-and-reveal, applied round by round without waiting for a seed to rotate.

What provably fair does and does not prove

It proves:

• The result was fixed before the bet. The operator could not choose it after seeing what you did.
• Results can be audited. You can write a short script and check any past round.
• The server seed you were shown is the one used (if the commitment was published first).

It does not prove:

• That the odds are good. The formula inside the game can have any house edge. Dubach's analysis makes the point that every cash-out strategy in a fair game still has an expected return of about 3% below what you stake.
• That the implementation is correct. A mistake in the conversion from hash to outcome, or in how the seed is generated, can bias results while the verification still passes.
• That the commitment came first. If you are not shown the hash before you play, the system gives you nothing.
• That the seed is unpredictable. A server seed picked from a small set of options, or reused forever, weakens the scheme.
• That your play was safe. Provably fair says nothing about how fast you can lose.

Statistical tests of a game's published results can support a claim about the odds, but they cannot establish the cryptographic soundness of the system, and with rare big multipliers they have little power to detect small deviations.

How server-authoritative games like ours differ

Cashout Arcade is server-authoritative. Each result is decided on our server with a secure random source, the round state is stored there, and the app only displays it. There is no seed to rotate and no hash for you to recompute.

The honest position on our side: we publish every game's odds on the Odds page, we draw results server-side, we test our engines against the published figures, and you can check your own frequency against them (the RNG guide shows how). We do not offer round-by-round verification, so we do not describe our games as provably fair. See also the rigged games guide for what we can and cannot prove.

How to judge any game that claims it

1. Is the server seed's hash shown before you play, and can you set your own client seed?
2. Does the site document the exact formula from hash to result, so you can reproduce it?
3. Is there a verifier, or enough detail to write one?
4. What is the stated return? Check the formula, because a fair draw with a 10% edge is still a 10% edge.
5. Are seeds rotated and revealed on a clear schedule, or reused indefinitely?

If any answer is no, the "provably fair" label is marketing. Even if all five are yes, the label settles one question (was the draw tampered with?) and leaves the others, including the price of playing, exactly where they were.