Classic RNG (HMAC-SHA256)

The Classic RNG mode uses a commit–reveal scheme built on HMAC-SHA256. This is the same approach used by most provably fair platforms in the industry.

How It Works

1. Seed Generation

Before any bets are placed, the server generates a random Server Seed and computes its SHA-256 hash. The player is shown the hashed server seed as a commitment — proof that the seed exists but cannot be read yet.

The player also provides (or auto-generates) a Client Seed, which they can change at any time.

Server Seed:        a1b2c3d4e5f6...  (hidden from player)
Hashed Server Seed: SHA-256(Server Seed) → 7f3a9b...  (shown to player)
Client Seed:        my-custom-seed  (chosen by player)

2. Random Number Generation

For each bet, a deterministic random number is generated using:

• Server Seed — secret key for HMAC
• Client Seed — player-provided input
• Nonce — auto-incrementing counter (0, 1, 2, …)
• Cursor — byte offset for games needing multiple random values

The HMAC-SHA256 function produces a 32-byte output per round:

HMAC-SHA256(
  key:     serverSeed,
  message: "clientSeed:nonce:round"
)

The resulting bytes are converted to floating-point numbers in the range [0, 1) by grouping them into chunks of 4 bytes:

float = byte[0] / 256 + byte[1] / 256² + byte[2] / 256³ + byte[3] / 256⁴

Each game maps these floats to game outcomes (dice rolls, card draws, multiplier values, etc.).

3. Verification (After Seed Rotation)

When the player rotates their seeds, the previous server seed is revealed. The player can then verify every bet made with that seed pair:

1. Confirm that SHA-256(revealed server seed) matches the hash they were shown before
2. Recompute HMAC-SHA256(serverSeed, "clientSeed:nonce:round") for each bet
3. Convert the bytes to floats and confirm the game outcomes match

Seed Rotation

Players can rotate seeds at any time through the Provably Fair modal:

1. The previous server seed is revealed in plaintext
2. A new server seed is generated and its hash is shown
3. The player can set a new client seed
4. The nonce resets to 0

Player-Visible Data

Verification Steps

To manually verify a bet:

1. Take the revealed server seed (available after seed rotation)
2. Confirm the hash: SHA-256(serverSeed) must match the hashed server seed shown before the bet
3. Compute the HMAC: HMAC-SHA256(serverSeed, "clientSeed:nonce:0") → 32 bytes
4. Extract floats: Group the bytes into chunks of 4, compute the float for each chunk
5. Map to game outcome: Apply the game’s specific logic to convert floats into results

Security Properties

• Unpredictable: The server seed is hidden, so neither the player nor the server can predict outcomes before the commitment
• Deterministic: The same inputs always produce the same output
• Tamper-proof: Changing any input (server seed, client seed, or nonce) produces a completely different outcome
• Verifiable: After seed rotation, the full chain of bets can be independently verified
• Player influence: The client seed ensures the player contributes to the randomness

Limitations

• Verification is retroactive — the player must rotate seeds before they can verify past bets
• The server seed is revealed as a batch, covering all bets in that seed pair
• There is no per-bet proof; trust is based on the hash commitment scheme