Are Mini Kraken's Dice Rolls Fair? A Look Inside the Dice Engine
Every table eventually asks it: is this thing rigged? Here is an honest, jargon-free tour of how Mini Kraken picks a number — why it is fair, how you can verify it, and what we never do behind the scenes.
A run of bad luck can make any table ask whether its roller is rigged. The answer should come from implementation and observations, using criteria other people can check.
Mini Kraken's frontend engine maps integers to faces through rejection sampling, avoiding modulo bias under a uniform-source assumption. We also publish a reproducible technical audit: 14.4 million Dicecore 3.7.1 faces, 44 primary tests, five charts, every seed and the analysis scripts. No primary test rejected its model after Holm adjustment at a 1% family significance level. This supplies evidence without turning a finite sample into proof of perfect randomness.
What fair dice mean
In a fair d20 model, each face has probability 1 in 20. Independence means that knowing earlier results does not change the next outcome's distribution. These are separate properties: balanced counts can coexist with dependence.
The model does not require all twenty faces to appear in twenty rolls or demand compensation after bad outcomes. Three 1s at three prespecified positions have probability 1 in 8,000. Finding some such run in a long session is a different question with many opportunities for occurrence.
Where a roll comes from
The frontend uses the public @erpg/dicecore API with xoshiro128ss. The library default without that option is MT19937. Without a supplied seed, the engine requests 128 bits from Web Crypto to initialize isolated state per call.
Xoshiro and MT19937 are deterministic, non-cryptographic PRNGs. Cryptographic seed acquisition does not make them cryptographic generators. We therefore distinguish face distributions, reproducibility and resistance to tampering.
The audited npm 3.7.1 package declares MIT. The public fork repository has separate current license terms; inspect the version you intend to use. The original upstream library is also available for inspection.
Why rejection sampling is used
Taking a random word modulo the number of sides can favor some faces because the source interval is not always a multiple of that number.
The engine accepts an interval whose size is a multiple of the sides. If a word falls in the excess region, it consumes another word before producing a face. Every face has exactly the same number of preimages in the accepted interval. Given uniform independent words, each face of an s-sided die has probability 1/s.
The technical article proves this mapping and separates it from assumptions about the PRNG. Rejection occurs before a face exists; it is not choosing among completed rolls to improve an outcome.
3D animation presents computed faces
In the examined frontend path, the engine computes a roll before sending faces to the 3D adapter. Appearance, texture and animation present that result. The audit measures API faces, not a physics simulation used as the random source.
The backend and Fortuna have a Go runtime. The published study measures the JavaScript package in Node and Chromium; it does not certify every runtime or all players' histories.
Replay verifies consistency
A replay descriptor preserves seed, algorithm, versions and formula plan. Running the formula with that descriptor permits an exact comparison with the original faces. Every one of the study's 14.4 million faces passed this comparison.
Replay alone does not establish that nobody searched for a favorable seed, modified a client or altered history. Those guarantees need an additional protocol. Its role here is exact verification of the identified engine's inputs and outputs.
When impressions and statistics differ
Advantage, disadvantage and sums have distributions different from an isolated face. For 2d20 with advantage, a 20 has probability 9.75%, while a 1 has probability 0.25%. A 2d6 sum produces 7 more often than 2. These follow from rules applied to fair faces.
A short session is also not required to produce balanced counts. To investigate a suspicion, retain raw outcomes, choose tests before inspecting the sample, and account for uncertainty and multiple comparisons. Do not repeat collection or analysis until it yields your preferred conclusion.
Read Why Fair Dice Feel Rigged for the perception of streaks. Use the technical audit with data and reproduction instructions to verify the measured implementation, or try the dice roller.