TRUST & ENGINEERING
Can digital dice be trusted? Seeds, replay and fairness
Trust in digital dice takes more than a convincing animation. It requires understanding the random source, face distribution and audit trail.
Where randomness comes from
Without a provided seed, Dice Core requests 128 bits from the environment’s cryptographic source through Crypto.getRandomValues. If that source is unavailable, execution fails instead of silently falling back to Math.random.
The seed feeds a deterministic pseudorandom generator. This enables replay; it does not make the sequence unpredictable once the seed is public.
d20Try in playground ↗No hidden edge for a face
A simple modulo conversion can favor certain faces when the input range is not divisible by the number of sides. The runtime uses rejection sampling to discard values outside the balanced range.
A correct implementation aims for a uniform distribution, but documentation cannot replace code review, tests and trust in the execution environment.
Replay explains, but does not prove nobody cheated
A replay descriptor stores what is needed to repeat execution against the same plan. It helps investigate differences and show how a total was computed. A manually chosen seed makes an outcome predictable.
In competitive play, control of execution, seed and publication remains part of the trust model. Dice View presents already resolved values; physics does not choose the game result.
Sources and references
IN USE
Meet the products already building.
The architecture comes to life in a Discord bot and a virtual tabletop.