Provably fair explained: check the inputs and result

What the commitment keeps fixed

A commitment puts a checkable hash in front of you while the value behind it remains hidden. Shuffle describes its active server seed as a random 64-character hexadecimal string and publishes a SHA-256 hash of that seed. The active secret is held back until the pair is replaced. Its client seed is the player's input, initially generated by the browser; its nonce counts bets made with the same pair, starting at zero.

After a completed game, replacing the pair reveals the previous server seed. You can then make two separate comparisons:

The word "unhash" in Shuffle's instructions means revealing the stored old seed. It does not mean decrypting SHA-256 or recovering a secret by reversing its hash. A visible server-seed hash is not the secret HMAC key required for the Dice calculation.

Keep the old bet and its inputs together

A current seed panel can belong to the next pair. Start from the completed bet you want to check and keep its identity, result and inputs in one record. The labels have different jobs:

Use the same representation the implementation uses. A string that looks hexadecimal can be treated as literal text or decoded into binary bytes; those are different inputs. The Dice HMAC example uses the literal seed string. For an actual commitment comparison, use the matching commitment code or verifier to preserve that implementation's representation.

Reveal and check a completed Shuffle Dice bet

Shuffle's verification instructions give the following path. They describe the product controls; the calculations here use published examples, not a submitted player bet.

1. Save the completed record. Keep the bet identifier, game, displayed result, Client Seed and Nonce. Keep the earlier Server Seed hash too if you saved it before that result.
2. Finish existing games before replacing the pair. Open the bet modal and select Rotate pair. Enter the desired next Client Seed, then select Change. That next seed belongs to the new pair.
3. Return to the old bet. Close the fairness modal and reopen the completed record. Its previous Server Seed is now revealed. The old bet's Client Seed and Nonce stay the same.
4. Compare the commitment separately. Hash the revealed old value using the matching implementation's representation, or use its matching commitment verifier. Compare with the saved earlier hash. Without that earlier record, leave the timing comparison unresolved.
5. Select Verify for the matching game. Use the old bet's Client Seed, revealed Server Seed and Nonce. An independent calculation must also use that game's byte selection and result mapping.
6. Compare with the bet slip. Record the calculated result and the result being checked. Distinguish a match, a completed comparison that disagrees, and a check that cannot yet be completed because an input is missing.

An online verifier may require account access. Login or loading a page is not a completed verification; the check needs the old inputs and a comparison with their recorded result. You can practise the arithmetic with the complete published vector without creating a betting record.

Reproduce 43.05 from Shuffle's published Dice example

These are illustrative inputs published for Shuffle Dice: Client Seed abc, Server Seed def, Nonce 1, Cursor 0, and one output. The short seed def is a teaching example, not the 64-character operational format or a player's disclosed secret. The expected Dice result is 43.05.

q = 110 × 256³ + 55 × 256² + 216 × 256 + 93
q = 1849153629
u = q / 4294967296
u = 0.43053962965495884

u = 110/256 + 55/65536 + 216/16777216 + 93/4294967296

floor(0.43053962965495884 × 10001) / 100 = 43.05

import hashlib
import hmac
import math

server_seed = "def"
client_seed = "abc"
nonce = 1
cursor = 0
block_index = cursor // 32
byte_offset = cursor % 32
message = f"{client_seed}:{nonce}:{block_index}"
digest = hmac.new(
    server_seed.encode("utf-8"),
    message.encode("utf-8"),
    hashlib.sha256,
).digest()
first_four = digest[byte_offset:byte_offset + 4]
q = int.from_bytes(first_four, "big")
u = q / 4294967296
roll = math.floor(u * 10001) / 100
print(digest.hex())
print(list(first_four))
print(q)
print(u)
print(f"{roll:.2f}")

6e37d85daa228fdf2caeabc192b01502d99bc5e4433994bcabac23403bf407a5
[110, 55, 216, 93]
1849153629
0.43053962965495884
43.05

If your result does not match

Compare the earliest point where the calculations separate. A different message, digest, byte group or mapping can explain a different final number.

Those are specific counterexamples. Different inputs can still land on the same displayed roll because the output grid is finite; a coincidentally equal number is not a substitute for checking the full inputs and calculation.

Trace a disagreement in this order

1. Record and game. Check the exact completed bet, its game and the algorithm version. A correctly calculated result for another bet does not resolve this one.
2. Old pair. Use the old Client Seed and revealed old Server Seed. Keep the newly selected pair out of the calculation for the completed bet.
3. Text and counters. Compare case, spaces, delimiters and the completed Nonce. Preserve seed text exactly; silently trimming or changing case changes the input. Uppercase and lowercase hexadecimal digest displays can represent the same bytes, which is a different issue from changing the seed text.
4. Key encoding and byte selection. Check literal text versus decoded hexadecimal bytes, the HMAC block and Cursor. The synthetic 64-character key gives digest 4046436370ad8d39075d58b218ccf9df4d63be108d55bb743837f9d39f53bf28 as literal text; decoding that key into bytes gives 4ca6ba1c5309bd89562fddb0b36e19ecb0b3db9875b4bcb65e49e073f79b331d.
5. Mapping and rounding. Apply the exact game's final transformation. In the published baseline, the expression u × 10001 / 100 before floor is approximately 43.0582683618; Shuffle's specified floor produces 43.05. A floor step, display rounding and settlement rounding have different meanings.

Shared terminology does not establish a shared algorithm. For example, the published Stake Dice expression shown as (float * 10001) / 100 does not contain Shuffle's floor operation. That expression alone cannot establish Stake's final display or settlement rounding. Adding a floor and calling the result a verified Stake roll would change the implementation being checked.

Missing inputs need a different next action

Missing data is an incomplete check. A failed comparison is a calculation made with identified inputs that disagrees with the identified record. Neither should be reported as the other.

If the mismatch remains after these checks, keep the bet or round identifier, game/version, earlier commitment, revealed old inputs, exact calculation, expected output and actual recorded result together when asking support to explain it. Show where the values diverge. A generic "fairness failed" message leaves out the information needed to reproduce the problem.

Aviator has its own verification path