Provably Fair

Provably fair is the cryptographic method this site uses to generate and let you independently verify the outcomes of supported Originals and instant games. The aim is simple: results are determined by a combination of values you control and values the server commits to in advance, so neither side can alter a round after seeing a stake, potential win, or any other factor. Players in England and across the UK can verify every round without relying on trust or hidden code.

Rainbet / Provably Fair

What “provably fair” means in practice

Before a session starts, the server creates a secret value and publishes only its cryptographic hash. That hash acts as a tamper-evident seal: once revealed, the original secret must match the earlier hash or the attempt is invalid. You provide your own value as well, so the final result depends on something you chose and something the server committed to before your wager. After you rotate seeds, the server discloses the original secret, allowing you to confirm the seal and reproduce each past outcome.

This approach prevents biased dealing, selective “lucky” behaviour, and post-bet adjustments. It also means streaks—good or bad—are just randomness, not a hidden switch. Your role is to keep a record of your settings and to rotate seeds regularly so you always know exactly which inputs created a given result.

Seeds and nonces, explained

Term	What it does
Client seed	A text string you set in your account. You can edit it any time before a round. This ensures you contribute to the randomness and can reproduce results later.
Server seed (hashed)	A secret made by the server. Its hash is shown to you before play as a commitment. The unhashed value is revealed only after you rotate seeds.
Nonce	A counter that starts at 0 for a given client/server seed pair and increases by 1 per bet. It ensures round #1, #2, #3, etc. produce distinct outputs even with the same seeds.

How a round result is generated

You set (or keep) your client seed.
The platform shows a hashed server seed—a commitment the site cannot change without breaking the hash.
You place a bet. The game combines client seed + server seed + nonce and runs them through a public algorithm (for example, HMAC-SHA256 or SHA-512 driven expansions) to produce a pseudo-random stream.
That stream is mapped to the game’s outcome space: a crash multiplier, a mines layout, a plinko bin, a dice roll, and so on.
The nonce increments by 1 for the next round under the same seed pair.

Exact mapping rules differ by game type and are documented on each game’s Fair Play panel.

How to verify any past round

Open the Bets page and select the round you want to check.
Click Provably Fair to view all inputs used: your client seed, the hashed server seed that was committed at the time, and the nonce for that round.
Rotate seeds in your account. Doing so reveals the unhashed server seed previously used for all rounds under that pair.
Use the in-bet Verify tab or the game’s algorithm description to recompute the output locally. If your recomputed result matches the recorded outcome, the round is verified.

You can also copy the inputs into any independent verifier that implements the same algorithm. Always check that the code and formula it uses match the description shown inside the game.

Seed rotation and reveal policy

You may change your client seed at any time before the next round.
When you choose Rotate for the seed pair, the platform discloses the plain server seed for that historical period.
The disclosed seed must hash to the exact commitment you saw earlier. If it does not, the commitment was not honoured—contact support immediately with the bet IDs.
After rotation, a new server seed and hash appear, and the nonce counter resets to 0 for the fresh pair.

Frequent rotation makes audits simpler and reduces the number of rounds tied to a single pair of inputs.

Multiplayer and live formats

Some multi-user formats and presenter-led live games use additional safeguards such as round-specific hashes, shared entropy contributions, or external randomness sources. The Fair Play or Game Rules panel explains how those sources are incorporated and how you can retrieve the exact inputs for each shared round. Regardless of format, the principle is identical: commitments are published before play, and all inputs required for reproduction are made available after the round (or after seed rotation, where applicable).

Example mapping (illustrative)

For games that require a number in the range [0, 1):

Compute digest = HMAC_SHA256(server_seed, client_seed + ":" + nonce).
Interpret the first 8 bytes of digest as an unsigned integer x.
Divide by 2^64 to obtain r in [0, 1).
Map r to the game result (e.g., select a plinko bin based on cumulative probability bands, pick safe tiles for mines using deterministic shuffles, or derive a crash multiplier via a documented formula).

This is an example only; always follow the exact mapping listed on the game’s Fair Play panel.

Best practice for players in England

Set a memorable client seed (not personal data) and record it alongside the date you enabled it.
Rotate seeds after any session you intend to audit, then download or screenshot the revealed server seed for your notes.
If you use third-party verifiers, confirm the hash function and mapping steps match the game’s documentation.
Keep your device time and browser updated to avoid caching old seed data on the Fair Play page.

Troubleshooting and support

If a round will not verify, check that:

You used the correct nonce for that round.
You rotated the seed pair covering the bet, so the server seed is visible.
The algorithm in your verifier matches the exact steps listed inside the game.

Still stuck? Contact [email protected] with the bet ID, your client seed, the revealed server seed, and a brief description of the verifier you used. Average email response time is 2 hours. For general status updates, you can also reach us via our official social profiles, but account-specific troubleshooting is handled by email for security.