provably faircertified RNGfairness
Certified RNG means an independent lab examined a random number generator at a point in time and judged its output statistically sound. Provably fair means the game hands every player a cryptographic receipt for their own match, so each roll can be rechecked without trusting anyone. One model audits the machine. The other proves your game.
Both phrases appear on the trust pages of online games that roll dice for you, and they sound interchangeable. They are not. They answer different questions, they fail in different ways, and the difference decides what you are being asked to believe when you sit down to play.
What does certified RNG actually certify?
A certification lab takes a generator, runs its output through statistical test batteries, and hunts for bias: numbers that arrive too often, patterns that repeat, sequences that drift. If millions of samples look indistinguishable from chance, the lab signs a certificate. That work is real and it takes skill. It establishes that the generator, as tested, on that day, produced sound randomness.
Notice what the certificate cannot see. It was issued in a lab, and your dice are rolled on a server.
- Whether the code tested is the code deployed, months and many updates later.
- The wiring between the generator and your game: the code that turns a raw random number into your 6 and 4.
- Any individual roll in any individual match. Certification speaks about the generator in general, never about your Tuesday night game.
So certification carries a quiet second clause: trust that nothing changed since the test, and trust that the certified path is the one your game actually took. Most studios honor it. The point is that you cannot check. The model is an inspection of the machine at one moment, followed by faith in the deployment at every moment after.
What does provably fair mean?
Provably fair is a different bargain. Instead of pointing at an audit you never saw, the game commits to its randomness before play begins, then reveals enough afterward for you to recompute every roll yourself. The proof travels with the match. In practice it works like a sealed envelope.
Commit. Before the first move, the server generates a secret seed and publishes its SHA-256 fingerprint. The fingerprint reveals nothing about the rolls to come, but it pins the seed in place. Change a single bit of the seed later and the fingerprint no longer matches.
Roll. During play, each roll is derived from the seed with HMAC-SHA256, one computation per roll. The dice were decided the moment the envelope was sealed. A friendlier number cannot be slipped in mid-game without breaking the commitment already published.
Reveal. After the game, the seed is revealed. Anyone can hash it, compare against the commitment, recompute every roll, and set the results next to the dice that appeared on the board. If it all lines up, the game could not have been steered. If anything was tampered with, the math says so.
The trust moves from the company to the arithmetic. You no longer need to believe the audit was thorough or the deployment was faithful. You need SHA-256 to hold, which is the same assumption the rest of the internet leans on every day.
A certificate says the coin was fair the day we looked. A receipt says your flip was fair, and shows the math.
Does certification still matter?
Yes. Commit-reveal proves you received exactly the randomness that was committed. It does not prove that what was committed was good in the first place. A weak or predictable seed source would still produce receipts that validate perfectly: provable delivery of poor dice. Judging the quality of the source is exactly what audits and statistical testing are for, and in regulated industries a certificate is simply required.
The two models answer different questions. An audit asks: is the randomness any good? A receipt asks: did my game actually use it? A system with only the first runs on permanent faith in deployment. A system with only the second could faithfully deliver bad dice and prove it. The strongest systems close both doors.
Why does a public verifier matter?
Because a receipt no one can read protects no one. Some games publish commitments but give players no practical way to check them, or tuck verification inside the very app in question. That closes no loop. If the only tool that can vouch for a system belongs to the system, you are back to faith, now with extra steps.
The strongest setups publish three things. The commitment, before the game. The seed, after it. And an independent, public way to recompute the rolls: a plain web page, standard cryptography every browser already ships, no login in front of it. A skeptic who never played the match can audit it anyway.
That is the model we built Orion on. Every server-backed match commits to its dice with SHA-256 before the first roll, derives each roll with HMAC-SHA256, and reveals the seed when the game ends. The verifier at orion.arthea.ai/verify is live today. It recomputes the entire chain in your browser with Web Crypto, and it asks for no account, because a proof that requires permission is not a proof. The server also validates every move in live play at source. Honest dice deserve an honest board.
The door at orion.arthea.ai/go carries the App Store and Google Play links and always shows what is available right now. Behind it, every match from the first carries its own receipt.