Learn about Bitcasino Originals provably fair games

What is Provably Fair?

Provably fair is an approach used in online gaming that allows every result to be independently verified as genuinely random.

It provides a cryptographic guarantee that game outcomes cannot be altered after a bet is placed. By combining player-provided data, server-generated data and publicly verifiable cryptographic commitments, anyone can independently reproduce and verify the outcome of a round.

This ensures that every result remains both unpredictable before the round and verifiable after it has completed.

How We Keep Our Original Games Provably Fair

Every outcome is generated using three components:

Server Seed

A secret random value generated by the server.

Before gameplay begins, the server publishes a cryptographic hash of the Server Seed. This acts as a commitment, proving the Server Seed existed before the round started without revealing its value.

After the round resolves, the Server Seed is revealed and can be verified against the previously published hash.

Client Seed

A value contributed by the player.

Players may choose their own Client Seed or use a system-generated value. The Client Seed becomes part of the randomness generation process and can be changed at any time.

Nonce

A counter that increases with every random event.

The Nonce ensures that each random result remains unique, even when the same Server Seed and Client Seed are used.

Provably Fair — Verification Guide

This guide explains how the provably fair system generates randomness and how you can independently verify the outcome of any round.

The system operates using a simple principle:

Commit → Play → Reveal

The server first commits to a Server Seed by publishing its hash. Gameplay then takes place using the Server Seed, Client Seed and Nonce. Once the round has completed, the Server Seed is revealed so that the entire process can be independently verified.

Table of Contents

• Trust Model
• Seeds, Hashes and Nonces
• Randomness Generation
• RNG Translation
• Shuffling
• Deck Commitment
• Outcome Mapping
• How to Verify a Result
• Reference Verifier
• Worked Example
• Notes

Trust Model

Before a round begins, the server generates a secret Server Seed and publishes:

serverSeedHash = SHA256(serverSeed)

Because cryptographic hashes are one-way functions, the Server Seed remains hidden while the commitment remains publicly visible.

After the round resolves, the Server Seed is revealed.

Players can then verify:

SHA256(serverSeed) == serverSeedHash

If the values match, the Server Seed could not have been modified after the commitment was made.

Seeds, Hashes and Nonces

Value	Origin	Meaning
serverSeed	Server	Secret random value revealed after the round
serverSeedHash	Derived	SHA256 hash of the Server Seed
clientSeed	Player	Player-provided source of randomness
nonce	Counter	Increments with every random event
initialShuffle	Server	Initial deck or board state, for card games only
initialShuffleHash	Derived	Commitment to the initial deck or board state
finalShuffle	Server	Final deck or board state after the round

What Is Published When

Value	Before / During Round	After Round Resolves
clientSeed	✓	✓
serverSeedHash	✓	✓
nonce	✓	✓
initialShuffleHash	✓	✓
serverSeed	—	✓
initialShuffle	—	✓
finalShuffle	—	✓

Randomness Generation

Every random value is generated from the combination of:

• Server Seed
• Client Seed
• Nonce

The inputs are combined using HMAC-SHA256 to produce a deterministic cryptographic value.

Conceptually:

Server Seed + Client Seed + Nonce
            ↓
        HMAC-SHA256
            ↓
     Cryptographic Value

This value is then used to initialize a ChaCha20-based random number generator.

ChaCha20 is a widely used cryptographic algorithm designed to generate secure and statistically uniform random values.

Because the process is deterministic, the same inputs will always produce the same output. This allows every outcome to be independently reproduced and verified after the Server Seed has been revealed.

RNG Translation

The random values produced by the generator are converted into the numerical ranges required by each game.

Examples:

• Dice converts a random value into a roll within the configured range.
• Roulette converts a random value into a wheel position.
• Plinko converts a random value into a landing position.
• Card games use random values to generate deck shuffles.

Where a game requires a random value within a specific range, rejection sampling is used to ensure that every possible outcome remains equally likely and that no statistical bias is introduced.

Shuffling

Card and board games use the Fisher-Yates shuffle algorithm.

Fisher-Yates is a mathematically proven method for generating unbiased random permutations and is widely used throughout the gaming industry.

Conceptually:

Ordered Deck
      ↓
 Fisher-Yates Shuffle
      ↓
 Randomized Deck

The shuffle is generated from the same Server Seed, Client Seed and Nonce values used throughout the provably fair system.

Because the shuffle is deterministic, any player can reproduce the exact deck order once the Server Seed has been revealed.

Deck Commitment

For card games, the initial deck order is committed before any cards are dealt.

The commitment is generated as:

initialShuffleHash = SHA256(initialShuffle + serverSeed)

The hash is published before gameplay begins, while the deck itself remains hidden.

After the round resolves, the initial deck order is revealed and can be verified against the previously published commitment.

This ensures that the deck could not have been modified after the commitment was made.

Outcome Mapping

Each game maps the generated random values to a specific result.

Dice

A random value is converted into a roll within the game's configured range.

Roulette

A random value is converted into a wheel position.

Plinko

A random value determines the final landing position and resulting multiplier.

Card Games

For Blackjack, Baccarat and Hi-Lo, an ordered deck is shuffled using Fisher-Yates and cards are dealt according to the game rules.

Players can independently reproduce the shuffle and verify the resulting card sequence.

How to Verify a Result

For a completed round, verification consists of three steps.

Step 1 — Verify the Server Seed

Confirm that the revealed Server Seed matches the previously published Server Seed Hash:

SHA256(serverSeed) == serverSeedHash

This proves that the Server Seed was committed before gameplay began.

Step 2 — Reproduce the Outcome

Using the revealed Server Seed, Client Seed and Nonce, reproduce the random values generated during the round.

The reproduced values should match the published game result exactly.

Step 3 — Verify the Deck Commitment

For card games, verify:

SHA256(initialShuffle + serverSeed) == initialShuffleHash

This confirms that the starting deck was committed before gameplay began and was not modified afterwards.

Reference Verifier

A reference verifier is provided to allow players to independently reproduce and verify game outcomes.

The verifier uses the published Server Seed, Client Seed and Nonce values to recreate the random values generated during gameplay.

If the reproduced values match the published results, the round has been verified successfully.

Worked Example

Example values:

serverSeed =
3e8f1c0b7a96d5e4f2c1b0a9d8e7f6c5b4a3928170615243f9e8d7c6b5a40312

clientSeed =
player-client-seed-001

serverSeedHash =
b1198418007c4216afd19221dc11274595663fc55219aaf85b6291e2d5bdebee

Verification:

SHA256(serverSeed)
=
b1198418007c4216afd19221dc11274595663fc55219aaf85b6291e2d5bdebee

Since the values match, the Server Seed was correctly committed before gameplay began.

Using the same Server Seed, Client Seed and Nonce in the reference verifier will always reproduce the same outcome.

Notes

• Server Seed, Client Seed and Nonce fully determine every outcome.
• The same inputs will always generate the same result.
• HMAC-SHA256 is used to derive cryptographic randomness from the seed values.
• ChaCha20 is used as the deterministic random number generator.
• Fisher-Yates is used for deck shuffling in card games.
• Rejection sampling is used where necessary to maintain uniform distributions.
• Any modification to the Server Seed after commitment would invalidate the published hash and be immediately detectable.
• Every result can be independently reproduced and verified after the Server Seed has been revealed.