Skip to content
LAB

Dice

Roll 0.00–99.99, bet over or under. Multiplier = 99 / win-chance%.

Dice

Roll 0.00–99.99, bet over or under. Multiplier = 99 / win-chance% (1% house edge).

Bankroll
Bets0
Win %
Net P/L
Streak
Biggest win
50.00
Win chance
Multiplier
Set a target. Bet over or under.
Presets
Auto-bet
How dishonest operators rig this game 5 documented tricks
01 Truncated multiplier display

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.

02 Verify-tool algorithm divergence

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.

03 Auto-roll speed throttle

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.

04 Hidden server-seed rotation

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.

05 Modulo-bias on the roll

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.

Server seed hash
Server seed (revealed after rotation)— pending rotation —
Client seed
Next nonce

How Dice math works

Provably Fair 100% RTP Dice
100% RTP Dice: Zero house margin PRNG with true 1:1 mathematical payout.
Autobet Console
Autobet Engine: Automated streak escalation and drawdown stop limits.

No other provably-fair game boils down to fewer moving parts than Dice:

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 < target

That 99 is the whole edge right there. A mathematically fair payout would be 100/win_chance; the operator hands you 99/win_chance instead. Whatever target or mode you pick, expected return sits at −1%, always.

Win chance is identical to expected value

New players trip over this constantly: “under 5” (5% win chance, 19.8× payout) and “under 95” (95% win chance, 1.042× payout) deliver the same long-run expectation of −1%. Variance, though, is a different story entirely.

Pick the 5% side and you win once per 20 rounds at +18.8 units each — mostly losing sessions punctuated by rare spikes. Pick 95% and you cash 19 rounds out of 20 at +0.042 units apiece; the session feels like steady profit until one loss erases roughly 24 wins. The Dice multiplier explorer charts this variance curve in detail.

How operators rig Dice

Here’s the irony: because Dice is so easy to verify, it’s equally easy to tamper with quietly. Patterns documented in the Dirty Tricks book include:

  • Multiplier rounding-down: pays 1.98× when the true value is 1.9888×.
  • Verify-tool divergence: in-app “verify” button uses a different formula than the production round generator.
  • Modulo bias: roll computed as int(bytes) % 10000 with a k-bit domain that doesn’t divide cleanly, biasing low rolls.
Use a third-party verifier. Never trust the operator’s own “verify” button. Use our dice verifier instead. If your result and ours disagree for the same (server, client, nonce), one implementation is broken — and only one of us holds your money.

Strategy notes

With EV fixed at −1%, no betting pattern short of an operator exploit improves long-term return. What strategy can shape:

  1. Variance budget. Kelly-fraction bet sizing on your favorite multiplier doesn’t apply (Dice is −EV), but you can size to survive N rounds with high probability.
  2. Time on device. Higher win-chance settings make sessions feel longer and burn the same money over more rounds.
  3. Bonus clearing. When wagering bonus money, low-variance high-win-chance Dice clears wagering efficiently — see wagering contribution calculator. Remember that wagering requirements and variance can still eat the bonus value before you finish clearing it.

Frequently asked questions

What’s the lowest house edge Dice can have?

You’ll see operators advertise 0.5%, 0.25%, even 0% (usually with a wagering catch attached). In the formula, swap 99 for 99.5 or 99.75 — then verify a handful of real rounds yourself before depositing anything. Bias detection beats marketing copy every time.

Is there a “best” target?

In expected-return terms, no — they’re all −1%. In risk terms, absolutely. Match the multiplier to what you actually want: “double or lose” calls for 49.5 under (mult ≈ 2.0×); a moonshot means 1.0 under (mult ≈ 99×).

How would I detect modulo bias in a real operator’s dice?

Export several thousand of your rolls to CSV. Run them through the Kolmogorov-Smirnov test against uniform [0, 100]. A p-value below 0.01 says the distribution isn’t uniform — either bad luck on your end or bias on theirs. Follow up with the modulo bias detector to calculate the theoretical maximum bias given the operator’s domain size.