How Provably Fair Works: The Cryptographic System Behind Flush Originals

Last Updated: May 2026 | Editorial Team, Flush Casino

Provably fair is a cryptographic verification system that allows any player to independently confirm that a game result was determined fairly, before the round began, without the ability of the casino to alter it after the fact. It is the foundational trust mechanism behind every Flush Original game in the Flush lobby. Unlike the RNG certification used in third-party slot games, provably fair does not require you to trust a testing laboratory’s certificate. The mathematics of the system allows you to run the verification yourself using publicly available tools. This guide explains exactly how provably fair works at Flush: the SHA-256 hashing algorithm, the dual-seed commitment structure, the HMAC-SHA-256 calculation used to generate results, the step-by-step verification process, and what the system does and does not guarantee. Every claim in this guide is grounded in cryptographic principles and the specific implementation used in Flush Originals.

The Problem Provably Fair Solves

In a traditional online casino using a server-side RNG, the game result is produced by the casino’s server after you place your bet. The server generates a random number, maps it to a game outcome, and returns the result to your screen. The entire process happens on hardware you cannot access, using software you cannot inspect.

The casino knows the result before you do. You have no mechanism to verify that the result was genuinely random and not selectively applied to your bet. You must trust the casino’s honesty and the integrity of the independent testing lab that certified their RNG. Both of those trust points are meaningful: reputable labs like eCOGRA and iTech Labs are rigorous, and certified casinos are overwhelmingly honest, but the trust requirement remains. You cannot verify; you can only believe.

Provably fair eliminates the trust requirement with mathematics. The system cryptographically commits to a game result before the round begins, then proves after the round that the commitment matched the outcome. The proof is mathematical, not institutional. You do not need to trust Flush’s honesty because the math structure makes dishonesty detectable.

This is the core value proposition of the provably fair system at Flush: it converts a trust-based system into a verification-based system. You still play against a house edge, but you can confirm the specific result of any round was produced fairly.

How SHA-256 Hashing Works

SHA-256 (Secure Hash Algorithm 256-bit) is the cryptographic foundation of the provably fair system at Flush. Understanding how it works is necessary to understand why provably fair provides meaningful guarantees.

SHA-256 is a one-way function. It takes any input of any length (a word, a sentence, a number, a random string of characters) and produces a fixed-length output of exactly 64 hexadecimal characters, called a hash or digest. Three properties of SHA-256 are relevant here:

Property 1: Determinism. The same input always produces exactly the same hash. SHA-256(“hello”) always produces 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. No exceptions. This is true across all computers, operating systems, and implementations of SHA-256.

Property 2: Pre-image resistance. Given a hash, it is computationally impossible to determine the original input. The hash 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 does not tell you the input was “hello” unless you already know or guess it. To find an input that produces a specific hash requires trying inputs one by one until you find a match, which for a 256-bit hash space requires more computation than exists on Earth.

Property 3: Avalanche effect. A tiny change in the input produces a completely different hash. SHA-256(“hello”) and SHA-256(“helo”) produce hashes that share no obvious pattern. This means you cannot predict what a hash will look like based on a nearby input.

These three properties are what make SHA-256 useful for commitment schemes. If Flush publishes SHA-256(server_seed) before a round, they have committed to that specific server_seed without revealing it. After the round, they reveal the server_seed. You can verify the commitment by calculating SHA-256(revealed_server_seed) and checking it matches the published hash. If the hashes match, the server_seed is genuine. If they do not match, Flush tried to use a different server_seed, and you would detect that immediately.

The Dual-Seed System at Flush

The provably fair system at Flush uses three components to generate each round’s result:

Server Seed: a long random string generated by Flush before the round begins. Flush keeps this secret during the round but publishes its SHA-256 hash so you can verify it was set before you bet.

Client Seed: a string you provide as the player. Flush gives you a default client seed when you first play, but you can change it at any time before a round. The client seed is visible to you at all times and is under your control.

Nonce: a counter that increments by 1 with each round played. The nonce for your first round is 1, for your second round is 2, and so on. It resets when you change your client seed.

The result of any round is a deterministic function of these three inputs. The same server_seed, client_seed, and nonce will always produce the same result. No randomness occurs at the result-generation step: the randomness is embedded in the server seed when it was generated.

Pre-Commitment: How Flush Locks In the Result Before You Bet

Before any round begins, Flush generates a new server seed for the upcoming session. Flush then calculates SHA-256(server_seed) and displays this hash in your game interface. This hash is your proof that the server seed exists and was set before you played.

You cannot determine the server_seed from its hash (Property 2 above). You can only confirm, after the round, that the server_seed Flush reveals hashes to the value that was displayed before the round. The pre-commitment hash is the mechanism that prevents Flush from choosing the server_seed after seeing your bet.

To understand why this matters: if Flush could choose the server_seed after you bet, they could always select a seed that produces a losing outcome for you. The pre-commitment with the published hash makes this impossible because any server_seed they try to use after the round must hash to the pre-committed value. The only server_seed that can hash to that value is the original one they generated before the round.

How the Result Is Calculated

The game result for any round at Flush is calculated using HMAC-SHA-256 (Hash-based Message Authentication Code using SHA-256). The formula is:

result_hex = HMAC-SHA-256(key: server_seed, message: client_seed + ”:” + nonce)

This produces a 64-character hexadecimal string. Flush then converts this hex string into the specific game outcome through a deterministic algorithm defined for each game type. For a Limbo round, the hex string is converted to a multiplier. For a Dice round, it is converted to a number between 0.00 and 100.00. For Plinko, it determines which peg path the ball takes.

The deterministic conversion from hex to game result is published in the Flush verification documentation. It uses a byte-reading process that selects a value from the hex output within the game’s defined range. The specific byte positions read, the range applied, and the scaling factors are defined per game and do not change.

A Worked Example: Verifying a Limbo Round

Limbo is a Flush Original where you set a target multiplier and win if the generated multiplier equals or exceeds your target. The round result is determined by the HMAC-SHA-256 of your three seeds.

Hypothetical round parameters:

Server Seed (revealed after round): a8f2c391de4b5f7c1e9a2d6b3c7f0e5a2d8b4c1e6f9a3d7b2c5e8f1a4d7b0c3
Client Seed (your seed): myCustomSeed2026
Nonce: 47

Step 1: Calculate HMAC-SHA-256(key: a8f2c391de4b5f7c1e9a2d6b3c7f0e5a2d8b4c1e6f9a3d7b2c5e8f1a4d7b0c3, message: myCustomSeed2026:47)

The HMAC-SHA-256 function takes the server_seed as the key and the concatenated client_seed:nonce as the message. This produces a 64-character hex string such as: 3f9a2c8b1e7d4f6a0c3b5e9d2a7f4c8b1e3d6f9a2c5b8e1d4f7a0c3b6e9d2a5f

Step 2: Read the first 8 bytes (16 hex characters) of the output: 3f9a2c8b1e7d4f6a

Step 3: Convert to a decimal integer. 3f9a2c8b1e7d4f6a in decimal is 4,573,421,078,452,543,338

Step 4: Apply the Limbo scaling formula. Flush uses the formula: multiplier = (2^32) / (4-byte_value_mod_2^32 + 1) * house_edge_adjustment. The specific formula for Flush Originals Limbo produces a multiplier from this byte value.

Step 5: Compare the generated multiplier to your target. If the generated multiplier exceeds your target, you win. If not, you lose.

To verify this round yourself: go to the Flush account verification page, enter the revealed server_seed, your client_seed, and the nonce, and the Flush verifier will run the same calculation and confirm the result matches what was displayed in the round. You can also verify independently using any online HMAC-SHA-256 calculator by replicating the inputs.

The critical verification step is checking the server_seed hash. Before the round, Flush displayed SHA-256(a8f2c391de4b5f7c1e9a2d6b3c7f0e5a2d8b4c1e6f9a3d7b2c5e8f1a4d7b0c3). After the round, you calculate SHA-256 of the revealed server_seed and confirm it matches. If it matches, the server_seed is genuine and the pre-commitment was honest.

Flush Originals: Games Using Provably Fair

Every Flush Original in the Flush lobby uses the provably fair dual-seed system described in this guide. The table below covers the primary Flush Originals with their game type and result conversion method:

Game	Type	Result Variable	House Edge
Crash	Crash multiplier	Crash point	1%
Limbo	Target multiplier	Generated multiplier	1%
Dice	Number prediction	0.00-100.00 number	1%
Mines	Grid bomb placement	Bomb positions on grid	1%
Plinko	Ball drop path	Ball landing position	1%
HiLo	Card sequence	Card values	1%
Aviator (Spribe)	Crash multiplier	Crash point via SHA-256	~3%

The 1% house edge on Flush Originals corresponds to a 99% RTP. This is substantially higher than the average slot RTP of 95-96.5% and reflects both the mathematical simplicity of the games and the transparency of the provably fair system.

Aviator is produced by Spribe and uses a multi-player crash implementation where the crash point is generated collectively from seeds contributed by all players active in the current round, using a SHA-256 chain that can be independently verified. The Spribe system is slightly different from the Flush native implementation but operates on the same cryptographic principles.

How to Verify a Round at Flush

Flush provides an in-account verification tool accessible from the game history section. The verification process takes less than two minutes:

Step 1: Play any Flush Original. The round’s client seed and nonce are recorded automatically.

Step 2: After the round ends, open the round history from your Flush account. Select the specific round you want to verify.

Step 3: The round history shows the client seed, nonce, and the server seed hash that was committed before the round. At this point, the server seed itself is still unrevealed for future rounds using the same server seed session.

Step 4: To verify a past round, Flush reveals the server seed for completed sessions (server seeds rotate when you change your client seed). Open the verification tab in your Flush account, select the session you want to verify, and Flush reveals the server seed for that completed session.

Step 5: The Flush verification page calculates SHA-256(revealed server_seed) and confirms it matches the committed hash displayed before the round. It then runs the HMAC-SHA-256 calculation with your client seed and nonce to confirm the result matches what was displayed.

Step 6: For independent verification outside Flush, copy the revealed server_seed, client_seed, and nonce into any HMAC-SHA-256 calculator (available at hmac.online or via the command line with openssl). The output should match the result shown in your Flush round history.

Changing Your Client Seed

Your client seed is a string you provide that contributes to every round’s result calculation. Flush assigns a default client seed when you first play a Flush Original. You can change it to any string of your choice at any time before a round, and many players do so regularly.

The practical effect of changing your client seed: it shifts the entire sequence of results you will experience because the HMAC-SHA-256 output changes with a different client seed input. Changing the client seed also resets the nonce to 1 for the new session and triggers Flush to reveal the server seed from the previous session (since that session is now complete and its server seed can be verified).

There is no strategic advantage to any specific client seed string. The SHA-256 function treats all inputs equally and the avalanche property means similar-looking client seeds produce completely different result sequences. The value of client seed control is transparency and independence: your result is not purely determined by Flush’s server seed because your own input is also required.

High-stakes players at Flush who use the provably fair system for BTC or ETH sessions often change their client seed periodically to confirm they can verify each session’s server seed promptly. At those stake levels, the ability to independently audit each session against the cryptographic record is meaningful protection.

What Provably Fair Does Not Guarantee

Provably fair is a powerful system but it has defined boundaries. It is important to understand what the system provides and what it does not.

Provably fair guarantees: the result of each round was determined by the combination of server seed, client seed, and nonce using the stated algorithm, before the round began, and was not altered after your bet was placed.

Provably fair does not guarantee: that you will win. The house edge on Flush Originals is 1%, meaning the theoretical long-run return is 99%. Over millions of rounds, Flush retains approximately 1% of all wagers. This edge is built into the result conversion formula (the step that converts the HMAC-SHA-256 hex output to a game multiplier or outcome applies a slight bias toward the house). The fairness of the system means you are playing against the true mathematical probability, not a manipulated one. The house edge itself is not manipulation; it is the disclosed and consistent mathematical structure of the game.

Provably fair also does not prevent sequences of losses, even extended ones. The independence of each round means that 50 consecutive losing rounds on Dice is possible and does not indicate any system failure. Each round’s result is independently generated from its own seed combination, with no memory of previous results.

Third-Party RNG vs. Provably Fair: How They Differ

The slot games in the Flush lobby from developers like Pragmatic Play, Push Gaming, Play’n GO, and others use server-side certified RNG systems. These are not provably fair in the cryptographic sense but are independently certified by testing laboratories.

The certification process for third-party RNGs: the developer submits their RNG implementation to a testing lab such as eCOGRA, iTech Labs, or BMM Testlabs. The lab tests the statistical properties of the RNG output, verifies the implementation against stated game mathematics, and certifies that the RNG meets defined standards for randomness and fairness. The certificate covers the RNG system as a whole across millions of simulated outcomes.

The key difference from provably fair: certified RNG is verifiable at the system level by the testing lab, not at the individual round level by the player. You cannot verify the result of a specific spin in Sweet Bonanza the way you can verify a specific round in Flush Dice. You rely on the lab’s certification covering the overall system.

Both systems, when properly implemented, produce genuinely random and fair results. The difference is the verification method: institutional trust for certified RNG, individual mathematical verification for provably fair. Flush uses certified RNG for all third-party slot games and provably fair for all Flush Originals. The RTP for Flush Originals (99%) is higher than the typical certified slot RTP (94-97%) partly because the mathematical simplicity of Flush Original games and the provably fair system allow a thinner house margin.

Flush Originals and Crypto: BTC, ETH, USDT, TRX, SOL

Flush Originals are particularly well-suited to crypto play. The provably fair system, the 99% RTP, and the instant round settlement of games like Crash and Limbo align well with crypto deposits and withdrawals.

Flush accepts BTC, ETH, USDT, TRX, and SOL for all games including Flush Originals. The minimum bet on Flush Originals is typically $0.10 or lower, making them accessible at very low crypto amounts. A $20 USDT deposit provides 200 rounds at $0.10 stake with the full provably fair verification available for every round.

For players who want to use the verification system regularly, the Flush account interface stores the full round history including server seed hashes, client seeds, and nonces for every round played. All past sessions with revealed server seeds are available for retrospective verification at any time. This record is permanent within your Flush account history.

FAQ

Can Flush manipulate a round result after I place my bet?

No. The pre-commitment system makes post-bet manipulation detectable. Before any round, Flush publishes SHA-256(server_seed). To change the result after your bet, Flush would need to use a different server_seed, but any different server_seed would produce a different hash that does not match the pre-committed value. When you verify the round after it ends, you check SHA-256(revealed_server_seed) against the committed hash. A mismatch would be immediately visible. This check takes less than one minute using any SHA-256 calculator. The cryptographic impossibility of finding a different input that produces the same SHA-256 hash (the pre-image resistance property) is what makes this guarantee absolute rather than probabilistic.

What happens if I forget to verify a round? Is the data still available?

Yes. Flush stores the complete round history for every Flush Original session in your account. Server seed hashes, client seeds, nonces, and revealed server seeds for completed sessions are all retained and accessible from the verification section of your Flush account. There is no time limit on verification: a round played six months ago can be verified today using the stored data if the server seed session containing that round has been completed (i.e., you have since changed your client seed, which triggers server seed reveal). Flush does not delete round history.

Does changing my client seed affect my odds or RTP?

No. The RTP of every Flush Original is determined by the house edge built into the result conversion formula, which is constant regardless of what client seed you use. Changing your client seed shifts the sequence of results you will experience (because different inputs to HMAC-SHA-256 produce different outputs) but does not change the probability of any specific outcome. The RTP of 99% on Flush Dice, for example, applies to every client seed equally across a sufficient number of rounds. Changing your client seed is a transparency mechanism, not a strategy tool.

How is the crash point in Aviator determined fairly?

Aviator uses a multi-player crash point system developed by Spribe. The crash point for each round is generated from a hash chain where each round’s seed is derived from the previous round’s hash, creating a verifiable sequence. Additionally, player seeds from all active participants are incorporated into each round’s crash point calculation, meaning no single entity (including Spribe) can predetermine any individual round’s outcome unilaterally. The full Spribe verification method is documented in their provably fair technical specification, and each Aviator round in the Flush lobby includes a verification hash that can be checked against Spribe’s published hash chain.

What is the difference between a server seed and a server seed hash?

The server seed is the actual secret random string generated by Flush before your session. It is kept hidden during your session so it cannot influence your betting decisions. The server seed hash is SHA-256(server_seed): a 64-character string derived from the server seed using SHA-256. The hash is published before your session begins, proving the server seed exists and was set before you played, without revealing the server seed itself. After your session ends (when you change your client seed), Flush reveals the actual server seed. You verify it by calculating SHA-256 of the revealed value and confirming it matches the published hash. This two-step reveal-and-verify process is the core of the provably fair commitment scheme at Flush.

About the Author

Editorial team at Flush Casino produces technical casino guides to help players understand game mechanics, mathematics, and strategy with precision. Our how-it-works guides are written to give players the factual foundation to make informed decisions about which games to play and how to approach them. All technical data is sourced from developer documentation, certified RTP sheets, and direct gameplay analysis.

The Cryptographic Security Margin: Why SHA-256 Cannot Be Broken

A natural question is whether SHA-256 could theoretically be reversed or faked. Understanding the scale of the computational security margin explains why the provably fair guarantee at Flush is absolute for practical purposes.

SHA-256 produces a 256-bit hash. The number of possible SHA-256 hashes is 2^256, which is approximately 1.16 x 10^77. This is a number with 77 digits. The total number of atoms in the observable universe is estimated at 10^80, meaning the number of possible SHA-256 hashes is comparable in scale to the number of atoms in the universe.

To reverse a SHA-256 hash (find the original input given only the hash) by brute force requires trying possible inputs until one produces the correct hash. Even using the entire computing power of the planet running continuously since the beginning of time, the number of SHA-256 inputs that could be tested falls vastly short of the number needed to have a meaningful probability of finding the correct one. No quantum computer at any scale currently planned would change this for SHA-256 within any foreseeable timeframe.

The practical guarantee: when Flush publishes SHA-256(server_seed), finding a different server_seed that produces the same hash (a collision) is computationally beyond any realistic attack. This makes the pre-commitment binding in a way that is not a matter of policy or trust, but of mathematics.

The Nonce: Why Round Counts Matter

The nonce is often the least discussed component of the provably fair system but it plays a specific role. The nonce is a counter that increments by 1 with each round played during a client seed session. Its purpose is to ensure that each round produces a unique result even when the server seed and client seed are the same.

Without the nonce, playing the same game twice in a row would produce the same result because the HMAC-SHA-256 inputs would be identical. The nonce breaks this repetition: round 1 uses client_seed:1, round 2 uses client_seed:2, and so on. The HMAC-SHA-256 function applied to these different messages produces different hex outputs and therefore different game results.

The nonce also serves as a round counter that you can use to audit your history. If your current nonce is 342, you know you have played 342 rounds in the current client seed session. Combined with the stored round history at Flush, you can identify and verify any specific round by its nonce number.

When you change your client seed, the nonce resets to 1 and a new server seed session begins. The previous session’s server seed is revealed. This design means each client seed session is a self-contained cryptographic record: a specific server seed, a sequence of nonces from 1 to N, and a specific client seed, producing a deterministic and verifiable sequence of round results.

Probability Within a Fair System: Expected Value and Session Variance

Provably fair verifies that each round result is genuine. It does not smooth out variance across sessions. The statistical properties of fair randomness include streaks, cold runs, and sequences that feel improbable.

For Flush Dice at 50% win probability (betting under 50.50 with a 1% house edge): the probability of losing 10 consecutive rounds is (0.505)^10 = approximately 0.95%. In a session of 1,000 rounds, you would expect to see a 10-round losing streak approximately 9 or 10 times. These streaks are the expected output of a fair random system, not evidence of manipulation.

For Crash at Flush with a 1% house edge: the expected crash point follows an exponential distribution. The probability that any given round crashes before 2x is approximately 50%. The probability that it crashes before 10x is approximately 90.1%. The probability of a crash below 1.01x (before any meaningful multiplier is reached) on any single round is approximately 1%. In a session of 300 rounds, you would expect approximately 3 rounds to crash at that early level.

Understanding these probabilities within the provably fair framework at Flush gives you the complete picture: each result is generated fairly and verifiably, and the distribution of results across a session matches the mathematical expectations defined by the game’s house edge. The Flush verification system confirms the first part; the mathematical expectations cover the second.

Using Provably Fair at Flush for BTC, ETH, USDT, TRX, and SOL Play

The provably fair system at Flush applies to every Flush Original game regardless of the cryptocurrency used to fund the bet. Whether you are playing Crash with a BTC deposit, Limbo with ETH, Dice with USDT, Plinko with TRX, or HiLo with SOL, the same dual-seed HMAC-SHA-256 system generates and verifies every round result.

The crypto-specific element is the transaction record: your deposit, bet placement, and withdrawal are all recorded on the relevant blockchain. For BTC and ETH deposits, the transaction is confirmed on-chain before the balance is credited at Flush. For USDT (typically on the TRC-20 or ERC-20 network), TRX, and SOL, the confirmation times differ by network speed.

Once your balance is credited at Flush, all Flush Original play is governed entirely by the provably fair system. The cryptographic record of round results is independent of the blockchain transaction record. If you want to audit a session, you need the provably fair verification data (server seed, client seed, nonce) from your Flush account, not the blockchain transaction. The blockchain confirms the funding; the provably fair system confirms the game results.

Flush recommends keeping a local record of your active client seed and the server seed hash for any session where you are betting at significant stake levels. This takes less than a minute (copy both strings to a notes file) and ensures you have the data needed for independent verification even if you access the Flush account verification tool later.

Ready to Play?

Instant crypto deposits. Fast and simple.

Play at Flush

How Provably Fair Works: The Cryptographic System Behind Flush Originals