security
Server seed, client seed, nonce and HMAC-SHA256, explained without hand-waving. What a provably fair system proves about a result, and the much longer list of things it does not.
Provably fair is a verification method, not a promise of good outcomes. It answers one narrow question: did the casino decide the result before you placed your bet, or after? That question is worth answering. It is also a smaller question than the marketing around it suggests.
This guide explains the mechanism piece by piece, then draws a hard line around what the proof covers.
A traditional online casino runs its random number generator on its own servers. You cannot see it. You trust that a testing lab checked it, that the licensing body enforced the check, and that nobody changed the code afterwards. That chain of trust is reasonable, but it is trust, and you are outside it.
Provably fair moves the trust into arithmetic you can perform yourself. The casino commits to a secret before you bet. You supply an input it cannot predict. After the round, the casino reveals the secret, and you check that the committed secret and your input produce exactly the result you saw. If the numbers line up, the casino could not have changed the outcome once your bet was in.
Three inputs feed every result.
The server seed is a long random string the casino generates and keeps secret during play. Before you bet, the casino shows you a hash of it, usually SHA-256. A hash is a one-way fingerprint. It reveals nothing useful about the seed, but once published it cannot be walked back. If the casino later hands you a server seed whose hash does not match the one it published, it has been caught.
The client seed is your contribution. Most sites generate one for you, and every serious implementation lets you replace it with any string you like. This is the part players most often skip, and skipping it removes most of the point. If the casino chooses both seeds, it controls the whole input. Set your own client seed. Type something arbitrary. The value does not need to be clever, only unpredictable to the operator at the moment it commits to the server seed.
The nonce is a simple counter. It starts at zero or one and increments with each bet in the current seed pair. It exists so that the same two seeds produce a different result on bet one, bet two and bet three. Without it, every round on the same seeds would be identical.
The three inputs are combined using HMAC-SHA256. HMAC is a keyed hash: the server seed acts as the key, and the client seed plus nonce act as the message. The output is 256 bits, written as 64 hexadecimal characters. It is deterministic. The same three inputs always produce the same output, on any machine, forever.
That hex string then has to become a game result. Implementations differ, but the shape is consistent. The site takes a slice of the hex, converts it to a number, and maps it onto the game's outcome space.
For a dice roll between 0 and 99.99, the number is scaled into that range. For crash, it is converted into a multiplier using a formula that also removes the house edge slice. For Plinko, each of the 16 rows needs a left or right decision, so the bytes are read as a series of binary choices, and the ball's path is the sum of those 16 decisions. For Mines, the hash drives a shuffle that places the mines across the 25 tiles.
The important property is that none of these steps involve a choice. Given the seeds and the nonce, the result is already determined. The casino's server is doing arithmetic, not deciding.
A server seed stays secret while it is in use. You can only verify results after it is revealed, and it is revealed when you rotate it.
Rotation works like this. You ask for a new seed pair. The casino reveals the old server seed and publishes the hash of the next one. You now hold everything needed to check every bet made under the old seed: the revealed server seed, your client seed, and the nonce for each bet.
Two checks follow. First, hash the revealed server seed and confirm it matches the hash published before you played. Second, run the HMAC for each nonce and confirm the outputs match the results you were shown. Our fairness verifier does both, and you can also do it with a few lines of any language that has a crypto library.
Rotate often if you intend to verify. Rotate before a long session and again after it. An unverified seed pair is just a promise.
If the checks pass, you know three specific things.
The result was fixed before your bet reached the server, because the server seed was committed as a hash beforehand and your client seed was part of the input.
The result was not tailored to your bet size, your balance, your withdrawal history or how long you have been losing. The function does not take those as inputs.
The casino cannot retroactively change what happened. The published hash is a fixed point, and any altered seed fails it.
That is a real guarantee about a real category of cheating, and it is more than most regulated operators offer their players directly.
Now the limits, which are larger.
It says nothing about the house edge. A provably fair game can be honest and still priced against you, because every casino game is priced against you. Stake Originals run at 99% RTP, a 1% edge. BGaming Crash is also 99%. Spribe's Aviator is 97%, and operators may configure it to 96% or 94%. Spribe Plinko is 97%. JetX runs between 96.2% and 98.9% depending on configuration. Verification confirms the result was drawn fairly from a distribution. It does not change the distribution. The edge is the price of the entertainment, and the maths charges it whether or not you check the hash.
It says nothing about payouts. The fairness proof ends the moment the result is determined. Whether the casino credits your balance, honours a withdrawal, or applies a term you did not read is a separate matter entirely. Plenty of sites publish immaculate seed pairs and are still difficult places to get money out of. Read how to read casino terms before you deposit anywhere.
It does not cover the odds you were quoted. The hash proves the number was drawn honestly. It does not prove the paytable is what the site claimed, unless you also check that the payout for a given result matches the published table. On Mines, for example, survival across k picks with m mines is the product of (25 - m - i) / (25 - i) for each pick. If the multipliers offered do not correspond to those probabilities minus a stated edge, the game is expensive even though the shuffle is clean.
It does not cover third-party games. Provably fair systems generally apply to a site's in-house originals. Slots and live tables from external studios run on the studio's own RNG and are certified conventionally. A site can be provably fair on its own dice game and entirely opaque on everything else.
It does not cover the client seed you never changed. If the operator generated both seeds and you left the default, the commitment is weaker. Change it.
It does not make a site trustworthy. Verification is one input. Licensing, ownership, withdrawal record and terms are the others. Our methodology sets out how we weigh them.
Set your own client seed before your first bet. Copy the published server seed hash somewhere outside the site. Play. Rotate the seed when you stop, then check the revealed seed against the hash you saved and spot-check a handful of nonces in the verifier.
If the hash does not match, stop using the site and say so publicly. If it matches, you have confirmed exactly one thing: the game did not cheat you on the draw. The price of the entertainment was still the house edge, and that was charged in full.
Set a budget you are content to spend on the session, treat it as spent, and if the size of it starts to matter to you, our responsible gambling page lists the tools and helplines worth knowing about.