Quantum Roulette · IBM Quantum

Experience real randomness.

Measure

Options Options: 2Clear

Separate with new lines or commas. One line like "ramen, curry, soba" is fine.

Presets Yes / No Lunch Chores Order

Everyone's observation history

Cumulative tally of outcomes produced by quantum hardware bits on this page (device-RNG fallbacks are excluded). We record nothing about who or when — only the number of options and where it landed. If the source is truly uniform, every position should even out over time. That, too, is part of "check it yourself."

Ordinary computer randomness is not random

This is the important part, so please try it rather than take my word for it.

The "random numbers" a computer produces are a sequence computed from a seed. Multiply, add, take a remainder. That is all. So put in the same seed and the same "random" numbers come back, every time.

Seed Roll a die 10 times

—

Press it again without changing the seed.

That is a pseudo-random number. It looks scattered, but anyone holding the seed knows exactly what comes next. Math.random() and the Mersenne Twister are the same shape — more digits and more mixing, nothing more.

Cryptographic randomness (crypto.getRandomValues) is better: it stirs in noise from the outside world — mouse movement, electrical jitter — as seed material. But the shape is unchanged: gather a seed, run a deterministic calculation. If the seed leaks, so does every output.

This is where quantum differs. A measurement outcome is not determined by any variable that existed before the measurement. There is no seed. Not "we haven't found it yet" — this is Bell's theorem, a mathematical result, confirmed experimentally (the confirmation won the 2022 Nobel Prize in Physics). So the quantum roulette can say "before this spin, nobody knew."

Why commit first?

The thing worth being suspicious of is whether the server is choosing the result. If the bits were generated at the moment you spin, the server could look at all your options and pick bits that land wherever it likes.

So the order is reversed. Before you spin, the server fixes the bits and hands you only a hash. At that moment it does not even know how many options you have. Deciding the bits without knowing the option count makes steering toward a particular option impossible in principle.

After the spin the bits and salt are revealed, and the hash is recomputed inside your browser (step 04 above). If it matches, nothing was swapped in afterwards.

The spin is theatre

Being straight about it: the result is decided before the wheel starts moving. The bits are revealed first, the winner comes out of them, and the animation is calculated backwards to land there.

Spinning it "physically" in the browser would just mean Math.random() decides, which has nothing to do with quantum mechanics.

The "superposed glow" before you measure is also a metaphor. The real superposition happens inside IBM's hardware; this screen only draws the result it receives. There is no superposition in your browser.

About modulo bias

Taking a 32-bit value modulo the number of options makes small indices slightly more likely (2³² is not divisible by most numbers). Values outside the divisible range are discarded and redrawn — and when that happens, the page says so and shows the redrawn bits.

The rigged one is right next door

The fastest way to understand why the commitment matters is to see what happens without one. On the rigged roulette you pick the winner first — and the bits it shows and the modulo genuinely check out, because the bits were computed after the winner was chosen.

While they spin, you cannot tell the two apart. The difference only appears when you check the commitment. → Try the rigged one

What you still have to take on trust

All of it, plainly. Hiding this would defeat the point of the page.

You cannot verify that the bits really came from IBM hardware. I display "hardware", and that is all. The job-submitting code is public, but whether it is actually running is something you take on trust.

The commitment only rules out swapping after the spin. When the seal is made, I know what the bits are. I cannot aim them, because I don't know the option count — but that is the limit.

If you need something stronger, see the randomness beacon (JSON). It publishes bits at a fixed time each day and publishes the hash of tomorrow's bits today, so anyone can confirm that tomorrow's randomness is already frozen.

When you need a proper draw

The roulette keeps no records. You can spin as often as you like and there is no evidence you did, which makes it unsuitable when you need to show a draw was done properly. For that, use Quantum Draw, which issues a certificate and publishes verification code anyone can run.

Running a giveaway for a business? Quantum Draw is free to use as it is. If you want it built into your own site or app, or certificates that carry your company name, get in touch — asking costs nothing.

Open source

Including the IBM hardware integration: toriumib/quantum-roulette (MIT).

Other things on the same hardware

Quantum Draw, the randomness beacon (JSON, for developers), Quantum Koan, and the Quantum Itinerary Solver.