Provably fair calculator & verifier

The algorithm

bytes(round) = HMAC_SHA256(key = serverSeed, msg = clientSeed + ":" + nonce + ":" + round)
              (32 bytes per round; round = 0, 1, 2 ... as more bytes are needed)
float         = b0/256 + b1/256^2 + b2/256^3 + b3/256^4      (4 bytes -> [0, 1))

dice   = floor(float * 10001) / 100                          -> 0.00 .. 100.00
limbo  = max(1, floor(1e8 / (floor(float * 1e8) + 1) * 0.99 * 100) / 100)
plinko = one float per row: floor(float * 2) = 0 left, 1 right; slot = number of rights
mines  = 25 tiles; for each mine: index = floor(float * tilesLeft), remove that tile
         (Fisher-Yates style draw without replacement; 24 floats generated, first N used)
keno   = 10 hits from squares 1-40, same draw without replacement
wheel  = segment index = floor(float * segments)   (segments 10-50; multipliers per casino table)

crash  (no player seeds - one result per round for everyone)
gameHash(n-1) = SHA256(hex text of gameHash(n)); the casino publishes the chain end first
int           = first 8 hex chars of HMAC_SHA256(key = gameHash, msg = salt) as a number
crash         = max(1, 2^32 / (int + 1) * 0.99)       (salt = a Bitcoin block hash mined later)

Server seed is used as text exactly as the casino shows it (not hex-decoded). The nonce increases by one with every bet on the same seed pair. For limbo, Stake's documentation writes 1e8 / (float * 1e8); the integer form above is what their calculator and the open-source verifier we cross-checked use, and the two only differ for extremely small floats. The final max(1, …) reflects the 1.00x minimum.

Which casinos this verifier fits

From each casino's own fairness documentation, as recorded in our profiles (alphabetical):

Crash is different

Crash has one result per round for all players, so there is no client seed or nonce. Stake announced its scheme in a public seeding post on bitcointalk(July 2019): a chain of 10,000,000 SHA-256 hashes, played from the end, salted with the hash of a Bitcoin block (584,500) that had not been mined when the post was written, so neither side could choose it. To verify a round, paste its game hash and the salt; the tool shows the crash point and the hash of the previous round. A casino can re-seed with a new chain and salt - check its current fairness page for the salt in use. More in how provably fair crash works.

Sources and how we tested this

The scheme follows Stake's public pages stake.com/provably-fair/implementation and /game-events. Those pages block automated access, so we could not fetch them directly while building this tool. Instead, our implementation is unit-tested (Node node:test) against published test vectors from two independent open-source verifiers:

• lucasholder/fair (Rust) - raw bytes across two HMAC rounds, floats, dice, limbo (including a tiny-float case its author checked against Stake's calculator), plinko for 8 and 9 rows, mines, keno, wheel and crash (including a real Stake game hash).
• KyranRana/stake-provably-fair-api (TypeScript) - HMAC values, dice, limbo, mines (24 mines) and the plinko path for 8-16 rows, for three seed pairs annotated with Stake calculator links, plus keno, wheel (10-50 segments) and three crash rounds. The "Load public test vector" button uses one of them: expected dice 77.18, limbo 1.28; for crash it loads Stake game hash 5844bf32… (expected 2.35x).

All vector tests pass. Plinko and wheel multipliers are not verified here because they depend on the casino's risk tables; the tool gives the slot or segment, which is what the seeds determine. The crash formula is quoted directly from Stake's bitcointalk post.

What verification does and does not prove

A match proves the result was fixed by seeds committed before you bet, and that the casino did not pick it after seeing your wager. It does not prove the payout table or house edge is what you think, says nothing about third-party slots, and nothing about whether the casino will pay a withdrawal. More in what provably fair means and how to verify a round yourself.