Understanding Provably Fair on Stake

In a conventional online game, the player sees the result but cannot check how it was selected. Provably fair adds verifiable proof: before the game, the casino commits to a secret value; after that value is revealed, the player can recalculate the result and verify that the commitment did not change.

The system does not make the game favourable. It answers a more precise question: “Does the announced result match the data committed before my bet?”

The sealed-envelope analogy

Imagine that Stake places a secret number in an envelope and shows you the envelope's unique fingerprint. You add your own number, then each game receives a sequence number. These elements are combined to produce a result.

Later, Stake opens the envelope. You can verify that its contents produce the fingerprint shown at the start, then repeat the calculation. The hash acts as the fingerprint; the server seed is the secret inside the envelope; the client seed is your contribution; and the nonce is the sequence number.

The elements used in the calculation

Server seed

The server seed is a long random value generated by Stake. While it is active, only its hashed version is visible. Publishing the complete seed before the games would make it possible to calculate results in advance; showing no prior trace would allow the server to replace it afterwards. The hash resolves this dilemma by acting as a commitment.

When the player rotates or replaces the seed pair, the previous server seed is revealed. It then becomes possible to check that its hash matches the one displayed before the bets.

Client seed

The client seed is the player's contribution. The browser may generate one during registration, and the interface generally allows it to be changed. It prevents the server from being the sole source of the data used in the calculation.

Choosing your own client seed does not let you select a winning result: the complete server seed remains unknown during the series.

Nonce

The nonce is a counter that increases with every bet placed using the same seed pair. It allows two successive games to use different inputs without requiring a new pair to be created for every click.

Hash and HMAC-SHA256

A cryptographic hash turns data into a fixed-length fingerprint. A tiny change produces a different fingerprint. Stake uses HMAC-SHA256 to combine the server seed with the client seed, the nonce and, when the game requires more values, a cursor.

The raw result is a sequence of bytes. It is then converted into numbers between 0 and 1, and translated according to the game's rules: mine positions, cards, squares or other events.

How a result is generated

For a verifiable bet, the process follows this logic:

1. Stake has already published the hash of the secret server seed.
2. The client seed and the bet's nonce are known.
3. HMAC-SHA256 combines these values and produces deterministic bytes.
4. The bytes become numbers that the game can use.
5. The rules specific to the game turn these numbers into a visible event.

With exactly the same inputs and the same method, the calculation will always produce the same result. This property makes verification possible.

Verifying a game afterwards

Open the bet history or details and note the client seed, nonce, committed hash and game data. Then rotate the seed pair to reveal the previous server seed.

In the provably fair verifier, enter the values from the game. First check that the revealed server seed produces the original hash, then compare the recalculated result with the one in the history. A different nonce, order or game version is enough to make the check fail; copy the data again before concluding that there is an anomaly.

What provably fair proves — and what it does not

It lets you verify that a result matches the committed seeds and counter, and that the server seed was not replaced after the bet without its hash changing.

It guarantees neither a win, nor a favourable RTP over a short session, nor account security, nor the legality of the service in a country. It also does not allow future results to be predicted while the server seed remains secret. Provably fair is proof of draw integrity, not a gambling strategy.

Stake Originals such as Mines, Pump or Chicken apply this logic to their own events. Their payout tables describe the multipliers, while provably fair explains how the positions or events in a game can be reproduced.

Frequently asked questions

Why is the server seed not revealed before the game?

Because the client could then calculate future results. Stake publishes its hash first, then reveals the seed after rotation to allow retrospective verification.

Does changing the client seed increase the chances of winning?

No. It creates a new deterministic chain of results without changing the game's mathematical edge.