Roll 0.00–99.99, bet over or under. Multiplier = 99 / win-chance%.
Roll 0.00–99.99, bet over or under. Multiplier = 99 / win-chance% (1% house edge).
Mechanism. Multiplier shown as 2.00× but actual win-chance derived from 50.001% → 1.9999× internally, rounding-down the payout silently.
Red flag. Multiply your bet × displayed multiplier yourself. Operator payout should match to the cent — long-run any discrepancy is theft.
Mechanism. Operator's in-app "verify" button uses a simpler formula than the production round generator. Round looks fair against the verifier but isn't.
Red flag. Use a third-party verifier (this site's dice verifier at /tools/dice-verifier/) not the operator's. Same inputs must produce same output across implementations.
Mechanism. When auto-roll trends positive for the player, the operator slows ticks down by 1–2 seconds, making players give up before reaching profit target.
Red flag. A "Run 1000" that takes 4 minutes one session and 12 the next, despite same volume, is suspect.
Mechanism. Server rotates the seed mid-session without notifying you, breaking the hash-chain audit window. Past rounds appear unverifiable.
Red flag. The "previous server seed" should be reachable for every nonce range you played. Gaps = silent rotation.
Mechanism. Roll computed from `int(bytes) % 10000` with k-bit domain not divisible by 10000. Low rolls (0.00–0.50) appear ~0.1% more often.
Red flag. Run the Kolmogorov-Smirnov test (at /tools/kolmogorov-smirnov-test/) over a few thousand of your rolls. p < 0.01 = bias material enough to act on.
For the full compendium across all games, see The Book of Casino Dirty Tricks.
—— pending rotation —Dice is the simplest provably-fair game possible:
bytes = first 4 bytes of HMAC(server, "{client}:{nonce}:0")
float = bytes[0]/2⁸ + bytes[1]/2¹⁶ + bytes[2]/2²⁴ + bytes[3]/2³²
roll = float · 100 // range [0.00, 100.00)
mult = 99 / win_chance% // 1% house edge baked in
win = (mode == "over") ? roll > target : roll < targetThe 99 in the multiplier formula is the entire house edge: a fair multiplier would be 100/win_chance, but the operator pays 99/win_chance instead. Across all targets and modes, expected return is constant at −1%.
This often confuses new players: betting "under 5" (5% win chance, 19.8× payout) and "under 95" (95% win chance, 1.042× payout) have identical long-run expected value of −1%. What changes wildly is variance.
At 5% win chance: 1 win in 20, but each win is +18.8 units. Sessions are mostly red with occasional moonshots. At 95% win chance: 19 wins in 20, each +0.042 units. Sessions feel constantly positive but a single loss takes back ~24 wins. The Dice multiplier explorer plots the variance curve.
Dice is the cleanest game to verify and therefore the cleanest game to rig dishonestly. Common patterns from the Dirty Tricks book:
int(bytes) % 10000 with a k-bit domain that doesn't divide cleanly, biasing low rolls.Because EV is constant, any strategy that doesn't involve operator exploits cannot raise long-term return. Strategy can control:
Spot operators advertise 0.5%, 0.25%, even 0% (with a wagering catch). In the formula, replace 99 with 99.5 or 99.75 — but verify a few rounds yourself before depositing. Bias detection trumps marketing.
By expected return: no. By risk preference: yes. Set the target so the multiplier matches your goal. For "double or lose" use 49.5 under (mult ≈ 2.0×). For "moonshot" use 1.0 under (mult ≈ 99×).
Save several thousand of your rolls to CSV. Run them through the Kolmogorov-Smirnov test against uniform [0, 100]. P-value < 0.01 = the distribution differs from uniform; either you're unlucky or the operator is biased. Cross-reference with the modulo bias detector to compute the theoretical maximum bias for the operator's domain size.