Cryptography for gamblers

What is provably fair – seeds, hashes, nonce, and verification explained

A clear, game-agnostic guide that shows how modern crypto casinos lock results before you play and how you can verify them later.

Hash commitment before play
Client seed control
Per-bet nonce
Post-round reveal

Core idea

The casino commits to a hidden server seed with a public hash. You bring a client seed. A nonce increments per bet. After the round the server seed is revealed so anyone can recompute the result from public rules.

Why it matters

Results are locked in advance. No live tweaking. No after-the-fact rerolls. You can check the math yourself with any standard SHA-256 implementation.

What you need

  • Server seed (revealed after the round)
  • Server seed hash (published before the round)
  • Your client seed
  • Nonce for that bet

How provably fair works – step by step

1. Pre-commitment

The casino generates a random server seed and publishes its hash. Example: hash = SHA-256(serverSeed). The plain server seed stays hidden until after settlement.

2. Client seed

You pick or confirm a client seed in your browser. Keep it or change it between sessions to suit your preference.

3. Nonce

Each bet uses an incrementing nonce that starts at 0 for a fresh seed pair. It prevents output reuse and ties a unique output to every round.

4. Result computation

The game combines values like HMAC-SHA256(serverSeed, clientSeed:nonce) or SHA-256(serverSeed + clientSeed + nonce) then maps bytes to an outcome. The exact spec is published per game.

5. Reveal and verify

After settlement the server seed is revealed. You hash it to confirm it matches the pre-commitment, then recompute the outcome with your client seed and nonce.

Important: different games use different mapping rules. Dice might map a 52-bit integer to 0-99.999. Crash might turn bytes into a multiplier. Blackjack might map to a shuffled deck. Always follow the official spec on the game page.
Security tip: never share your account secrets. Seeds used for provable fairness are not passwords. They are random strings designed for audit and result generation.

Example – Dice roll mapping (JavaScript)

// Pseudo-implementation: SHA-256 -> number in [0, 99.999]
async function sha256(hexStr){
  const bytes = new TextEncoder().encode(hexStr);
  const hash = await crypto.subtle.digest('SHA-256', bytes);
  return Array.from(new Uint8Array(hash)).map(b=>b.toString(16).padStart(2,'0')).join('');
}
function toNumberFromHash(hash){
  // take first 52 bits ~ 13 hex chars
  const slice = hash.slice(0,13);
  const asInt = parseInt(slice,16);
  const max52 = Math.pow(2,52);
  return (asInt / max52) * 100; // 0 - 100
}
async function diceResult(serverSeed, clientSeed, nonce){
  const input = `${serverSeed}:${clientSeed}:${nonce}`;
  const hash = await sha256(input);
  const roll = toNumberFromHash(hash);
  return Math.min(99.999, roll);
}
        

Real games may use HMAC with the server seed as key and a documented byte slicing policy. Follow the official spec.

Example – Verify commitment (Python)

import hashlib

def sha256_hex(s: str) -> str:
    return hashlib.sha256(s.encode()).hexdigest()

server_seed = "REVEALED_AFTER_ROUND"
published_hash = "HASH_SHOWN_BEFORE_ROUND"

assert sha256_hex(server_seed) == published_hash, "Commitment mismatch"
print("Commitment verified")
        

Common mapping patterns by game type

GameHashing approachMappingNotes
DiceHMAC-SHA256(serverSeed, clientSeed:nonce)First 52 bits to 0-99.999Deterministic per nonce
CrashSHA-256 or HMAC variantTransform to multiplier curveSpec defines how to avoid bias
MinesSHA-256 streamTiles revealed by byte orderBoard layout reproducible
PlinkoHMAC-SHA256Left or right peg steps from bitsRow count affects path space
BlackjackSHA-256 based shuffleFisher-Yates seeded by bytesDeck order reproducible

Player checklist – fast verification flow

  • Copy the server seed hash before you play or confirm it is visible in the fairness panel
  • Set your client seed if the game allows it or store the auto-generated value
  • After the round copy the revealed server seed and the nonce from your bet
  • Hash the server seed to confirm the pre-commitment matches
  • Recompute the outcome using the public spec and compare to your bet result

If any step fails, contact support with your Bet ID, seeds, nonce, and screenshots of the fairness panel.

Best practices for users

  • Rotate your client seed between sessions if you prefer isolation
  • Record Bet IDs for high stakes rounds and verify later
  • Use independent tools for hashing if you want a second opinion
  • Do not confuse seeds with passwords – they are different

Red flags to avoid

  • No server seed hash before play
  • No public description of mapping from hash to result
  • Non reproducible results with the same inputs
  • Withdrawal delays tied to unclear bonus terms

Play provably fair Originals with no-wagering rewards

Use code VIP on Duel for instant cashback and audit-friendly games like Crash, Dice, Mines, Plinko, and Blackjack.

Does provably fair guarantee profit

No. It guarantees transparency, not positive expectation. Your EV depends on house edge and your choices.

Can I verify on mobile

Yes. Most modern browsers support SHA-256. You can also use external tools or simple scripts.