Provably fair explained: verify a casino roll yourself

What are the server seed, client seed and nonce actually doing?

Each input closes a different hole. The server seed is a secret random string the casino generates; publishing its SHA-256 hash first is the commitment, because a hash cannot be reversed, and nobody has a practical way to find a second string that produces the same digest, so the casino is locked to that seed from the moment it shows you the hash. The client seed is your contribution, and it exists so the operator cannot choose both halves of the input. The nonce is a counter that starts at zero or one and rises by one per bet, which is what lets a single seed pair produce an effectively unlimited sequence of distinct, independently checkable results rather than one. Combine them and the outcome for bet number n is already determined the instant you set your seed, long before you decide how much to stake on it. That is the whole mechanism: not a promise about randomness, but a promise that the number was written down first.

How do I verify a result myself, step by step?

Open the fairness or provably-fair panel before you play and copy the hashed server seed shown there. Replace the default client seed with a string you invented. Note the current nonce. Play your bets, recording the nonce and the outcome for any you intend to check. When you are finished, rotate the seed pair — this retires the current server seed and reveals it in plain text. Run SHA-256 over that revealed seed and compare the digest, character for character, to the hash you copied at the start. If it does not match, the operator swapped the seed and nothing else on the page is worth reading. If it matches, recompute the result: HMAC-SHA256 with the server seed as the key and the client seed and nonce as the message, then apply the operator's published mapping to the digest. Do the hashing somewhere the casino does not control — Python's hashlib and hmac modules, a browser console, or a third-party verifier. Using the casino's own verifier to check the casino proves nothing.

What does the arithmetic look like on a single bet?

HMAC-SHA256 returns 32 bytes, written as 64 hexadecimal characters. A dice-style original typically takes the first four bytes and reads them as a fraction between 0 and 1, each byte a digit in base 256. Suppose the first four bytes come out as 8b 1f c2 44, which in decimal is 139, 31, 194 and 68. The fraction is 139 divided by 256, plus 31 divided by 65,536, plus 194 divided by 16,777,216, plus 68 divided by 4,294,967,296. That sums to 0.54345335. A dice game mapping onto 0.00 to 100.00 then computes the floor of 0.54345335 times 10,001, which is 5,435, and divides by 100 to give a roll of 54.35. Every step is reproducible with a calculator. The mapping differs between operators and between games — card games use rejection sampling over the byte stream, crash games use a different formula entirely — so read the operator's published algorithm rather than assuming this one.

What does provably fair actually prove?

It proves the outcome of a specific bet was committed to before that bet was placed, and it proves it retroactively for every bet made under that seed pair. The practical consequences are concrete. The casino cannot see your stake and select a losing number, because the number for that nonce was already fixed. It cannot re-roll a result it dislikes, because the sequence is deterministic and the next nonce is checkable too. It cannot quietly change the outcome sequence partway through a seed's life, because the revealed seed has to hash back to the commitment made before any of it. And it cannot treat a winning account differently from a losing one within the same seed pair. That is a real, narrow, verifiable guarantee, and it is more than any conventional certified RNG offers a player directly. It is also the only guarantee the scheme provides. Everything else people assume provably fair covers, it does not.

What does provably fair not prove?

Three things, all of which cost players more money than rigged rolls ever have. It does not change the house edge: a game with a 1% edge returns 99 for every 100 staked in expectation, so 10,000 of turnover expects to cost 100 whether or not each roll is verifiable. Honest and profitable are different claims. It does not prove solvency or payment — verification concerns the random number generator, while withdrawals concern the operator's balance sheet, licence and terms. A cryptographically perfect win at a casino that freezes cash-outs is a number on a screen. And it says nothing about the bonus you accepted to fund those bets. A 100 deposit with a 100% match at 35× wagering on deposit plus bonus requires 7,000 of turnover; at a 4% house edge that is an expected 280 to clear a 100 bonus, so realistic value is minus 180. Every roll in that 7,000 can be provably fair and the offer is still negative.

Why does it matter that you pick your own client seed?

Because if you leave the default string the site generated for you, the operator chose both inputs. The commitment still binds it within that seed pair, but the pair itself was selected by a party who could, in principle, generate and test many candidate pairs offline and offer you one whose sequence it liked. Typing your own client seed after the hash is published removes that entirely: the operator committed to its half before it knew yours, so it cannot search for a favourable combination. Two related habits matter as much. Record the hash and your seed before betting rather than reading them off the panel afterwards, since a commitment shown only after the round has been settled is not a commitment. And rotate the seed pair periodically, which both forces the reveal you need in order to verify and limits how long any single sequence runs. If a site will not let you set your own client seed, its fairness page is decoration.

Which games support provably fair, and which never will?

Only games the casino builds itself. That means the house originals — dice, limbo, crash, plinko, mines, keno, hi-lo, wheel and their variants — where the operator controls the code and can publish the algorithm. Third-party slots and live dealer tables are a different trust model altogether. Slot outcomes are generated on the studio's own servers under a proprietary implementation, so the assurance comes from licensing and independent RNG certification by testing laboratories, not from a hash you can check. Live dealer games are physical equipment under camera, audited procedurally. A small number of studios have shipped provably-fair slot titles, but they are the exception; if a game came from an external provider, expect certification rather than cryptography. This matters more than it first appears, because bonus wagering terms commonly steer players onto exactly those third-party slots while originals contribute little or nothing towards the requirement. Check the contribution table in the terms — the verifiable part of the casino is often the part your bonus will not let you use.

How do crash games verify a whole history at once?

Crash and similar round-based games usually use a hash chain instead of a per-bet seed pair. The operator picks one secret value in advance and hashes it repeatedly, often thousands of times, producing a chain in which every link is the SHA-256 hash of the link after it. Only the final hash is published, before any round is played. Rounds then consume the chain in the opposite direction to how it was built, so each round's disclosed value, when hashed, must reproduce the value used for the round before it. Anyone can take a value revealed today, hash it forward through every earlier round and arrive back at the published anchor, which confirms no round was inserted, removed or reordered. The strength is coverage: one published hash secures every future round with no per-bet interaction. The weakness is that the chain was built entirely by the operator with no player input, so it proves the sequence was fixed in advance, not that the generator sampled honestly when it created it. Better implementations close part of that gap by mixing in a public value nobody controlled at commitment time, such as the hash of a Bitcoin block that had not yet been mined.

How should provably fair change what you look for in a casino?

Treat it as a filter on one failure mode, not as a rating. Rank the questions by what actually loses players money: whether the operator holds a licence and has a payment record, then what the withdrawal and bonus terms say, then whether the originals are verifiable. A casino that publishes a flawless fairness page and stalls cash-outs is worse than one that does neither. Use the verification to check what it can check — that the seed reveal hashes back to the commitment, that you can set your own client seed, that the outcome mapping is published — and use the terms to check everything else. The bonus arithmetic is on break-even table, with an interactive version at bonus calculator; the current ranking sits at global ranking, and casino matcher narrows it by what you care about. The ProvenPayouts Score is an editorial judgement, not a measurement, and worth saying plainly: a lower house edge is a slower loss, not a gain.

FAQ