Provably Fair Casino Games

The server seed. Before the first bet, the casino generates a random string and keeps it secret. What it shows instead is the SHA-256 hash of that string, a fixed-length fingerprint written in hexadecimal. Hashing runs one way only: the fingerprint gives away nothing about the seed, yet no other seed produces it. Displaying the hash in advance is the commitment, because from then on the casino cannot swap the seed without the mismatch showing.

The client seed and the nonce. The client seed is a value the player can set or edit in the fairness settings. Because it is chosen after the hash is on screen, the casino could not have picked a server seed to suit it. The nonce is a counter that rises with every bet placed on the same pair of seeds, so each bet gets a different input while neither seed changes.

The computation. In the common published form, each bet runs HMAC-SHA256 with the server seed as the key and, as the message, the client seed, the nonce and a round counter joined by colons. The digest is read four bytes at a time, and each group of four becomes one number between 0 and 1: the first byte divided by 256, plus the second divided by 256 squared, plus the third divided by 256 cubed, plus the fourth divided by 256 to the fourth power. A game that needs more numbers than one digest holds, such as a mines board or a long plinko drop, moves the round counter up and computes a fresh digest.

In short: The published hash binds the casino's input before play, the client seed binds the player's, and the nonce keeps every bet distinct, so once betting starts neither side has a free choice left.

Every value can be recomputed with any SHA-256 and HMAC-SHA256 tool, entering the seeds as plain text exactly as printed. The dice, limbo and mines rows all come from this one bet: each game reads the same stream of numbers and maps it in its own way.

The bytes 42, 128, 74, 191 become 0.1660200802 because the leading byte, scaled down by a single factor of 256, supplies most of the value, and each byte after it adds a finer adjustment. The result is an evenly spread number that every game on the site can share, which is why the casino documents one conversion and then one short mapping per game.

Dice multiplies the number by 10,001, drops everything after the decimal point and divides by 100, which here gives a roll of 16.60. Limbo divides 0.99 by the number, so a small number produces a large multiplier; this one gives 5.96x. Mines uses one number per mine: the first is multiplied by the count of squares still free and rounded down, which picks a position in that list, the chosen square is taken out, and the next number picks from the squares that remain. On a 3-mine board the first three numbers of this bet place the mines on squares 5, 14, 8.

A bet can be checked only after its server seed is out in the open, which happens when the player retires the seed pair. The routine is the same for every game that uses this scheme:

1. Record the commitment. Before playing, copy the server seed hash shown in the fairness settings, and set a client seed of your own.
2. Note the bets. Play as usual. The bet history shows the nonce of each bet.
3. Rotate the seeds. Ask for a new seed pair. The casino reveals the old server seed and shows the hash of the next one.
4. Hash the revealed seed. Run it through SHA-256 and compare the output with the hash you recorded. A single different character means this is not the seed the casino committed to.
5. Recompute the bet. Run HMAC-SHA256 with the revealed seed as the key and the client seed, nonce and round as the message, turn the first four bytes into a number, and apply that game's formula.
6. Compare. The outcome should match the one in the bet history. Repeat for as many nonces as you like.

The hash comparison is the step that carries the guarantee. If the revealed seed does not lead back to the commitment, no recomputed result means anything, however well it matches.

Crash cannot use the dice method. One multiplier serves every player in a round, so no single player's client seed can feed it, and a fresh server seed for each round would leave nothing to commit to in advance. The published design fixes every round at once instead: the operator generates one secret value, hashes it, hashes that hash, and repeats the process millions of times, then announces only the last hash in the chain.

Rounds are played through the chain backwards. Each round's hash, once revealed, hashes to the previous round's hash, so any result can be traced link by link to the value announced at the start, and changing a future round would break the chain. To show that the chain was not selected from many candidates for a favorable run, the hash of a Bitcoin block that had not yet been mined when the chain was announced is mixed into every result as a salt.

In the form crash operators have published, the round hash goes through HMAC-SHA256 with that salt, the opening bits of the output become a number X between 0 and 1, and the bust point is 99 divided by one minus X, rounded down to two decimals and never below 1.00x. There is no seed for the player to set, so the check changes too: confirm that each revealed round hash leads back through the chain to the announced one, then recompute the bust point from it.

A result that checks out is a result the casino could not pick. It is not a result tilted toward the player: the payout formula, not the random number, carries the house edge, so a perfectly verified game still returns less than it takes over time.

The method covers only games whose code the casino runs and documents. Slots from outside studios and live dealer tables draw their results elsewhere, through the studio's random number generator or a real wheel and deck, and a fairness panel on the same site says nothing about them. Nor does a verified bet say anything about whether a withdrawal will be paid, which licence the casino holds or how its terms treat a balance.

The key point: Provably fair shows that a result was fixed before the bet and computed as documented. It says nothing about whether the odds are generous or whether the casino will pay.

Casinos do not all use the same mapping. Some read the digest differently, use another hash function or shuffle a board by another method, and a site can publish one formula while a game runs another. A bet is therefore verified only against the formula that casino documents for that game, and only by recomputing it; the formulas on this page are the common published form, not every casino's.