Are Online Backgammon Dice Fair? Verify Them Yourself

2026-09-04

Are online backgammon dice rigged? The honest answer is: normally you have no way to know, because the entity rolling the dice is also the one producing the result and simply asks you to "trust me." On this board, it's different — the dice are generated using a method called commit–reveal, and after each game ends, you can recalculate and verify every roll on your own.

"It felt rigged" is not proof

Getting two sixes in a row or missing the exact number you needed at a critical moment is genuinely frustrating — but our memory is a terrible witness when it comes to dice. One outcome out of 36 possibilities happening once in 36 rolls is a normal event; getting the same result three times in a row is too. The brain remembers the moments that went wrong and forgets the fifty unremarkable rolls that came before. This doesn't make your suspicion invalid — it just means "I felt it" and "I proved it" are different things, and the method below gives you the second one.

The Method: Commit–Reveal

Before the first roll of a game, the server generates a 32-byte secret number (serverSeed) and publishes only its SHA-256 fingerprint (the commitment) — not the secret itself. The order here is critical: the commitment is made public before anyone knows the seed and before a single die is rolled, so the server cannot later say "actually, the secret was this" and have it match the fingerprint — the math won't work.

Then each player adds their own seed (client seed) — any free text you want, up to 40 characters; if you enter nothing, a random 8-byte seed is generated for you automatically. Your seed enters every roll calculation, which means the server cannot pick a secret number that would match if it guessed what you'd add later.

Each roll is calculated using the formula HMAC-SHA256(serverSeed, "whiteSeed:blackSeed:nonce"), where nonce is that roll's position in the game. The two dice come from the first two bytes of this HMAC output — but not every byte. Only bytes below 252 are used. Here's why, pure math: taking a byte value directly, dividing by 6, and using the remainder (byte % 6) favors the low faces by about 1.6%, because 256 does not divide evenly by 6. But 252 equals exactly 6×42, so any byte below this threshold represents all six faces with exactly equal probability. This detail is proof that someone actually cares about getting this right.

When the game ends, the secret (serverSeed) is revealed. From that point on, anyone — not just the two players — can recalculate every roll and compare it to the published fingerprint.

How to verify it yourself

On the board, there's a fairness panel: it shows the commitment (fingerprint) and marks the key as "sealed" until the secret is revealed. After the match ends, a Review page runs all the verification again for you. One important detail: the verification code in your browser does not import the server's own code — it's written independently, using your browser's own Web Crypto layer. So the proof doesn't depend on trusting the server's implementation; your own browser does its own math. Also, a server endpoint returns the result along with the name of the algorithm used — the source code's own label, not the proof itself, just a convenience. Finished matches are kept with their revealed dice logs for 400 days, so you can even verify a game from last season if you have doubts about it.

The board theme cannot change the dice

Structurally, the code that contains the roll logic never takes board or theme parameters in any of its functions — which means the board theme you choose, the color scheme you pick, cannot affect which die result comes next. No matter which of the four board designs you select, the code that calculates the dice stays the same.

Even who goes first is determined by the same system

The opening roll that decides who plays first is also part of the same verifiable chain. Both players each hold one die of a combined single roll — one roll represents white's die, one represents black's die; whichever is higher gets to start and plays both dice as their opening move. If both dice are equal, it's a tie and the roll repeats — but this repeat is also part of the chain, because the nonce advances and is recorded. How many ties happened before the real opening is even sent to the client separately, so even this count is not hidden from you.

What this method does not prove

To be honest: commit–reveal proves that the dice were not changed after the commitment and that everyone can recalculate them. You cannot know in advance which secret the server chose before publishing the commitment — but that doesn't matter, because your seed also goes into the calculation, so the server cannot choose an outcome based on seeing your input first. That is the claim of this method, nothing more and nothing less; we don't make an overblown promise that "everything is proven."

You can also measure your luck

The post-match review calculates the luck in every roll based on the position you were actually in at that moment — so "the dice beat me" is not a claim here, it's a number the game itself extracts and gives you. If you want to tell whether you really got unlucky or just played poorly, you can start by refreshing your rules at how to play backgammon, then improve your moves with the backgammon strategy tips guide. If you're looking for other 2-player opponents, the 2-player online games list is a good starting point too.

In short: your suspicion is legitimate, but now it has an answer. When you doubt a match, check the sealed key in the fairness panel and the verification on the Review page when it ends; run your own math if you want. The dice themselves stop being a subject of argument—what's left to discuss is the quality of your game.

Frequently Asked Questions