Guides & FAQ

Provably Fair

Gambl uses a commit-and-verify model: each completed bet is tied to a server seed hash, client seed, nonce, HMAC-SHA256 output, game rules, and payout record that can be checked for that exact round.

Last updated: 2026-08-06

Trust model The in-app verifier is a convenience tool. Full independent verification uses the revealed old server seed, client seed, nonce, algorithm version, game mapping, and payout rules to reproduce the result locally.

Summary

Before a bet, the server commits to its secret input by publishing SHA256(server seed). The player supplies a client seed, and each bet uses a changing nonce. The result source is produced with HMAC-SHA256 from those inputs.

After a server seed is rotated and revealed, anyone can check that SHA256(server seed) equals the pre-bet hash, recompute the HMAC, map the random bytes through the published game rules, and compare the result and payout with the completed bet.

Why our system is provably fair

  • The server seed hash is the operator commitment before the bet.
  • The client seed gives the player-side input to the result.
  • The nonce changes per bet so repeated seeds do not repeat the same draw.
  • HMAC-SHA256(server seed, client seed plus nonce payload) creates the outcome source.
  • Game-specific mappings convert the outcome source into the exact result and payout.

What it proves

A successful verification proves that the completed bet was generated from the committed server input, the player input, the nonce, and the published rules for that game version.

It also proves the displayed payout matches the recorded game mapping and payout calculation for that completed bet.

What it does not prove

  • It does not reveal or predict future results.
  • It does not prove a profit chance or remove the house edge.
  • It does not prove solvency, licensing, compliance, RTP audits, or external audits.
  • It does not make an in-progress unrevealed seed safe to publish.

How to verify

  • Record the server seed hash shown before the bet.
  • Keep the completed bet proof fields: Bet ID, game, client seed, nonce, round hash, algorithm version, game rules version, outcome, stake, and payout.
  • After rotation, take the revealed old server seed and confirm SHA256(server seed) equals the pre-bet server seed hash.
  • Recompute HMAC-SHA256 using the revealed server seed and the bet's client seed plus nonce payload.
  • Convert bytes to floats or game-specific random values, apply the published game mapping, then compare the result and payout.

Proof fields

  • Server seed hash: the pre-bet commitment.
  • Client seed: player-side input used for the round.
  • Nonce: changing per-bet counter or timestamp input.
  • Round hash: HMAC output for the completed round.
  • Algorithm and game rules version: the exact verifier rules to use.
  • Outcome, stake, multiplier, and payout: the public values checked by the verifier.

Security notes

Current server seeds must stay secret until they are rotated out. Revealing an active server seed would let future outcomes be computed.

Only old rotated seeds should be revealed. Once revealed, the hash commitment can be checked locally without trusting the backend verifier.

Server seed rotation

  • Manual rotation is available to signed-in players from the fairness API.
  • Auto rotation runs every 24 hours or after 10,000 bets, whichever comes first.
  • A new seed pair starts a fresh nonce sequence for new stateful rounds.
  • The old server seed is revealed after rotation as soon as no active round can still use it.
  • The reveal check is SHA256(revealed server seed) equals the server seed hash shown before the bet.

Where to verify

Use the Fairness button on a game page, a slot page, or an individual row in My Bets. Use the local verifier and published game mapping for independent verification when the old server seed has been revealed.

My Bets Casino