How the Provably Fair Algorithm Actually Works

A provably fair algorithm lets you check, after the fact, that a game result was not altered once you placed your bet. The mechanism behind that claim is called hash-commit-reveal: the platform commits to a secret value before the round by publishing its hash, then reveals the value afterward so you can recompute that same hash yourself. Add a client seed you control and a nonce that increments with every bet, and you get a system where a casino cannot quietly change an outcome after seeing what you wagered on, at least not without producing a hash mismatch you could catch. This guide goes one level deeper than the general "what is provably fair" explanation: what a one-way hash function mathematically guarantees, the real difference between a plain hash commitment and a true HMAC-keyed scheme, why a nonce is structurally necessary, and a worked example simple enough to follow and recompute by hand.

What Provably Fair Actually Guarantees, in Plain Terms

Provably fair is a narrower claim than it sounds. It guarantees one specific thing: the inputs that determined your result existed, in fixed form, before your bet was placed, and did not change afterward. It does not guarantee that the game is generous, that the house edge is small, or that every detail of how a hash maps to an outcome is publicly documented for every game type.

The guarantee rests on a property of cryptographic hash functions called pre-image resistance: given a hash output, it is computationally infeasible to find a different input that produces that same output. A platform cannot generate a result, see how you bet, and then swap in a more favorable secret value, because that new value would need to produce the exact same hash already published to you, and finding one is not practically possible with current computing power. That single property is what turns "trust us" into something you can actually check.

The Three Inputs: Server Seed, Client Seed, Nonce

Nearly every implementation of this mechanism, across different platforms and game studios, is built from the same three inputs, combined to determine a single round's result.

The server seed is a random value the platform generates before a session or a batch of rounds begins. Its hash is published to you immediately; the seed itself stays hidden until it is rotated out or the session ends. The client seed is a value you can typically set or rotate yourself, often from an in-game fairness menu, giving you a genuine input into the outcome rather than a purely cosmetic one. The nonce is a simple counter, usually starting at zero or one, that increases by exactly one with every bet placed against the same seed pair.

Combined, these three inputs feed into a function that produces the round's result. Change any one of them, the server seed, the client seed, or the nonce, and the output changes completely, which is exactly why all three need to be public and checkable, not just the final result.

The Commitment Step: Why the Hash Comes Before You Bet

Sequencing is the entire point of this mechanism. Before you place a bet, the platform generates the server seed and publishes only its hash, never the seed itself. That published hash is the commitment: a mathematical promise about a value that stays hidden, made in a form that cannot be altered without detection.

You then place your bet. Because the platform already committed to the hash before it saw your action, it has no way to change the underlying server seed to produce a friendlier result for itself. Any attempt to do so would produce a server seed whose hash no longer matches what was already shown to you, an immediate, checkable mismatch. This is why the order matters so much: a hash published after the bet proves nothing, since nothing yet stops the value being adjusted right up until the moment it is shown.

Plain Hash vs HMAC: Two Ways the Industry Implements the Same Idea

Not every provably fair system builds its commitment the same way, and the distinction is more precise than most explanations of "hashing" bother to make. A plain hash commitment takes a single concatenated string, for example a result value joined with a secret, and runs it through a function like SHA-256 to produce one fixed output. BGaming, a game studio whose own public provably fair documentation is a useful named example of this approach, describes exactly this: SHA-256 applied to a concatenated result-and-secret string, verified with worked examples across roulette, card games, and slots.

An HMAC, short for Hash-based Message Authentication Code, is a different, keyed construction. Rather than simply hashing a concatenated string, it combines a secret key with a message through a defined algorithm built specifically for message authentication, not just data-integrity hashing. Both approaches can secure a valid commitment scheme. They are not interchangeable terms, though, and a system's actual documentation, not a generic description of "hashing," is what tells you which one it uses. Treat any explainer that never distinguishes the two, including some of the most-cited ones online, as incomplete rather than wrong.

How the Reveal and Verification Work

Once a round or session ends, or whenever you rotate your seed pair, the previously hidden server seed is revealed. At that point, verification becomes a task anyone can do without special tools: hash the newly revealed server seed with the same function used for the original commitment and confirm the output matches what was published before your bet. If it matches, the seed was not swapped.

From there, the same server seed, your client seed, and the specific nonce for that round are combined using the platform's documented method to reproduce the round's outcome. If the recomputed outcome matches what you saw during play, the result was determined by fixed, already-committed inputs, not adjusted after your bet landed. Most platforms bundle this into a built-in verifier tool, but the underlying math does not require one, which matters more than it might first appear.

A Worked Example: Verifying One Round By Hand

This example uses a simplified, illustrative setup, not any single platform's exact real-world implementation, so you can follow every step and recompute the same values yourself with any SHA-256 tool or a browser console.

Say the server seed is the text string `flush-demo-server-seed-2026-a1`. Before any bet, its SHA-256 hash is computed and published as the commitment:

`797263e7c38a17a978cf114a1a81170767a3804d6e428b2753f7a82475eab80e`

You bet using the client seed `lucky-player-7` and nonce `1`, the first bet on this seed pair. After the round, the server seed is revealed as the same text string shown above. First, recompute its SHA-256 hash yourself: it produces the identical string published earlier, confirming the seed was not swapped after your bet.

Next, combine the three inputs into one string, `flush-demo-server-seed-2026-a1:lucky-player-7:1`, and hash that combined string with SHA-256. It produces:

`fa94b69baa55ec601af53a8c6355f438186b30bc760c70a08b4439e60de98455`

Taking the first eight hex characters of that output, `fa94b69b`, and converting them to a plain integer gives 4,204,050,075. Taking that number modulo 100 gives 75, a simple illustrative way to map a hash to a bounded outcome, the same basic principle a game would use to map a hash to a reel position, a multiplier, or a card. Change only the nonce to `2` for the next bet on the same seed pair, and the combined string, hash, and resulting outcome all change completely, landing on 65 instead. That is the nonce doing its job: same seed pair, different bet, genuinely different, independently checkable result every time.

Why the Math Can't Be Faked, and What It Doesn't Prove

The reason this sequence resists tampering comes back to pre-image resistance. Once a hash is published, finding a different input that produces that exact same hash is not something brute-force computing makes practical, even at large scale. That is what makes the commitment step meaningful rather than decorative: the platform is genuinely locked into whatever value it already committed to.

What this does not prove is broader than many explanations acknowledge. It does not prove the house edge on a given game is fair, small, or disclosed. It does not prove that the specific formula mapping a hash to a game's actual outcome, the part unique to each game type, is public. A hash commitment can be perfectly sound while a platform's per-game outcome-mapping logic remains proprietary and unverifiable by an outsider, and those are genuinely two separate claims worth keeping distinct in your own head, not one bundled guarantee.

Where the Skepticism Comes From (and When It's Justified)

Real, searched skepticism about provably fair systems exists online, and dismissing it outright would be less honest than engaging with it. The most common version of the criticism conflates two different ideas: "provably fair" and "actually fair" are not the same claim. Provably fair means a result was not manipulated after your bet. It says nothing about whether the house edge built into the game itself is reasonable, a completely separate question that provably fair mechanics were never designed to answer.

A second, more concrete version of the skepticism is better founded. Independent testing of multiple platforms advertising provably fair play has found real, practical gaps: verifier tools that were broken or under maintenance, and in some cases no genuine independent verification system behind the marketing claim at all. That is a legitimate reason for caution, and it points at implementation quality rather than at a flaw in the underlying cryptography itself. A third, narrower point worth understanding on its own: some providers keep their exact per-game outcome-mapping formula proprietary even while their hash commitment process is fully documented. Data integrity and formula transparency are two different things a provider can offer independently of each other.

How Flush Implements the Mechanism

Flush applies this same hash-commit-reveal structure across all 18 games in its in-house Originals catalogue, including Crash, Dice, Mines, Plinko, Keno, Blackjack, Roulette, Baccarat, and the rest of the lineup. A server seed is generated before play and immediately hashed, with that hash shown to you as the commitment before any bet is placed. The original server seed stays hidden until you rotate your seed pair or the session ends. You can set and rotate your own client seed from Flush's in-game fairness menu at any time, and a nonce increments with every bet placed against the current seed pair, exactly as described throughout this guide.

Flush documents this using a cryptographic hash function combined with your client seed, server seed, and nonce; this guide describes that mechanism generically rather than asserting a specific algorithm name as confirmed fact, since the fullest technical detail sits on Flush's own fairness page, which is the definitive source to check directly for the current implementation. A built-in fairness tool lets you verify a previous round's seed and outcome without leaving the game. This mechanism covers Flush's own Originals specifically; third-party slots and live-dealer tables run on independently certified RNGs audited by bodies including Gaming Laboratories International, iTech Labs, and eCOGRA, a different but equally valid fairness model covered in more depth in our guide to what provably fair actually means.

What Flush Asks of You

Beyond setting or rotating your own client seed, nothing extra is required to benefit from this mechanism. Every Originals round you play is already using the committed hash sequence described above, whether or not you ever open the fairness menu to check it. If you want the practical, game-by-game version of this, which button to press and what a verifier tool actually shows you for crash, dice, mines, plinko, and keno specifically, our companion guide on verifying provably fair Bitcoin games walks through each one directly. You can explore Flush's current game lobby to see the Originals lineup in demo mode first, before wagering anything, if you want to look around before committing funds.

Responsible Gambling

Understanding the cryptography behind a round changes nothing about the risk of the money wagered on it. A provably fair guarantee has no bearing on house edge, variance, or the chance of a losing session; it only confirms a result was not altered after the fact. Set a deposit or session limit before you start playing, not after a losing streak makes the decision harder. Flush's own responsible gambling resources sit alongside the helplines below. If gambling stops being enjoyable or starts affecting your finances, free and confidential support is available: GamCare (0808 8020 133 in the UK, gamcare.org.uk), BeGambleAware (same UK number, begambleaware.org), the National Council on Problem Gambling in the US (1-800-GAMBLER, ncpgambling.org), and Gambling Therapy for international support (gamblingtherapy.org). Never gamble more than you can afford to lose.

Ready to Verify Your Next Round?

The mechanism covered in this guide is not theoretical. Every bet placed on a Flush Original already runs through this exact hash-commit-reveal sequence, whether you check it or not. If you want the step-by-step version for a specific game, our provably fair Bitcoin games walkthrough covers crash, dice, mines, plinko, and keno individually. Otherwise, visit Flush's casino lobby to try a round yourself, rotate your seed, and verify a result firsthand.