Education & Guides
Bonus Balance at Qzino
Terms & Conditions
Sep 7, 2026
1500
Sep 17, 2026•8 min read
Provable Fairness Guide
To enhance your experience, we have introduced a transparent Provably Fair mechanism that allows you to independently verify every single bet. We deeply value our community's trust, and keeping our games fair is our top priority. This article explains the core principles behind our fairness protocol.
This cryptographic method guarantees that outcomes are fixed before you play, generated by a process we disclose rather than hide, and cannot be altered afterward. It powers our Original games: nothing about a round's outcome can be changed once it's locked in, and the cryptographic proof behind it is there for you to check afterward.
This guide currently covers our single-player Originals only.
Why Does It Matter?
Trust is everything in gaming. When you place a bet, you need to know the game isn't rigged behind the scenes, plain and simple as that. You shouldn't have to cross your fingers and hope the system treats you fairly.
That's why we use the Provably Fair mechanism:
- Every single round generates verifiable cryptographic proof.
- Once that proof is revealed (after you rotate your seed pair), you can inspect your seeds, hashes, and outcomes directly from your game history.
- Game outcomes are locked in cryptographically before you even click play.
We don't expect you to take our word for it. We give you the tools to check it yourself, so you can play with confidence.
Single-Player Originals (Dice, Limbo, Keno, Plinko, Coin Flip, Ultimate Dice)
How It's Implemented
These games run on an individual RNG framework combining a Server Seed, a Client Seed, and a Nonce. The core cryptographic calculation is:
Outcome = HMAC_SHA256 (Server Seed, Client Seed:Nonce:Cursor)
When a bet is placed, these values are processed through the HMAC-SHA256 algorithm to produce a deterministic, unalterable stream of random bytes, which are then converted into the final game result. Below, we describe each component in detail.
Server Seed
A 64-character, cryptographically secure random string generated on our backend using a Hardware Random Number Generator (HRNG). Before you place a bet, the backend displays the public Server Seed Hash (a SHA-256 hash of the secret seed). In cryptography, this is known as a commitment. Because the hash is public, the server is locked in. If we were to alter even a single character of the secret Server Seed during your session, the public hash would no longer match. The raw, unhashed Server Seed remains secret during active gameplay to prevent predicting future outcomes and is revealed only when you rotate your seed pair.
Client Seed
A custom string that acts as your personal contribution to the RNG process. Because you can provide or change your own seed, the casino has no way of predicting or controlling the input to the formula. Your Client Seed offsets the random output into a unique result that only you help determine. Even if you never set a custom value, the default Client Seed is generated in your browser, not on our servers.
Nonce
An incrementing integer that tracks how many bets you have placed with your active seed pair. It starts at 0 for the first bet made with a new seed pair and automatically increments by 1 with every subsequent bet. Because the Server Seed and Client Seed stay constant during your session, the Nonce ensures that every single bet produces a completely unique result. Each seed pair follows a strict, sequential Nonce progression.
Your seed pair isn't tied to a single game; instead, the same Server Seed and Client Seed apply across all single-player Originals, so switching from Dice to Mines mid-session doesn't reset anything. Only the Nonce keeps counting, tracking every bet you place across any of these games until you rotate to a new pair.
Cursor
A standard HMAC-SHA256 calculation yields a fixed output of 32 bytes of random data. Because most single-player game events require 4 bytes of data to generate a fair outcome, a single hash provides enough random data for up to 8 events (32 bytes / 4 bytes = 8 events). The Cursor is an incremental pointer used to generate additional random bytes if a single game round requires more data than one 32-byte hash can provide:
- Cursor 0: Used for games requiring 8 or fewer random numbers per round (e.g., a single roll in Dice, a target hit in Limbo, or a coin flip). The initial 32-byte hash is sufficient, so the Cursor remains at 0.
- Cursor +1, +2, ...: Used for complex rounds requiring more than 8 distinct random numbers (e.g., drawing 20 numbers in Keno, or uncovering multiple tiles in Mines). Once the first 32 bytes are exhausted (after 8 events), the Cursor increments by 1 to generate a fresh 32-byte HMAC stream, ensuring continuous, unrepeated randomness throughout the round.
Generating random bytes is universal across all single-player Originals, but converting those raw bytes into specific in-game events depends on how the game is played. The platform takes 4-byte chunks of the HMAC-SHA256 output and converts them into floats (decimal numbers between 0 and 1). These floats determine game events using two main methods:
1. Non-Repeating Outcomes (Fisher-Yates Shuffle Algorithm)
Games where outcomes cannot be duplicated (e.g., uncovering tiles on a grid without hitting the same spot twice, or drawing distinct numbers from a fixed range) use the Fisher-Yates Shuffle. The generated float is multiplied by the number of remaining possible outcomes. Once a position is selected, it is removed from the pool, and the next float is multiplied by the reduced total. Game example: Keno.
2. Independent Continuous Outcomes
Games with independent results take the generated float and map it directly across a fixed range, with no outcome ever removed from consideration - the same result can come up again on the very next event. For example, in Dice, the float is multiplied by 100 to produce an exact roll result between 0.00 and 99.99. Game examples: Dice, Limbo.
How to Verify a Single-Player Bet
For single-player games, an active Server Seed is hidden during play and must be revealed by rotating your seeds before you can verify past bets. Note that you can rotate your seed pair anytime by clicking Fairness inside any game and opening the Seeds tab. This isn't tied to a specific bet, so you don't need to be checking one to do it.
Step 1.
Go to Game History and select the bet you want to check, then open its details by clicking on the bet.
Step 2.
Scroll down to the Provable Fairness section.
If you see "Change seed pair to verify": your seed pair hasn't been rotated yet. Click it, then click Change, and close the pop-up. This reveals the raw Server Seed for all bets placed under that pair.
If you see “Verify” directly: your seed pair was already rotated, for example, if you'd done it earlier via the Seeds tab under Fairness inside the game. Skip straight to Step 3.
Step 3.
Click Verify. Your revealed Server Seed, Client Seed, and Nonce will autofill into the calculator (or copy/paste them manually).
Step 4.
Confirm that the calculated result matches your game history, and that hashing the revealed Server Seed reproduces your original Server Seed Hash. Match confirmed: your result was generated exactly as committed, with nothing altered afterward.
FAQ
Does Provable Fairness remove the house edge?
No. Provable Fairness guarantees that outcomes are generated and revealed exactly as committed, and that you can check that for yourself. It does not alter the built-in mathematical house edge or payout ratios of the games.
Which games use the Server Seed + Client Seed + Nonce model?
Dice, Limbo, Keno, Plinko, Coin Flip, and Ultimate Dice all use the Server Seed + Client Seed + Nonce model described above.
Why is my active Server Seed hidden?
If the raw Server Seed were revealed while still active, players could calculate future outcomes before placing a bet. By displaying the public Server Seed Hash, we commit to the outcomes in advance while keeping the raw input hidden until you choose to rotate your seeds.
Can I change my Client Seed whenever I want?
Yes. You can enter a custom Client Seed or generate a new random one at any time in the Fairness window. Because the Server Seed Hash for your pair is published before your Client Seed is set, the platform can't tailor its seed to a Client Seed it doesn't know yet — your Client Seed keeps the backend from biasing outcomes toward a value it can see in advance.
Does changing my bet size change the outcome?
No. Outcomes are derived strictly from your active seed pair and the incremental Nonce. Because your inputs are locked in cryptographically before you place a wager, changing your bet amount has zero effect on the mathematical result.
What happens if the verification result doesn't match my bet history?
Because the system is governed strictly by cryptographic math (HMAC-SHA256), a mismatch is virtually impossible unless the inputs were entered incorrectly. If a check fails, ensure you are using the correct unhashed Server Seed, Client Seed, and exact Nonce for that specific round.
Did you like this article?
Share with:
