What are provably fair games? A player’s introduction

A common approach: commit, play, reveal, verify.

Implementations differ, but a common model uses a server seed, a client seed, and a round counter called a nonce. Before play, the operator publishes a hash of the secret server seed. This acts as a commitment that can be checked when the seed is later revealed.

1. Commit. Save the server-seed hash shown before the round.
2. Play. The published method combines the inputs to produce a game result.
3. Reveal. The operator reveals the server seed later, often after a seed change.
4. Verify. Check the revealed seed against the saved hash, then reproduce the result with the recorded inputs and game rules.

For a concrete example of this model, see Stake’s published implementation. It is an example from another platform, not the specification for StackRoll or SlabRoll.

Server seed, client seed, hashed seed and nonce: a glossary.

These four terms describe the inputs many provably fair systems use to produce a result and check it later. Implementations differ, so the documentation for a specific game is what counts.

• Server seed. A secret random value generated by the operator. It stays hidden during play so results can’t be worked out in advance, and is revealed later so they can be checked.
• Hashed server seed. A one-way fingerprint of the server seed, often made with SHA-256, shown before play. It commits the operator to that seed without revealing it. When the seed is revealed, hashing it should reproduce the same fingerprint.
• Client seed. A value from the player, or set on the player’s behalf, that is combined with the server seed. It means the result does not depend on the operator’s input alone.
• Nonce. A round counter, usually increasing by one with each round played on the same seed pair, so each round produces a different result.

These are general definitions, not a specification. StackRoll’s own inputs and method have not been published.

A verification label should lead somewhere.

Imagine you have finished a round and want to understand the result. A useful game explanation should tell you what to save, when the missing information becomes available, and where to run the check. If the explanation only says “provably fair,” you are still missing the practical steps.

For StackRoll, those are the questions we want our game documentation to answer. We also want to explain how the calculated result maps to what the player sees, rather than leave a gap between a technical output and the game.

What it does not tell you.

A verification method checks a defined part of a system. It is not a promise of a winning result or a substitute for reading the game’s odds and reward rules.

With a collectible game, there are other questions too: which card is involved, what its stated grade is, and how a reward is fulfilled. A reproducible game result does not, by itself, answer those questions. Our SlabRoll introduction separates the confirmed concept from the details still to be revealed.

Can provably fair be rigged?

Provably fair verification can show that a result matches a commitment made before you played. It cannot, on its own, show that everything about a game or platform is fair, so it narrows what can be manipulated rather than removing the need for trust.

What a passing check shows: the server seed revealed after play matches the hash shown before it, and the result can be reproduced from the recorded inputs using the published method. Swapping the seed after seeing a bet would make that check fail.

What it does not show on its own:

• How the server seed was chosen. Order matters. If an operator could see a player’s client seed before committing to a server seed, it could in principle pick a seed with a known outcome and still pass the hash check.
• How the output becomes a result. The step that turns a calculated number into a card, multiplier, or outcome needs to be published and checkable too.
• Rounds nobody checks. Verification covers the rounds someone actually verifies.
• Everything outside the round. Odds, payouts, withdrawals, and fulfilment are separate questions.

When StackRoll publishes its implementation, we will need to explain what it covers and what it does not, in the same plain terms.

Does provably fair mean fair odds?

No. Provably fair is about integrity: whether a result was produced by the stated method. It does not tell you whether the odds favour the player, and a game can be fully verifiable and still have a house edge.

Two terms help separate the ideas. RTP (return to player) is the share of total wagers a game is designed to return over a very large number of rounds. The house edge is the rest. As an illustration only, a game designed with 99% RTP has a 1% house edge. Both are set by a game’s rules and payout table, not by its seeds or hashes, and short-term results can differ widely from either figure.

Collectible games add another layer: the value of a result also depends on how card values are set and what any cash alternative is.

The odds, RTP, and reward rules for StackRoll Originals and SlabRoll have not been published. Before anyone plays, those rules will need to be clear, alongside the verification method.

Where StackRoll stands today.

Provably fair mechanics are part of the plan for StackRoll Originals and SlabRoll. The implementation, verifier, and detailed rules have not been published on this preview. We will need to explain the actual system when those details are ready; this guide introduces the concept only.

Flap Off is a separate free-play game with demo multipliers. It has no wagers or prizes, and this article does not claim it is a verified provably fair casino game.