What is Provably Fair and how to test the integrity of the game

What is Provably Fair (PF)

Provably Fair is a protocol that allows you to cryptographically verify that the round result was random and could not be replaced by the operator after the bet.

The idea: first a commit is published (hash of the hidden server seed), then after the bet a revil is revealed (the server seed itself), and anyone can check the hash and reproduce the RNG, given the player's client seed and round identifiers.

Base protocol: commit → bet → reveal

1. Commit: before the start of the rounds, the server generates a random 'server _ seed' and publishes its hash:


commit = SHA-256(server_seed         salt )//or Keccak-256

Commit can be displayed in history/blockchain/journal.

2. Bet: the player selects or confirms his' client _ seed '(from UI or own), sends a bet with:


client_seed, roundId, nonce

3. Reveal: after closing bets, the server reveals' server _ seed '(and' salt'if there was) so that everyone can check:


SHA-256(server_seed         salt) = = commit//integrity check

4. RNG: randomness number is deterministic and reproducible:


rng = HMAC-SHA256(key=server_seed, msg=client_seed          roundId          nonce)
//or rng = SHA-256 (server_seed         client_seed          roundId          nonce)

5. Mapping to the outcome: convert 'rng' to the range of the game without displacement (see below).

💡 Why nonce? So that with one 'server _ seed' you can spend many rounds without the risk of predictability: 'nonce' increments each round/bet.

How to get a bias-free number

It is wrong to take 'rng% N' - this gives a modular offset if 2 ^ k is not a multiple of N. That's right - rejection sampling:

pseudo
// rng_bytes = 32 bytes hash → uint256 x = uint256 (rng_bytes)

limit = floor(2^256 / N) N while x >= limit:
rng_bytes = SHA-256 (rng_bytes )//" mix "again deterministically x = uint256 (rng_bytes)

result = x % N

So we get a uniform distribution over N outcomes (roulette cells, drum symbols, etc.).

Mini Example (Player Step Verification)

Suppose:


server_seed = "b2c6... e9 "//revealed after round (hex/utf8)
client_seed = "my-client-seed "//I selected roundId =" R-2025-10-17-001 "
nonce = 42 commit = "c9a1... f3 "//publ. in advance

1) Check commit

Count 'SHA-256 (server_seed)' and make sure it matches' commit '.

2) Deterministic RNG

Count:


rng = HMAC-SHA256(key=server_seed,          msg= client_seed          ":"          roundId          ":"          nonce)

3) Conversion to outcome

For roulette (37 numbers) → N = 37, apply rejection sampling and take 'x% 37'.

For a slot, use multiple RNG chunks to define reels/symbols according to the allocation table.

4) Check against the result in history

The site should show the same inputs that were used in the calculation: 'server _ seed', 'client _ seed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVersion'.

Alternative/Gain: VRF (Verifiable Random Function)

Instead of a commit, the operator can (or optionally) use VRF:

1. A smart contract or public registry asks the provider for'VRF (seed)'.

2. Published by '(random, proof)'.

3. Anyone can check out the'proof' by the same public VRF key pair.

4. Next, the same RNG mapping steps into the outcome.

Pros: Less trust in the operator. Disadvantages: dependence on the VRF provider/chain and possible cost.

How a casino should implement PF correctly

Contract (PF data contract)

Margins in round history:

`serverSeedHash`, `serverSeedReveal`, `clientSeed`, `roundId`, `nonce`, `hashAlgo`, `rngAlgo`, `mappingVer`, `proofUrl` (опц.) , `calcVer`.
Values - in WORM storage (immutable), with time stamps (UTC).

Seed generation

'server _ seed'is generated by cryptographic PRNG (OS CSPRNG/HSM).

Sids should never be repeated between series (rotation).

'client _ seed '- selected by the player or generated on the client and confirmed.

Publishing commits

Commits are available before bets (history, RSS, on-chain-anchor).

For lots, you can use the commit merkley tree with the root published daily.

Reveal

Before publishing the result, 'server _ seed' is expanded and logged.

For a series of rounds on one seat - disclosure after the end of the series (indicate the policy in advance).

Transparent mapping

The mapping algorithm version ('mappingVer') is fixed.

Any change ('mappingVer '/' rngAlgo') - only with an announcement and a new series of commits.

Audit and disputes

Raw inputs + computation record saved; when arguing, a report is generated: inputs → RNG → mapping → outcome.

Streams/Live: store CV/RFID event hash anchors, video in WORM.

How a player can check honesty (checklist)

1. Open the history of the round and copy: 'serverSeedReveal', 'clientSeed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVer'.

2. Count the hash'serverSeedReveal' and compare with 'serverSeedHash'.

3. Calculate the RNG according to the specified algorithm (HMAC/Hash + inputs).

4. Apply "unbiased" mapping (rejection sampling) to the number of outcomes.

5. Make sure the result is the same as shown.

6. If VRF is declared, check the'proof' ("Verify" button or independent script/block explorer).

Typical errors (anti-patterns)

'rng% N'without rejection sampling → biased probabilities.

Hidden or changing 'client _ seed' (generated by the server without the player's participation).

Re-generation of'server _ seed' after the bet (commit changes retroactively).

Opaque algorithm changes without version/publication.

Replay of sides between series.

Lack of WORM/time stamps - the order of events cannot be proved.

Mixing PF and business logic (for example, the bonus is applied in such a way that it changes the outcome space, but this is not described in 'mappingVer').

FAQ (short)

Is it possible to check slots, not just roulette?

Yes I did. PF is applied to the selection sequence (e.g., the symbol index on the reel). It is important that RNG probability tables and reading order are documented.

And if I entered my 'client _ seed', the operator can still "pick up" 'server _ seed'?

Not if the commit was posted before the bid. It fixes' server _ seed'and does not allow it to be replaced retroactively.

Why do they sometimes reveal sides in batches?

So that it was not possible to "sort out" the seed in the series. This is acceptable if the commit is published in advance and the disclosure policy is transparent.

Mini-reference formats

Hashes: SHA-256 or Keccak-256.

RNG: HMAC-SHA256 or concatenation SHA-256.

Identifiers: 'roundId' (UTC-stamp + game + increment), 'nonce' (bet counter in the series).

Версии: `rngAlgo=HMAC-SHA256@1`, `mappingVer=roulette. v2`, `calcVer=wallet-7. 2`.

Operator PF Implementation Checklist

Cryptography and Sids

CSPRNG/HSM; unique 'server _ seed', documented rotation.
'client _ seed' - controlled by the player, saved in history.

Publications and storage

Commits to bets, access to history/publication channel/anchor.
WORM storage, UTC stamps, merkley batches for scales.

Algorithms

RNG and mapping without bias; versioning'rngAlgo/mappingVer '.
Script/page "Check honesty" (open-source is desirable).

Live and Hybrid

CV/RFID/round phase hash anchors, log "when the betting window was closed."
Dispute procedures (vkhodov→iskhod report, links to commits/VRF).

Security and auditing

Independent audit of the PF protocol, bug bounty.
Decision logs are immutable; regular replay tests.

Provably Fair turns "trust us" into "check it yourself." With commit/revil or VRF, deterministic RNG, and correct non-offset mapping, any round becomes reproducible and verifiable. For a player, it's transparency and trust. For the operator - less controversy, stronger brand and compliance with regulatory requirements. The main thing is discipline: publish commits in advance, fix versions of algorithms, store evidence invariably and give the user a simple verification tool.