Provably Fair Dice Tutorial 2026

ⓘ This article contains affiliate links. We may earn a commission if you sign up — at no cost to you. See our full disclosure.

Tobique #0000064 · Operator: Metlait SRLTested May 2026

See Wild Fortune's audit-based fairness →

TL;DR — Verifying a provably fair dice roll

Every provably fair dice roll has three inputs (server seed, client seed, nonce) and one verifiable output (the dice number 0.00-99.99). The casino publishes SHA-256(server_seed) before play; after rotation, you verify SHA-256(revealed_seed) matches the published hash, then compute HMAC-SHA-512(server_seed, client_seed:nonce), take the first 5 hex characters, convert to decimal, and divide by 1,048,576 to get a 0.0-1.0 number that maps to your dice roll. Anything not matching = seed substitution. Our Provably Fair Verifier does this end-to-end in the browser.

Quick Answer — Can the casino fake my dice roll?

No, not under correct commit-reveal protocol. The server seed hash is published BEFORE play. Once you've placed bets, the casino cannot change the seed without producing a different hash, which would fail your verification. This is the cryptographic guarantee that distinguishes provably fair from audited RNG. Wild Fortune does NOT use this protocol on its main slot library; it uses audited RNG. For provably fair dice, look at Stake, BC.Game, Rollbit, or other crypto-native casinos covered in our crypto casinos Australia and crypto casinos Canada guides.

Disambiguation: wildfortune.io and provably fair

This article does not claim wildfortune.io is provably fair. The current Wild Fortune (operated by Metlait SRL on Tobique Gaming Commission licence #0000064) uses audited RNG, similar to eCOGRA/iTech Labs-style monthly attestations rather than cryptographic per-roll verification. The closed wildfortune.com (formerly N1 Interactive on Malta MGA) also used audited RNG, not provably fair. For provably fair, the article covers Stake/BC.Game/Rollbit/Roobet protocols. For the full Wild Fortune positioning, see our provably fair master guide honest-disclosure section.

Step-by-step verification — a worked example

Step 1: Find your seed pair and nonce on the casino site

Every provably fair casino exposes the seeds in a dedicated UI screen. On Stake.com, it's under Account → Vault → Fairness. On BC.Game, it's Settings → Provably Fair. On Rollbit, it's Account → Fairness.

The screen shows three values per active seed pair:

Server seed hash — published BEFORE play, an opaque SHA-256 hex string
Client seed — your value (defaults to a random hex, but you can override)
Nonce — incrementing counter, starts at 0 and counts up per roll

The casino does NOT reveal the server seed itself until you rotate. You can rotate at any time, which closes the current seed pair and starts a new one. Only the rotated (closed) seed pair can be verified — the active one's server seed is held secret.

Step 2: Rotate the seed pair you want to verify

Click "Rotate seeds" or "Change seeds" (terminology varies by operator). The casino:

Publishes the previous server seed as plain text
Closes the seed pair to new rolls
Generates a fresh seed pair with a new hash

You now have the four values needed for verification:

The previously-published server seed hash
The newly-revealed server seed
Your client seed (the one you used)
The nonce of the specific roll you want to verify

Step 3: Verify the SHA-256 commit

Open our Provably Fair Verifier (or any browser console).

Compute SHA-256 of the revealed server seed. The output hex string MUST match the published hash exactly. If it doesn't, the casino changed the seed mid-game — that's a verification failure, full stop.

Using the Web Crypto API directly:

const enc = new TextEncoder();
const hashBuffer = await crypto.subtle.digest("SHA-256", enc.encode(server_seed));
const hashHex = Array.from(new Uint8Array(hashBuffer))
  .map(b => b.toString(16).padStart(2, "0"))
  .join("");
console.log(hashHex === published_hash); // must be true

This single check is the heart of the provably fair guarantee. The math is one-way: given a SHA-256 hash, finding a different input that produces the same hash is computationally infeasible (~2^128 operations on average, even with quantum-aware Grover's algorithm assumptions). The casino is bound to the original server seed by the published hash.

Step 4: Compute HMAC-SHA-512 to get the dice outcome

The dice outcome is computed via HMAC-SHA-512 with the server seed as key and client_seed:nonce as message.

const enc = new TextEncoder();
const keyBuffer = await crypto.subtle.importKey(
  "raw", enc.encode(server_seed),
  { name: "HMAC", hash: "SHA-512" },
  false, ["sign"]
);
const sigBuffer = await crypto.subtle.sign(
  "HMAC", keyBuffer, enc.encode(`${client_seed}:${nonce}`)
);
const hmacHex = Array.from(new Uint8Array(sigBuffer))
  .map(b => b.toString(16).padStart(2, "0"))
  .join("");

The output is a 128-character hex string. Each 5-character slice is interpreted as an integer, divided by 16^5 = 1,048,576 to produce a [0.0, 1.0) float, then mapped to game outcome.

For dice (0.00-99.99 range):

const firstFiveHex = hmacHex.slice(0, 5);
const intValue = parseInt(firstFiveHex, 16);
const decimal = intValue / Math.pow(16, 5);
const diceRoll = Math.floor(decimal * 10000) / 100;

diceRoll is your verifiable dice outcome. If your bet was "roll under 50.00" and the dice rolled 28.43, you won.

Step 5: Compare with what the casino displayed

The number you compute MUST exactly match the dice roll the casino showed in your bet history. If it does, the casino played fair on that roll. If it doesn't, something is wrong — usually it's a transcription error (wrong nonce, wrong seed pair), occasionally it's a real verification failure that should be reported.

House edge in provably fair dice — where does the 1% come from?

Provably fair dice has a 1% house edge baked in to the bet payout structure, not the RNG.

Consider Stake's classic "roll under" dice. You pick a target between 1.00 and 98.99 (for example, 50.00 — "roll under 50"). Your win probability and payout multiplier are:

Win probability = target / 100
Payout multiplier = 99 / target

For "roll under 50": win prob = 50%, payout = 99/50 = 1.98×.

A fair coin flip would pay 2.0× on a 50% win probability. Stake pays 1.98× — that 1% gap is the house edge.

Expected value per dollar bet:

EV = (Win_prob × Payout) − 1
   = (0.50 × 1.98) − 1
   = 0.99 − 1
   = − 0.01

The math is identical across all target values:

Target	Win prob	Payout	EV per dollar
5.00	5%	19.8×	-1%
10.00	10%	9.9×	-1%
50.00	50%	1.98×	-1%
80.00	80%	1.2375×	-1%
98.99	98.99%	1.0001×	-1%

The 1% house edge is constant regardless of how you bet. The RNG (provably fair HMAC-SHA-512) is mathematically random; the operator's margin comes from the payout formula. Provably fair verifies the randomness; it does not affect the edge.

This is important to understand because some affiliate content positions provably fair as "lower house edge than slots." That's a category error. Provably fair guarantees the RNG isn't manipulated; the operator still sets the payout structure however it wants, and 1% house edge is the industry-standard target for crypto-native dice games.

What provably fair dice does NOT prove

Three things the protocol cannot guarantee:

The displayed dice value is right. The protocol verifies the cryptographic output; the casino front-end translates that output to the visual dice. If a casino displays "you rolled 49.99" on a "roll under 50" bet but the HMAC-SHA-512 actually says 50.01, the bet was a loss disguised as a win. Verification with our Provably Fair Verifier is the only way to confirm display integrity.
The bet was placed at the price you saw. Provably fair dice does not address front-running, where the operator could match your bet against a known outcome. The defence here is operator reputation and the requirement that the server seed hash be public before any client_seed is set.
The casino will pay your withdrawal. Provably fair math is silent on operator solvency, withdrawal queue games, KYC delay tactics, or exit scams. A provably fair casino can still go offline tomorrow with your balance. This is why withdrawal-test data (see our USDT TRC-20 deposits test) matters in parallel.

Stake vs BC.Game vs Rollbit dice — side-by-side comparison

Feature	Stake	BC.Game	Rollbit
House edge	1%	1%	1%
RNG primitive	HMAC-SHA-512	HMAC-SHA-512	HMAC-SHA-256
Server seed hash publication	Yes, pre-game	Yes, pre-game	Yes, pre-game
Client seed control	Yes	Yes	Yes
Rotation cooldown	Instant	Instant	Instant
Min bet	$0.0001	$0.0001	$0.0001
Max bet	$50,000	$25,000	$10,000
Verification UI in-app	Yes (Vault)	Yes	Yes
API export	Yes (bet history JSON)	Yes	Limited

All three operators use the canonical commit-reveal pattern. The Rollbit HMAC-SHA-256 variant produces 64 hex characters instead of 128 (so fewer rolls per HMAC call), but the cryptographic guarantee is equivalent.

For first-time provably fair users, Stake.com has the best verification UX — the Vault screen exposes everything needed in one place, and the bet history JSON export makes batch verification possible. BC.Game is close behind but has a less intuitive UI. Rollbit works but requires more clicks.

Why slots cannot do this — a quick aside

Slots use proprietary game engines tied to a server-side RNG that controls reel mechanics. The pseudo-random number generated for a spin is internal to the operator's slot software (NetEnt, Pragmatic Play, BGaming, etc.). Even if the operator publishes a hash before play, the operator controls the mapping from RNG output to reel position, bonus trigger, and free-spin payout.

A slot could theoretically be made provably fair if the operator published the RNG output AND the complete mapping function. In practice, slot vendors treat the mapping function as proprietary, so verification stops at the unverifiable internal step.

The exception: a small number of crypto-native slots use Chainlink VRF (Verifiable Random Function) to generate the seed on a public blockchain. Even there, the reel mapping is still operator-controlled — Chainlink VRF only solves the seed-trust problem, not the mapping problem.

For full details on this and the four cryptographic primitives involved, see the Provably Fair Master Guide.

Frequently asked questions

What is HMAC-SHA-512?

A keyed hash construction defined by RFC 2104. It takes a secret key (server seed) and a message (client seed + nonce) and produces a deterministic 512-bit output that cannot be forged without knowing the key. The 512-bit output is 128 hex characters, providing enough randomness for many independent dice rolls per call.

Can I verify a dice roll without our tool?

Yes. The math runs in any browser console with the Web Crypto API. Our Provably Fair Verifier just wraps this with a UI. The underlying primitives are open and the source code patterns are widely published.

What if my computed dice roll doesn't match?

First, double-check inputs: server seed (revealed, not hash), client seed (your value, case-sensitive), nonce (exact integer the bet used). Most "verification failures" are input errors. If inputs are correct and outputs still mismatch, document the discrepancy and report to the operator — it's a real fairness violation.

Is 1% house edge low?

Yes, relative to other casino verticals. Slots run 2-5% house edge typically. Live dealer roulette is ~2.7% (European, single-zero). Provably fair dice at 1% is genuinely one of the lower-edge offerings in casino games, though baccarat and blackjack with perfect basic strategy can be lower still.

Why use HMAC-SHA-512 instead of just SHA-256?

HMAC provides resistance to length-extension attacks that plain SHA-256 doesn't. Without HMAC, a malicious operator could in theory extend the message to produce attacker-favourable outcomes. HMAC blocks that vulnerability. RFC 2104 is the authoritative source.

Can I run this verification offline?

Yes. The Web Crypto API runs entirely client-side. Our tool makes no network calls during computation. You can disconnect your internet and the verifier still works.

Does Wild Fortune offer provably fair dice?

No. Wild Fortune does not offer provably fair dice games. Its game library is conventional slots and live casino with audited RNG. For provably fair dice, use Stake.com, BC.Game, Rollbit, or other crypto-native casinos covered in our crypto casinos AU guide and crypto casinos CA guide.

Can the casino cheat by picking a favourable server seed before publishing the hash?

In theory yes — the casino picks the server seed it wants and publishes its hash. But the casino can't know your client seed in advance, and the HMAC depends on both. So the casino would need to test many server seeds against many possible client seeds and pick one that produces an attacker-favourable distribution. The combinatorial space is too large for this to be feasible — a single hash takes microseconds but the search space is 2^256. Combined with the rotation pattern (where you change client seed frequently), the attack is computationally infeasible.

Provably Fair Dice Tutorial 2026 — Verify a Stake / BC.Game Roll in Your Browser