How Our RNG Works — Provable Fairness in the Roulette Simulator

Why Fairness Matters — Even in a Free Simulator

You aren't risking real money on the CasinoMoneys roulette simulator. So why care about fairness at all? Two reasons. First, the educational point of the simulator is to show how probability behaves over time — if the underlying randomness is biased, every observed pattern, every house-edge curve, every strategy comparison becomes meaningless. Second, "fairness" in roulette has a specific technical meaning that is widely misunderstood: it is the difference between a uniformly random RNG and the long-run profitability of bets. The simulator gets the first right and is transparent about the second.

CSPRNG — Cryptographically Secure Pseudo-Random Numbers

The browser provides a built-in API called crypto.getRandomValues(). It is part of the Web Crypto API and is required to produce output that is statistically indistinguishable from true randomness, even to an adversary with significant computational resources. In practice, it draws bytes from the operating system's entropy pool — the same source that backs SSH keys, TLS session keys, password salts, and other security-critical operations.

This matters because earlier random functions like Math.random() are not cryptographically secure. Their internal state is small (typically 64 or 128 bits), and their output is in principle predictable if you observe enough samples. For a roulette simulator that wants to demonstrate the law of large numbers across thousands of spins, that potential weakness — however unlikely to ever matter in practice — is something the simulator avoids entirely.

Rejection Sampling — Eliminating Modulo Bias

A common mistake when generating a random number in a range like 0–36 is to take a random byte and apply modulo: randomByte % 37. This looks fair but is subtly biased. A byte holds 256 possible values; 256 ÷ 37 = 6 with remainder 34. That remainder means values 0–33 each get seven chances (six full cycles plus one extra), while values 34–36 get only six. Over millions of spins, low numbers would appear ~16% more often than high numbers — a serious bias.

The simulator avoids this by using rejection sampling:

1. Read a random byte (or 32-bit value) from crypto.getRandomValues().
2. If the value falls in the "safe" range — a multiple of 37 — accept it and take modulo 37 to get the spin result.
3. If the value falls in the unsafe remainder, discard it and try again.

The result: every pocket from 0 to 36 has exactly probability 1/37. No bias. The cost is occasional re-rolls, but with 32-bit input the rejection rate is so small (under 0.000001%) that it never causes a noticeable delay. American wheel spins use the same technique with modulus 38.

The Chi-Squared Test — Live Verification

Generating fair randomness is one thing; demonstrating it visibly is another. The simulator's "Provably Random" panel runs a live chi-squared (χ²) test on every spin you make. The test compares observed pocket frequencies against the expected frequency (~2.7% per number on a European wheel) and reports a single number summarising how unusual the deviation is.

The verdict shown in the panel translates the χ² value to plain language: "Within expected range," "Slight deviation — keep spinning," or "Unusual — but a CSPRNG can still produce streaks." Note that small samples (under ~200 spins) almost always look uneven; the test stabilises around 1 000+ spins.

House Edge vs Randomness — Two Different Things

This is the most common point of confusion when people say a roulette wheel "isn't fair." A perfectly fair RNG, where each pocket has probability 1/37, still produces a long-term loss for the player. That is because of the payout structure — not the randomness.

Notice that every bet on the European wheel has the same negative expected value — 2.70% per €1. That is the house edge, baked into the payout odds, not the wheel. A fair RNG guarantees this loss in the long run; an unfair RNG might accidentally favour the player. So when you hear that an online casino "rigs" outcomes against players, that would in fact be statistically detectable using exactly the chi-squared test the simulator runs live.

How to Verify the RNG Yourself

The simulator runs entirely in your browser. There is no server-side random generator. You can confirm this:

1. Open the roulette simulator page.
2. Open browser DevTools (F12 on Windows, Cmd+Option+I on Mac).
3. In the Network tab, spin the wheel — no XHR or fetch requests are sent.
4. In the Sources tab, search for getRandomValues to see the spin generator.
5. Disconnect from the internet and keep spinning — every spin still works.

If a casino were doing anything other than a fair draw, the data would be visible in the browser. The CasinoMoneys simulator is fully auditable.

Comparison With Licensed Online Casinos

Real-money online casinos use server-side RNGs that are audited by independent labs (eCOGRA, GLI, iTech Labs). Their RNG is typically a Mersenne Twister or a hardware-seeded variant. They publish certificates with chi-squared and Kolmogorov-Smirnov test results. The CasinoMoneys simulator uses a stronger generator (CSPRNG vs MT-19937) than most live casinos, but with one important caveat: real casinos must prove fairness after their RNG is locked behind their servers. Here, the entire process is in the open from the start.

Summary

• Generator: crypto.getRandomValues() — cryptographic, OS-seeded.
• Range mapping: Rejection sampling — no modulo bias.
• Distribution: Verified live with a χ² test on every spin.
• House edge: 2.70% (EU) / 5.26% (US) — a property of the payouts, not the RNG.
• Auditability: Pure client-side JavaScript. Inspect the source yourself.

→ Back to the roulette simulator  |  → Roulette odds chart  |  → Do betting systems beat the house edge?