Provably Fair 101: Seeds, Hashes and HMAC Explained

If you have ever watched a multiplier climb on a crash game and wondered whether the result was genuinely random or quietly rigged in the house’s favour, provably fair technology is the answer to that question — and it is one you can verify yourself, mathematically, without trusting anyone. This guide breaks down exactly how provably fair systems work: the server seed, the client seed, the nonce, SHA-256 hashing, and HMAC. By the end you will know how to run your own verification check on any round you have ever played.

What Does “Provably Fair” Actually Mean?

Traditional online casinos use proprietary Random Number Generators (RNGs) audited by third-party labs. You receive the result but never the receipt. Provably fair flips that model: every round produces a cryptographic receipt — a set of inputs, a function, and a mapping — that you can independently reproduce to confirm the outcome was not altered after your bet was placed.

The term is precise. “Provably” means mathematically demonstrable, not just claimed. “Fair” means the outcome was fixed before the round began and neither party could manipulate it unilaterally. Casinos such as Stake and BC.Game have built their entire product reputations on this transparency layer, publishing full verification documentation alongside every game.

One important caveat before we go further: provably fair controls outcome integrity, not house-edge pricing. A game can be 100% provably fair and still carry a 4% house edge. The technology proves the result was not manipulated — it does not guarantee you will win.

The Three Core Inputs: Server Seed, Client Seed, and Nonce

Every provably fair system is built on three inputs that are combined to generate each round’s outcome. Understanding what each one does — and why all three are necessary — is the foundation of everything else.

Server Seed

The server seed is a long random string generated by the casino before any play begins. Critically, the casino does not show you the raw server seed upfront. Instead, it shows you a hashed version of it — a 64-character fingerprint. This is the casino’s commitment. Because hashing is a one-way function, the casino cannot change the server seed after showing you the hash without you detecting it. Think of it as sealing a letter in an envelope and handing it to a notary before the game starts.

Client Seed

The client seed is a value you control. Your browser generates one automatically, but you can replace it with any string you like before a round begins. Its purpose is to ensure the casino could not have pre-calculated a losing result tailored to your session — because the casino does not know what client seed you will use until you submit it. Changing your client seed before a session is the single most impactful action a player can take to personalise their provably fair verification.

Nonce

The nonce is a monotonically increasing counter — it starts at zero and increments by exactly one for every bet you place within the same seed pair. Its job is to ensure that every single round produces a unique outcome even when the server seed and client seed remain unchanged. Without the nonce, two consecutive bets with identical seeds would produce identical results.

Together, these three inputs feed into a cryptographic function to produce the round’s outcome. No single party controls all three, which is what makes the system trustless.

SHA-256: The Digital Fingerprint

SHA-256 is the cryptographic hash function at the heart of most provably fair implementations — the same algorithm that secures every Bitcoin transaction. It takes any input of any length and produces a fixed 64-character hexadecimal string. Two properties make it ideal for provably fair systems:

• One-way: You cannot reverse a SHA-256 hash to recover the original input. Knowing the hashed server seed tells you nothing about the raw server seed.
• Deterministic: The same input always produces the same output. If the casino reveals the raw server seed after the round and you hash it yourself, you will get exactly the same 64-character string the casino showed you before play — unless something was tampered with.

The pre-game commitment flow looks like this:

1. Casino generates a raw server seed, e.g. 5b4a3c2d1e0f1a2b...
2. Casino runs it through SHA-256 and publishes the hash: 9f8e7d6c5b4a3c2d...
3. You play the round.
4. After the round, the casino reveals the raw server seed.
5. You hash it yourself using any independent SHA-256 calculator and compare.

A match proves the casino used the same seed it committed to before the round. A mismatch proves manipulation.

HMAC-SHA256: Why a Simple Hash Is Not Enough

While SHA-256 handles the pre-commitment step, most modern provably fair crash games use HMAC-SHA256 (Hash-based Message Authentication Code) to actually generate the round outcome from all three inputs. Understanding the difference matters.

A raw SHA-256 hash of a concatenated string like serverSeed + clientSeed + nonce works, but it is vulnerable to length-extension attacks and produces less stable mappings. HMAC-SHA256 uses the server seed as a key and the client seed combined with the nonce as the message, producing a keyed digest that is cryptographically stronger and more resistant to manipulation.

In pseudocode, the outcome generation looks like this:

const h = HMAC_SHA256(serverSeed, `${clientSeed}:${nonce}`);
const r = parseInt(h.slice(0, 13), 16) / 0x10000000000000;
// r is now a float between 0 and 1
// Map r to a crash multiplier, dice roll, etc.

The first 52 bits of the HMAC output are converted to a floating-point number between 0 and 1, which is then mapped to the game’s outcome range — for a crash game, this becomes the multiplier at which the round ends. Casinos publish their exact mapping formula so anyone can audit it independently.

The key distinction: SHA-256 is used for the pre-commitment hash (proving the server seed was not changed). HMAC-SHA256 is used for outcome generation (combining all three inputs into the actual result). Many implementations use both in the same round.

How Crash Games Use Provably Fair: A Worked Example

Let’s walk through a complete round on a provably fair crash game such as Aviatrix, using concrete values to make the process tangible.

Before the Round

• Server seed (raw): 5b4a3c2d1e0f1a2b3c4d5e6f9f8e7d6c
• Server seed (hashed, published to you): 9f8e7d6c5b4a3c2d1e0f1a2b3c4d5e6f
• Your client seed: alice-2025
• Nonce: 0 (your first bet with this seed pair)

The casino shows you the hashed server seed. You note it down or copy it. You can change your client seed at this point if you wish.

During the Round

The casino computes:

R = HMAC_SHA256("5b4a3c2d1e0f1a2b3c4d5e6f9f8e7d6c", "alice-2025:0")

It maps R to a crash multiplier — say the result is 3.47×. The plane flies, the multiplier climbs, and it crashes at 3.47×. You had cashed out at 2.00×, so your $10 bet returns $20.

After the Round

The casino reveals the raw server seed: 5b4a3c2d1e0f1a2b3c4d5e6f9f8e7d6c. You now have all three inputs. To verify:

1. Go to an independent SHA-256 calculator (not the casino’s built-in tool).
2. Hash the revealed server seed: SHA256("5b4a3c2d1e0f1a2b3c4d5e6f9f8e7d6c")
3. Compare the output to 9f8e7d6c5b4a3c2d1e0f1a2b3c4d5e6f — they should match exactly.
4. Then recompute HMAC_SHA256(serverSeed, "alice-2025:0") and confirm it maps to 3.47× using the casino’s published formula.

Match = Fair. The result was mathematically predetermined before your bet. Mismatch = Manipulation. The casino altered a seed after seeing your action. If you ever encounter a mismatch, stop playing immediately, capture all seeds, nonces, and bet IDs, and contact support. A properly implemented provably fair system will reconcile exactly.

Step-by-Step: How to Verify a Round Yourself

Here is the practical verification workflow you can follow after any session on a provably fair crash game.

1. Before the round: Open the Provably Fair widget (usually a shield icon or “Fairness” tab in the game interface). Copy the hashed server seed — a 64-character string. This is the casino’s commitment.
2. Optionally change your client seed to any string you choose. This ensures the casino could not have predicted your input. If you skip this, the browser generates one automatically.
3. Play the round. Note the crash point and the nonce (round number or bet counter).
4. After the round: The game reveals the unhashed server seed. You now have all three inputs: server seed, client seed, and nonce.
5. Verify independently: Use an external SHA-256 or HMAC-SHA256 calculator. Combine the inputs exactly as the game specifies in its documentation, then hash them. Compare the output to the pre-game hash you copied in Step 1.
6. Interpret the result: A match confirms the round was fair. A mismatch indicates the data was tampered with after your bet.

You do not need to verify every single bet — spot-checking sessions and any unusually large rounds is sufficient. Always retain your seed pair and nonce records to allow later audits.

Hash Chains and Seed Rotation

One subtlety that separates a robust provably fair implementation from a superficial one is the hash chain. Rather than generating a fresh independent server seed for every round, a well-designed system generates a long chain of hashes in advance, where each seed in the chain is derived from the previous one via SHA-256.

The chain is generated before any play begins, and only the final element (the hash of the last seed) is published. As rounds are played, the chain is consumed in reverse chronological order. After a seed rotation — when you change your client seed or the casino rotates its server seed — the casino reveals the raw server seed for that cycle. You can then verify the entire chain by hashing forward and confirming each link matches.

This design prevents a dishonest casino from generating multiple hash chains simultaneously and selecting the one most favourable to the house. By committing to a single chain endpoint before play, the sequence is locked. Chronological order is not just a technical detail — it is the mechanism that makes the fairness guarantee meaningful.

For players exploring newer crash titles, it is worth noting that some 2025-era releases are pushing provably fair mechanics into novel territory. Pigaboom, the first crash game with a Bonus Buy feature, combines provably fair outcome generation with purchasable bonus rounds — an interesting case study in how transparency standards can be maintained even as game mechanics become more complex.

Common Red Flags: When “Provably Fair” Is Not Really Fair

Not every casino that claims to be provably fair has implemented the system correctly. Knowing what to look for protects you from superficial or deliberately broken implementations.

• No pre-commitment hash: If the casino does not show you a hashed server seed before the round, you cannot prove it did not change the seed after seeing your bet. This is the most fundamental requirement.
• Vague algorithm description: “We use SHA-256” is not enough. The casino must specify whether it uses raw SHA-256 or HMAC-SHA256, the exact input format (order, separators, encoding), and the mapping formula from hash to game outcome.
• Naive modulo mapping: Converting a hash to a game result using simple mod N introduces statistical bias, particularly when N does not divide evenly into the hash space. Legitimate implementations use rejection sampling to eliminate this bias.
• No seed rotation or reveal log: If the casino never reveals raw server seeds or provides no history of rotations, independent verification is impossible in practice even if it is theoretically offered.
• Casino-only verification tool: Always use an independent calculator. A casino-controlled verifier could be designed to return “match” regardless of the actual inputs.

Both Stake and BC.Game publish detailed technical documentation covering their exact HMAC inputs, byte-order conventions, and mapping formulas — the standard every provably fair casino should meet.

Provably Fair vs. Traditional RNG: What the Difference Means for You

Traditional online casinos rely on proprietary RNG software certified by independent testing labs such as eCOGRA or iTech Labs. The lab audits the system and issues a certificate, but you — the player — never see the individual draw. You are trusting the audit, not verifying the result yourself.

Provably fair adds a per-round receipt. Every spin, every crash point, every dice roll comes with a set of inputs, a function, and a mapping that you can reproduce independently. The table below summarises the practical differences:

• Traditional RNG: Audited by third party. Player trusts the certificate. No per-round verification. Works for all game types including licensed slots.
• Provably Fair: Verified by the player. Cryptographic proof per round. Requires published algorithm and seed reveal. Most common in crypto-native crash, dice, and roulette games.

Neither system is inherently superior for every use case. Third-party slots from major providers are not provably fair — they use certified RNGs, and that is an accepted industry standard. Provably fair is most powerful in games where the outcome can be expressed as a single number derived from a hash: crash multipliers, dice rolls, card shuffles. Games like Aviatrix are built from the ground up with this transparency in mind.

Conclusion: Verify, Don’t Just Trust

Provably fair technology gives crash game players something genuinely rare in gambling: the ability to audit their own results with mathematical certainty. The system rests on three pillars — a server seed committed via SHA-256 hash before play, a client seed you control, and a nonce that keeps every round unique — combined through HMAC-SHA256 into an outcome no single party could have manipulated unilaterally.

The verification process takes less than two minutes once you have done it once. Copy the pre-game hash, note your client seed and nonce, wait for the server seed reveal, and run the numbers through an independent calculator. A match is mathematical proof of a fair round. That is a standard of transparency no traditional casino has ever offered.

Ready to put this into practice? Check out our full reviews of Stake and BC.Game to see how each platform implements provably fair verification, or explore our crash games directory to find titles that publish their full algorithm documentation.