Provably fair: the complete guide

The trust problem

Online, you cannot see the dice. A casino can tell you a roll was 62.41, and nothing in your browser can tell you whether that number was chosen fairly or chosen after the site saw your bet. Regulators and auditors solve this in the traditional world. Crypto gambling grew up without them, so developers looked for a cryptographic answer: let the player check the result themselves.

That is all "provably fair" originally meant. A site makes a commitment before you bet, so it cannot change its mind afterwards, and after the bet you can verify that the result follows from the commitment.

The building block: hashes

A hash function such as SHA-256 turns any input into a fixed-length fingerprint, 64 hexadecimal characters. The same input always gives the same output, a tiny change gives a completely different output, and you cannot work backwards from the output to the input. These three properties let someone commit to a secret without revealing it: publish the hash now, reveal the secret later, and anyone can check the secret matches.

You can try it with our SHA-256 generator. Hash the word "lottery" and the word "lotterz" and compare the results: one letter changes everything.

How a typical provably fair bet works

1. 1The site generates a secret server seed and shows you only its hash. That is the commitment.
2. 2You set your own client seed, or accept a random one. Because you contribute input, the site cannot choose results alone.
3. 3Each bet uses a nonce, a counter that goes up with every bet, so every bet has a different input.
4. 4The result is computed from the server seed, client seed and nonce, usually with HMAC-SHA256, then converted into the game outcome: a dice roll, a card, a crash point.
5. 5When you rotate seeds, the site reveals the old server seed. You hash it and check it matches the commitment from step 1, then recompute your bets.

Our provably fair calculator recomputes the HMAC, the number between 0 and 1 and a dice roll from your seeds and nonce, and checks the hash. Formulas differ between sites, so use the one the site publishes.

From hash to game result

HMAC-SHA256 produces 32 random-looking bytes. To make a dice roll from 0.00 to 100.00, the site takes the first few bytes and treats them as a fraction between 0 and 1. For example, four bytes b0 to b3 become b0/256 + b1/256² + b2/256³ + b3/256⁴. Multiply by 10,001 and round down to get a number from 0 to 10,000, then divide by 100. Other games use further bytes or a different mapping, for example a card from a shuffled deck or a crash multiplier from a formula with a built-in house edge.

The details matter less than the principle: the mapping is deterministic and public, so once you have the three inputs you can reproduce the output exactly.

What provably fair proves

• The server seed was fixed before your bet: it matches the hash you were shown.
• Your result was calculated from the inputs by the published formula.
• The result was not altered after the fact.

What provably fair does not prove

• That the odds or payouts are fair to you. A game can be provably fair and still have a large house edge.
• That you will be paid. Nothing in the maths forces a site to honour a winning bet.
• That every seed was handled honestly. If a site can choose server seeds after seeing your seed, or never rotates, weaknesses exist.
• That the code that displays your result is the code that computed it. Check results with your own tools.
• That the site is legal where you live.

Common weak points in implementations

Provably fair is a design, and designs can be implemented badly. Watch for sites that never reveal old server seeds, that hide the formula, that let the operator change the client seed without telling you, or that generate the client seed on the server. Others show a "verify" button that runs the site's own code, which tells you nothing: copy the inputs into an independent tool instead. A good sign is a published, documented formula with example inputs and outputs, and open-source verifiers written by third parties.

Provably fair versus a certified RNG

They answer different questions. A well-run operator has both: independent audits of the mathematics and payout rates, and player-side verification of results.

Lotteries: a stronger version of the same idea

A lottery draw differs from a dice bet in one important way: many people share the same draw. That allows a stronger design. Instead of a secret held by the operator, the random value can come from a public randomness beacon such as drand, which publishes a fresh, signed value every three seconds, produced jointly by independent organisations. Nobody, including the operator, can know a future value or change a past one.

The operator then commits to the ticket list by publishing its SHA-256 fingerprint, and the winners are a fixed calculation on the fingerprint and the beacon value. Because the random value does not come from the operator, the operator has no secret seed to abuse. And because the ticket list is published, anyone can check their own ticket is in it and recompute the draw. Our draws work this way. Read how to verify a draw step by step, or try the verify button on the Draws page.

Randomness: where it comes from

Computers are deterministic, so randomness comes from outside: physical noise, or a protocol where many parties contribute. Pseudo-random generators produce random-looking sequences from a seed and are predictable if you know the seed. Verifiable random functions (VRFs) produce a random number plus a proof that it was computed correctly, and are used by smart contracts. Beacons publish signed values on a schedule. Commit-reveal schemes let several participants combine secrets, with the weakness that the last revealer can walk away. Our verifiable randomness guide compares them in detail.

A practical checklist for any "provably fair" claim

1. 1Is the formula published, with an example you can reproduce?
2. 2Do you see the hashed server seed before you play?
3. 3Can you set your own client seed, and does the site tell you when it changes?
4. 4Does the site reveal old server seeds when you rotate?
5. 5Can you verify with a tool that is not the site's own?
6. 6Is there a public, third-party verifier?
7. 7For lotteries: is the random source independent of the operator, and is the ticket list published?
8. 8Separately: what is the payout share or house edge, and how are winnings paid?

Myths about provably fair

• "Provably fair means I will win more." It does not change your odds.
• "Provably fair means the site is safe." It says nothing about payment or legality.
• "If the hash matches, the game is fair." It means the result followed the committed inputs, nothing more.
• "Only crypto can do this." The cryptography is not specific to crypto, though crypto sites popularised it.

Try it yourself

Use the provably fair calculator with example seeds to see the HMAC and the dice roll, then change the nonce by one and watch the result change. Hash a sentence with the SHA-256 generator. Pick a verifiable random number with the drand tool. Then run a giveaway with the verifiable winner picker and recompute it on another device. Understanding the machinery once makes every "provably fair" claim easier to judge.

A complete worked example, with real values

Here is a real calculation you can reproduce in the provably fair calculator. The server seed is "cd-demo-server-seed", the client seed is "my-client-seed", the nonce is 0 and the round is 0. First the commitment the site would have shown before you played, the SHA-256 of the server seed:

SHA-256("cd-demo-server-seed")
= 3f51770c2ca429ac9afb0e57cd1665e392d75fa3cff93ab8109ef9092a681e4c

Then the bet itself

The message is "my-client-seed:0:0" and the key is the server seed. HMAC-SHA256 gives:

HMAC-SHA256(key = "cd-demo-server-seed", message = "my-client-seed:0:0")
= 5fbcfc92bf8a5a951e4fa23d176c737f6963996802bc81810f4748dc2ccb3628

first 4 bytes: 5f bc fc 92 = 95, 188, 252, 146
number = 95/256 + 188/256^2 + 252/256^3 + 146/256^4 = 0.37397746
dice roll = floor(0.37397746 x 10001) / 100 = 37.40

Changing the nonce to 1 gives a completely different hash and a roll of 21.27; nonce 2 gives 81.45. If the site showed you 37.40 for your first bet with those seeds, it was computed honestly.

Build your own verifier in a few lines

Any JavaScript runtime can do it. This snippet works in a browser console or in Node 18 and above:

async function hmacHex(key, msg) {
  const enc = new TextEncoder()
  const k = await crypto.subtle.importKey('raw', enc.encode(key), { name: 'HMAC', hash: 'SHA-256' }, false, ['sign'])
  const sig = await crypto.subtle.sign('HMAC', k, enc.encode(msg))
  return [...new Uint8Array(sig)].map((b) => b.toString(16).padStart(2, '0')).join('')
}
const hex = await hmacHex('cd-demo-server-seed', 'my-client-seed:0:0')
const bytes = hex.match(/../g).map((h) => parseInt(h, 16))
const n = [0, 1, 2, 3].reduce((a, i) => a + bytes[i] / 256 ** (i + 1), 0)
console.log(hex, n, Math.floor(n * 10001) / 100)

Red flags in a "provably fair" claim

• No published formula, or one that cannot be reproduced from the inputs.
• Seeds that never rotate, so the server seed is never revealed.
• A "verify" button that only runs the site's own code.
• Client seeds generated for you with no way to set your own.
• Claims of fairness with no information about the house edge or payouts.
• Fairness pages that are copied from other sites word for word.

Where provably fair is heading

The direction of travel is away from secrets held by the operator and toward public data. Public randomness beacons, verifiable random functions and on-chain contracts reduce what you have to take on trust, and published ticket lists let participants check inclusion. The remaining trust is about money: whether prizes are paid and funds are safe. That is why audits, licences and a record of paying still matter, and why we are open about which parts of our own system are verifiable and which depend on us.