Every roll is fair, timestamped, and auditable.

Random Number Algorithm

We use the Web Cryptography API's <code>crypto.getRandomValues()</code> — the same source used for TLS key generation and AES encryption. This draws directly from your server's hardware entropy pool (Intel RDRAND or Linux's <code>getrandom()</code> syscall), which cannot be predicted or reproduced. Unlike most VTT platforms that rely on JavaScript's <code>Math.random()</code> — a non-cryptographic generator that can technically be predicted — ShadowRealms rolls are seeded by true hardware entropy.

// Single batch call for all dice in a roll expression
const buf = new Uint32Array(count + buffer);
crypto.getRandomValues(buf);

// Rejection sampling — eliminates modulo bias
const remainder = 4294967296 % sides;
const rejectFrom = 4294967296 - remainder;
// accept x only if x < rejectFrom → x % sides is uniform

Bias Elimination

We use rejection sampling (the Knuth uniform reduction method) to eliminate modulo bias — the subtle unfairness introduced when mapping a random number to a die face using the % operator. Our implementation rejects any raw value that would over-represent certain outcomes, ensuring a d6 truly has a 1-in-6 probability for each side.

Performance

Dice expressions are batched: one <code>getRandomValues()</code> call generates all dice in a single expression. A full 1000d100 roll completes in under 200 microseconds — 250× faster than the individual-call approach and well within our 50ms latency target.

The 5W Dice Log

Every roll creates a permanent, immutable ledger entry with five-dimensional provenance:

Integrity Seal

Each roll is immediately sealed with an HMAC-SHA256 integrity proof using a server-side secret. The seal binds the exact dice values, expression, and timestamp into a single cryptographic commitment. Any retroactive modification would produce a different hash that wouldn't match the stored seal.

Future roadmap: on-chain attestation via web3 (EAS on Base/Optimism, Merkle tree anchoring) for fully trustless verification.

Why We Can't Cheat

Dice log records are sealed with HMAC-SHA256 immediately on creation. The entropy proof (SHA-256 of the raw random bytes) ties the result to a specific draw from the OS entropy pool. Since we cannot control or predict hardware entropy, and the result is committed to an integrity-sealed ledger, manipulation is cryptographically infeasible.

Roll Syntax & Post Integrity

When you use the ::roll[expr] syntax in a post or message, the server resolves the roll on submission — the client never sees unresolved expressions. Each resolved roll is linked by ID; if someone tries to insert a roll ID from a different session or a fabricated ID, it renders as an 'Unverified Roll' badge, not as legitimate dice data.

Frequently Asked Questions