Audit Verdict
The repo is the credential. You don't have to trust us — every finding ships as code. Run npm test to re-run the full audit: 17 verification steps, 98M simulated rounds, 6,700 live bets re-verified.
Dice Audit Overview
This audit independently validates the Dice game operated by Duel.com across five domains: deterministic outcome generation, entropy integrity, live-to-verifier parity, RTP mathematical accuracy, and fairness integrity testing. We placed 6,700 real bets across 134 seed pairs and independently verified every single outcome using our own implementation of the algorithm.
What Was Audited
- The RNG algorithm is deterministic and verifiable
- Server seeds are cryptographically committed via SHA-256 before play
- Client seed is browser-generated and players can customize it
- Nonces increment correctly and are never reused
- Dice results are computed via HMAC-SHA256 with rejection sampling (RANGE=10001)
- Results are reproducible from server seed, client seed, and nonce
- Payout logic matches the published formulas — win condition, multiplier, and win chance verified to machine precision
- Theoretical RTP is 99.9% across all targets (flat 0.1% house edge)
- Bet amount does not influence the RNG or dice result
- Players can independently verify every bet
What Audit Covers
| Area | Description |
|---|---|
| Commit-Reveal System | SHA-256 server seed hashing, pre-bet commitment, reveal on rotation |
| Client Seed Origin | Player-controlled seed, browser-generated — server commits before your seed is known |
| Seed Handling | Client seed control, nonce lifecycle (0–49), seed pair rotation |
| RNG Analysis | HMAC-SHA256 rejection sampling algorithm verification, bias analysis, external entropy assessment |
| Payout Logic | Win condition accuracy, multiplier formula, win chance formula, bet-size invariance (Phase C) |
| Live Parity | Independent result recomputation vs live game results |
| RTP Validation | Anti-circularity via live formula verification (Steps 9–10) with sampling-uniformity gate (Step 13), simulated RTP (98M rounds), cherry-pick detection (Pass 2) |
| Fairness Integrity | Standard integrity matrix — 15 tests across nonce, seed commitment, determinism, isolation, and payout enforcement |
What Audit Guarantees
- Outcomes are deterministic and reproducible from the recorded inputs
- Live game results match independent recomputation for the verified sample (6,700 / 6,700)
- Result distribution follows uniform [0, 10000] with unbiased rejection sampling
- RTP is proven analytically: win_chance × multiplier = 0.999 for all targets
- Client seed is a genuine, browser-generated input that materially influences results (100% result change rate)
- The house edge is 0.1% flat across all targets
- All standard fairness integrity checks passed at audit time
- House edge mechanism is transparent — RANGE=10001 produces a flat 0.1% edge for every possible target
What Audit Excludes
- Infrastructure or server security
- Wallet, payments, or operational systems outside game logic
- Rakeback layer — 99.9% is the certified RTP; rakeback is operator-side
- Cross-account sampling
- Max win cap enforcement — not embedded in game logic
References
Dice — Game Rules7 sections▶
Dice is a variable-odds betting game: pick a target and a direction (Roll Over or Roll Under), and win if the result lands on your side. Higher risk means lower win probability and higher payouts.
Dice is a single-outcome betting game. The player chooses a target value and a direction — Roll Over (win if the result is greater than the target) or Roll Under (win if the result is less than the target). The result is an integer drawn from a uniform distribution over [0, 10000] — 10,001 equally probable outcomes — determined by a single HMAC-SHA256 computation with bias-free rejection sampling. The further the target is from 50, the lower the win probability and the higher the payout.
1. Choose direction — Pick Roll Over (win if result is greater than target) or Roll Under (win if result is less than target). Toggling direction mirrors the win zone on the slider.
2. Choose target — Select a target value. The game UI displays this as 'Roll Over' or 'Roll Under' from 2.00 to 99.98 (API range: 200–9998). The further the target is from 50, the lower the win probability and the higher the payout.
3. Enter bet amount — Choose how much to wager.
4. Place the bet — The platform generates a dice result from the committed server seed, your client seed, and the current nonce.
5. Outcome — If the result is on your chosen side of the target, you win. Payout = bet amount × multiplier.
The win condition in Dice is a simple threshold comparison against the chosen direction.
| Direction | Win Condition | Example |
|---|---|---|
| Roll Over | result > target | target=5000, result=7234 → Win at 1.998× |
| Roll Under | result < target | target=5000, result=3100 → Win at 1.998× |
The core mechanic of Dice is the tradeoff between target distance and payout size.
- Target controls probability — targets close to 50 mean ~50% win chance and ~2× payout; targets far from 50 (in either direction) mean lower win chance and higher payouts
- House edge is flat — every target and direction has the same theoretical RTP (99.9%) and house edge (0.1%)
- Variance scales with distance from 50 — a 2% win chance / ~50× payout setting (Roll Over 98.00 or Roll Under 2.00) is far more volatile than a 80% / ~1.25× setting (Roll Over 20.00 or Roll Under 80.00)
| Parameter | Value | Notes |
|---|---|---|
| Target | 200–9998 | Platform-enforced range; UI displays as "Roll Over" 2.00–99.98 |
| Bet Type | over | Result must exceed target |
| House Edge | 0.1% (flat) | Identical across all targets |
| Theoretical RTP | 99.9% | Verified for all targets |
| RNG Algorithm | HMAC-SHA256 | One HMAC call per bet; key = hex-decoded server seed |
| RANGE | 10001 | Produces result in [0, 10000]; source of 0.1% edge |
Every Dice bet uses three cryptographic inputs to generate the result.
| Seed Type | Format | Example | Purpose |
|---|---|---|---|
| Server Seed | 64-char hex (32 bytes) | 528555039caf67c0… | Casino-provided randomness |
| Client Seed | Alphanumeric string | bRNvtSn0hp2uVFRe | Player-contributed entropy |
| Nonce | Integer (0–49) | 23 | Ensures uniqueness per bet within epoch |
Win chance and multiplier are fixed mathematical functions of the target. The 0.999 factor in the multiplier formula is the source of the 0.1% house edge.
win_chance = (10000 − target) / 10001
multiplier = 0.999 / win_chance| Target | Win Chance | Multiplier | RTP |
|---|---|---|---|
| 200 | 97.9902% | 1.0195× | 99.9% |
| 2000 | 79.9920% | 1.2489× | 99.9% |
| 5000 | 49.9950% | 1.9982× | 99.9% |
| 9000 | 9.9990% | 9.9910× | 99.9% |
| 9800 | 1.9998% | 49.9550× | 99.9% |
| 9998 | 0.0200% | 4995.4995× | 99.9% |
Why Provably Fair Matters▶
Traditional online casinos require players to trust that games are fair. Provably fair systems eliminate this trust requirement by allowing players to mathematically verify that outcomes were not manipulated. In a Provably Fair system:
- The casino commits to a result before the player bets
- The player contributes randomness that the casino cannot predict
- Anyone can verify the outcome after the fact
High-Level Overview8 sections▶
Checklist Reference
Based on the ProvablyFair.org Audit Execution Checklist, here are the tests covered under this audit document.
1. Commit-Reveal System & Seed Handling
| Test | Description |
|---|---|
| Server seed commit exists before play | SHA-256 hash shown to player before betting |
| Server seed reveal matches commit | SHA-256(hexDecode(revealed)) = committed hash |
| Client seed control | Player can set/change client seed via rotation UI |
| Nonce increments correctly | Starts at 0, +1 per bet, resets at epoch boundary |
| Full determinism | Same inputs → same result |
2. Randomness & Entropy Model
| Test | Description |
|---|---|
| RNG depends only on seeds + nonce | No external inputs — self-contained HMAC-SHA256 |
| No mixed entropy sources | No timestamps, Math.random, etc. |
| Unbiased mapping | Rejection sampling eliminates modulo bias for RANGE=10001 |
| No state leakage | Each bet uses unique HMAC message (clientSeed:nonce) |
3. Verifier ↔︎ Live Parity
| Test | Description |
|---|---|
| Live outcomes match verifier | 6,700 / 6,700 results recomputed with 0 mismatches |
| Multi-phase verification | Phases A (all targets), B (deep sample), C (bet-size check), D (client seed) |
| Bet-size invariance | $10 bets produce same RNG as $0.01 bets |
4. Game Logic & RTP Validation
| Test | Description |
|---|---|
| Anti-circularity (Steps 9–10 + 13) | Live multipliers and win chances match independently derived formulas; uniformity precondition gated |
| House edge audit | 0.1% flat confirmed across all targets |
| Payout rules correctness | Win amount matches multiplier × bet within 1e-8 |
| Simulated RTP convergence | 98M rounds converge on theoretical 99.9% |
| Cherry-pick detection | 9 flags, binomial p within expected range (not significant) |
5. Fairness Integrity & Player Verification
| Test | Description |
|---|---|
| Player can reproduce results offline | Using seeds + nonce |
| Verifier logic matches live logic | Same HMAC-SHA256 rejection sampling algorithm |
| Verifier publicly accessible | ProvablyFair.org verifier — no login required |
| No reliance on private APIs | Fully client-side verification |
| 15 fairness integrity tests | Nonce, seed commitment, determinism, isolation, payout enforcement |
To get an overview of how the process works, here is a high-level breakdown:
1. Player Bets — Selects target value (200–9998) and bet amount
2. Seeds Combined — HMAC-SHA256(hexDecode(serverSeed), clientSeed:nonce)
3. RNG Output — 4-byte hash chunks scanned; rejection sampling with RANGE=10001
4. Result Determination — result = chunk % 10001, integer in [0, 10000]
5. Win Check — win if result > target; multiplier = 0.999 / win_chance
6. Payout Result — win_amount = bet_amount × multiplier
Provably fair gambling systems use cryptographic primitives to guarantee the integrity of outcomes. The model relies on three components: a server seed committed via hash before play, a player-controlled client seed, and an incrementing nonce. These inputs are combined using HMAC-SHA256 to produce deterministic, verifiable results. This section documents the global provably fair architecture used by almost all casinos and all relevant games.
The Commit-Reveal model is integral to ensuring fairness and transparency in online gambling. This model involves several key phases:
Commit Phase:
Before any bets are placed, the casino generates a random server seed. To prove its authenticity and prevent later manipulation, only the SHA-256 hash of the hex-decoded seed is sent to the player. This ensures that while the player cannot know the seed initially, they can verify it later.
Bet Phase:
The player places their bet. The server combines the server seed with the player's client seed via HMAC-SHA256 to compute the dice result. Each epoch uses the same server seed and client seed pair.
Reveal Phase:
After the epoch ends, the server rotates seeds and reveals the plaintext server seed. The player can now independently verify SHA-256(hexDecode(serverSeed)) = committedHash.
Verify Phase:
Anyone can recompute every bet's result from the revealed server seed, client seed, and nonce using the published HMAC-SHA256 rejection sampling algorithm.
The player's client seed is generated by the browser and submitted to the server via the seed rotation UI. Players can set their own client seed at any time. This ensures:
- The casino cannot predict the full RNG input
- Players contribute entropy that they control
- Results depend on both parties' inputs
Nonce Lifecycle
The nonce is a counter that increments with each bet within an epoch:
- Starts at 0 for each new server seed
- Increments by exactly 1 per bet
- Never reused within the same seed epoch
- Resets to 0 when the server rotates to a new server seed
Seed Epoch: (serverSeed, clientSeed)
Bet 1: nonce = 0 → Result A
Bet 2: nonce = 1 → Result B
Bet 3: nonce = 2 → Result C
...
[Player rotates seed — epoch complete]
Next bet: nonce = 0 → Result X (new seed pair)Determinism Guarantee
Given identical inputs, the output is always identical:
key = hex_decode(serverSeed)
message = clientSeed + ":" + nonce
hash = HMAC-SHA256(key, message)
scan 4-byte chunks → reject if ≥ MAX_FAIR (4294959453)
result = chunk % 10001 → integer [0, 10000]
win = (result > target)Technical Glossary7 categories▶
| Term | Definition |
|---|---|
| Provably Fair | A cryptographic system that allows players to mathematically verify that game outcomes were not altered. Relies on commit-reveal schemes and deterministic algorithms. |
| Commit-Reveal Protocol | A two-phase process in which the casino commits to a result (by showing its hash) before the player bets, then reveals the actual value after the bet. |
| Determinism | The property that identical inputs always produce identical outputs. Same server seed, client seed, and nonce must always generate the same dice result. |
| Client Seed Origin | The method by which the client seed is generated. Full Pass: browser-generated default + player customizable seed. Conditional Pass: server-assigned default + player customizable seed. Hard Fail: player cannot set own seed. |
| Term | Definition |
|---|---|
| Server Seed | A random 32-byte value generated by Duel.com, transmitted as a 64-character hex string. Hashed and shown to players before betting, revealed after epoch rotation. |
| Client Seed | A random value controlled by the player, generated by the browser. Players can change it at any time via the seed rotation UI. |
| Nonce | A sequential counter (0–49) that increments per bet within an epoch. Resets to 0 when the server rotates to a new server seed. |
| Hashed Server Seed | SHA-256(hexDecode(serverSeed)) — the commitment hash shown before betting. After rotation, players verify the revealed seed produces this hash. |
| Epoch | A group of 50 consecutive bets sharing a single (serverSeed, clientSeed) pair. Each bet has a unique nonce (0–49). The epoch ends when seeds are rotated. |
| Term | Definition |
|---|---|
| HMAC-SHA256 | Hash-based Message Authentication Code using SHA-256. Duel Dice uses HMAC-SHA256 with the hex-decoded server seed as key and clientSeed:nonce as message. One call per bet. |
| Rejection Sampling | A technique to eliminate modulo bias. Hash chunks in the biased zone ([4294959453, 4294967295]) are discarded and the next chunk is tried. Ensures all 10001 outcomes are equally probable. |
| SHA-256 | Secure Hash Algorithm 256-bit. Used for server seed commitment: SHA-256(hexDecode(serverSeed)) = serverSeedHashed. |
| Hex Decoding | Converting a 64-character hex string to 32 raw bytes. Critical for the HMAC key — using the hex string as UTF-8 produces wrong outputs. |
| Term | Definition |
|---|---|
| Verifier | A tool that independently calculates dice results using provided seeds and nonce. The ProvablyFair.org verifier is built from the audit codebase. |
| Parity | Degree of matching between verifier and live game results. 100% parity = every result matches. This audit: 6,700/6,700 exact match. |
| Anti-Circularity | Proof that RTP derives from first principles, not casino's own claims. For Dice: live multipliers and win chances are verified against independently derived formulas on all 6,700 bets (Steps 9–10), and the sampling-uniformity precondition behind the closed-form EV is gated (Step 13). |
| Cherry-Pick Detection | Test for selective seed deployment. Pass 2 simulation runs 134 revealed seeds × 10,000 nonces, comparing early vs late distributions to detect biased seed selection. |
| Term | Definition |
|---|---|
| Target | Player-selected threshold (200–9998). The dice result must exceed this value to win. Higher targets = lower win chance, higher multiplier. |
| Result | The integer output of the RNG, in [0, 10000]. 10,001 equally probable values produced by HMAC-SHA256 with rejection sampling. |
| Win Chance | The probability of winning: (10000 − target) / 10001. Exact for all targets. |
| Multiplier | The payout ratio for a winning bet: 0.999 / win_chance. The 0.999 factor is the source of the 0.1% house edge. |
| RANGE | The number of discrete outcomes (10001). Using 10001 instead of 10000 shifts the denominator by 1, producing a flat 0.1% house edge for every target. |
| Term | Definition |
|---|---|
| Seed Pair | A (serverSeed, clientSeed) combination used for a sequence of bets. Each pair defines one epoch of 50 bets. |
| Phase | A structured data collection segment. Phase A: random targets (200–9998). Phase B: fixed target 9800. Phase C: $10 bet-size check. Phase D: custom client seed. |
| Scored Step | One of 17 verification checks that contribute to the audit verdict. PASS/FLAG/FAIL. All 17 passed in this audit. |
| Informational Context | Statistical observations reported for transparency but not scored — live-bet chi-squared, serial independence, and empirical RTP are underpowered at sample sizes below ~100K. |
| Term | Definition |
|---|---|
| dice-master-6700bets.json | The 6,700-bet dataset used throughout this audit. Contains all bets and 138 seed entries across four phases. SHA-256: 3550ffca07a6f7825f96cdd4e3d8c3cd57898b5b5238b9739753a754cff056d6. |
| verification-results.json | Output of the 17-step verification suite. Contains all step results, seed hash checks, result recomputation logs, and simulation artifact verification. |
| simulation-results.json | Two-pass simulation output: Pass 1 (98M rounds, fresh seeds) and Pass 2 (134 casino seeds × 10K nonces, cherry-pick detection). |
Every Dice game on Duel.com is generated from three inputs: server seed, client seed, and nonce. The casino commits to its server seed by publishing a SHA-256 hash before you place any bets. After you rotate your seed, the server reveals the actual seed — and anyone can verify that the hash matches. This cryptographic commitment makes it impossible for the casino to secretly change your outcome after you bet.
What We Verified
- Casino commits to the server seed hash before any bet is placed
- Client seed is browser-generated — server cannot know it at commitment time (Full Pass origin)
- Players can set or change their client seed at any time via the rotation UI
- Nonce increments by 1 per bet with no gaps or duplicates across 134 seed pairs
- Dice results are fully determined by the seed inputs before the outcome displays
- Identical inputs always produce the same result — confirmed across all 6,700 bets
- Your client seed is a genuine input — changing it changes the outcome in 100% of sampled tests
What This Means for You
- The casino cannot change your dice result after you bet
- You contribute randomness the server cannot predict or pre-select against
- Every bet is unique — the nonce ensures no two bets share an outcome
- Any result can be independently verified using the public tools and repo
- Outcomes are tamper-proof and verifiable even months later
| Test | Status | Finding |
|---|---|---|
| Server seed committed before bet | Pass | SHA-256 hash of server seed published before play — casino cannot change randomness after betting |
| Client seed origin | Pass | Browser-generated (Full Pass) — server commits before client seed is known |
| Client seed control | Pass | Player can set/change client seed via rotation UI at any time |
| Nonce sequencing | Pass | Sequential within each seed pair, 0 gaps, 0 duplicates across 134 seed pairs (4 capture-retry epochs reconstructed from revealed seed) |
| Hash consistency within seed pair | Pass | server_seed_hashed constant across all bets within each of 134 seed pairs |
| Seed hash integrity | Pass | 134 / 134 revealed seeds hash-verified — commitment chain intact |
| Deterministic output | Pass | Same (serverSeed, clientSeed, nonce) always produces same result — 6,700/6,700 confirmed |
| Client seed participation | Pass | Client seed is a genuine input — changing it changes the dice result in 100% of sampled tests |
All 134 revealed seeds hash-verified. Every seed rotation was verified — the next seed the casino pre-committed always matched what was actually used. Outcomes are fully deterministic — the same server seed, client seed, and nonce always produce the same dice result. The casino cannot change your result after you bet.
This section verifies that Duel.com's Dice random number generation produces cryptographically sound, unbiased outputs using only the disclosed inputs. The RNG uses HMAC-SHA256 with one call per bet — the result is derived from 4-byte hash chunks via rejection sampling with RANGE=10001, producing a uniform integer in [0, 10000]. We independently implemented this algorithm, verified it produces the same results as the live game, and confirmed no hidden inputs can influence outcomes.
What We Verified
- HMAC-SHA256 produces cryptographically sound, unpredictable output for each bet
- Only disclosed inputs affect outcomes — no timestamps, no server-side state, no hidden entropy
- Rejection sampling with RANGE=10001 eliminates modulo bias — all 10,001 outcomes equally probable
- Result distribution matches theoretical win rates for all 98 target values (confirmed over 98M simulated rounds)
- Consecutive outcomes are statistically independent — no patterns, no streaks
- 100% of outcomes change with a different client seed (670/670 sampled tests)
What This Means for You
- Each dice roll is generated fairly and cannot be skewed toward any outcome
- All 10,001 possible results are equally likely — no value is favoured
- No hidden randomness or server-side tricks influence the result
- Consecutive bets are not correlated — past results don't affect future outcomes
- The algorithm depends only on seeds you can verify
| Test | Status | Finding |
|---|---|---|
| RNG derived only from disclosed inputs | Pass | HMAC-SHA256(hexDecode(serverSeed), clientSeed:nonce) — no hidden entropy |
| Entropy purity | Pass | No timestamps, external APIs, Math.random, or server-side state |
| Algorithm independently implemented | Pass | Independent implementation produces identical results for all 6,700 bets |
| Modulo bias | Pass | Rejection sampling eliminates bias — RANGE=10001 maps uniformly onto [0, 10000] |
| Key encoding verified | Pass | Server seed hex-decoded to bytes (not UTF-8) — confirmed via 6,700-bet recomputation |
| Serial independence | Pass | Lag-1 autocorrelation near zero and runs tests pass across all 98 targets at 1M rounds each |
| Client seed influence | Pass | 100% of sampled outcomes change with an alternate client seed — confirmed across 670 sampled bets |
The Dice RNG uses only the disclosed inputs, produces uniform result distribution across all target values, and shows no serial dependence across 98M simulated rounds. Rejection sampling ensures all 10,001 outcomes are equally probable. The client seed is a genuine input — 100% of sampled outcomes change with a different seed.
This section validates that the independent verifier produces the exact same dice result as the live game for every single bet. It also confirms the win condition and that every payout matches Duel's published multiplier formula. Any mismatch would invalidate the fairness guarantee.
What We Verified
- Every bet independently recomputed from seeds — full dice result verified, not just the payout
- Payout correctness: win_amount = bet × multiplier, exact to 8 decimal places for all 6,700 bets
- All formulas verified: win condition, multiplier, and win chance confirmed to machine precision
- Bet amount is not an input to the RNG — dice result depends only on seeds and nonce
- All four capture phases recomputed identically (target coverage, statistical validation, elevated stake, client seed variation)
What This Means for You
- The verifier isn't a simulation — it produces the exact same result as the live game
- Every bet you play can be independently recomputed by anyone
- No hidden logic alters outcomes based on how much you bet or how you play
- The game engine in production matches the published algorithm exactly
| Test | Status | Finding |
|---|---|---|
| Result recomputation | Pass | 6,700/6,700 exact match — dice result verified for every bet |
| Payout correctness | Pass | All 6,700 bets: win_amount = bet × multiplier, exact to 8 decimal places |
| Win condition integrity | Pass | All 6,700 bets: is_win = (result > target) with zero errors |
| Multiplier formula integrity | Pass | 0.999 / ((10000 − target) / 10001) verified for all 6,700 bets — zero mismatches |
| Bet-size independence | Pass | Bet amount is absent from the RNG input — dice result depends only on seeds and nonce |
| Multi-phase coverage | Pass | 4 structured phases: target coverage (A), statistical validation (B), elevated stake (C), client seed variation (D) |
All 6,700 bets matched the independent verifier exactly — dice results verified across all four capture phases. Payout math correct. Win condition, multiplier formula, and win chance formula all verified to machine precision.
This section mathematically verifies that the 0.1% house edge is exactly what's advertised across all target values. The key test is anti-circularity: we derive the win chance from the RNG's integer range (uniformity precondition gated in Step 13) and verify the published multiplier formula against all 6,700 live bets (Steps 9–10) — so no casino-supplied probability data enters the computation. We then confirm it against 98 million simulated rounds and test whether the casino pre-selected favourable seeds.
What We Verified
- House edge is exactly 0.1% flat — confirmed from the published formulas and independently derived
- RTP proven from first principles: win_chance × multiplier = 0.999 for every target — algebraic identity
- 98M-round simulation converges on theoretical RTP (mean 99.922%)
- Cherry-pick detection: 134 casino seeds tested — no evidence of seed pre-selection
- Bet amount does not influence dice result — confirmed at $0.01 and $10
What This Means for You
- The house edge on Dice is a flat 0.1% of every bet, the same regardless of the target you pick
- The RTP proof is derived independently — it doesn't rely on trusting the casino
- The casino's seeds show no evidence of being chosen to produce favourable early outcomes
- Your bet amount doesn't affect the dice roll
- The flat 0.1% edge is transparent — implemented via RANGE=10001 in the denominator
| Test | Status | Finding |
|---|---|---|
| Anti-circularity | Pass | Live values match independent formulas on all 6,700 bets (Steps 9–10); EV = 0.999 follows in closed form with the uniformity precondition gated (Step 13) |
| House edge audit | Pass | 0.1% flat across all targets — implemented via RANGE=10001 denominator |
| Simulated RTP (Pass 1) | Pass | 98M rounds, avg RTP = 99.922%, 0/98 chi-squared failures, 0/98 serial independence failures |
| Cherry-pick detection (Pass 2) | Pass | 134 casino seeds tested — no evidence of seed pre-selection |
| Bet-size invariance | Pass | Bet amount is not an input to the RNG — same result distribution at $0.01 and $10. Tested in Phase C (200/200) |
| Multiplier formula | Pass | 0.999 / ((10000 − target) / 10001) verified for all 6,700 bets — zero mismatches |
| Win chance formula | Pass | (10000 − target) / 10001 exact to 14 decimal places for all 6,700 bets |
The 99.9% RTP is proven mathematically — win_chance × multiplier = 0.999 is an algebraic identity for every target. This is a first-principles proof, not a statistical estimate. 98M simulated rounds and cherry-pick detection confirm no anomalies. The 0.1% house edge is flat and transparent.
Sections 1–4 prove the game is mathematically fair. Section 5 proves the implementation maintains integrity under non-standard conditions. We applied 15 standard fairness integrity tests covering nonce integrity, seed commitment, outcome determinism, cross-player isolation, and payout integrity. 14 tests passed and 1 is not applicable to this game type.
What We Verified
- Nonce tampering — can the sequence be forced, replayed, or skipped?
- Seed injection — can server or client seed fields be overridden via API?
- Outcome replay — can a completed bet be replayed for duplicate payouts?
- Cross-player isolation — can one player's seeds or outcomes affect another's?
- Payout tampering — can multiplier or payout values be injected client-side?
- Parameter limits — can invalid target values or bet types be submitted?
What This Means for You
- Across the 15 tests we ran, no API path allowed outcomes to be altered, replayed, or injected — by player or casino
- Once a bet is placed, the result cannot be changed or replayed
- Each bet is cryptographically unique and isolated
- Your results are independent of every other player
- The server rejects malformed, out-of-range, and duplicate requests
| Test | Status | Finding |
|---|---|---|
| Nonce integrity | Pass | Sequential, server-controlled, no gaps or duplicates across 134 seed pairs |
| Seed commitment integrity | Pass | Locked at bet acceptance, unique per seed pair — 134/134 verified |
| Outcome determinism | Pass | Identical inputs produce identical outcomes — 6,700/6,700 confirmed |
| Round & player isolation | Pass | Per-user seeds, serial independence confirmed (0/98 fail in simulation) |
| Payout integrity | Pass | Parameter limits enforced (5/5 invalid rejected); injected payout fields ignored (0 honoured); server-computed multiplier consistent across all probes |
15 standard fairness integrity tests: 14 pass, 1 N/A (single-step game).
Every Dice outcome can be independently reproduced using publicly disclosed inputs. No hidden variables, no private backend data. If your calculated result matches the game result, the bet was provably fair. This section walks you through the process — and provides an independent verification tool built from the same code used in this audit.
Key Principles
- Every Dice outcome can be independently reproduced
- No hidden variables — no private backend data
- If your computed result matches the game result, the bet was provably fair
- Most players can verify directly through the Duel.com fairness UI
What You Need
- Server Seed — revealed after seed rotation (casino entropy)
- Client Seed — your player-controlled seed
- Nonce — the bet number in sequence (ensures uniqueness)
Only disclosed inputs are used. Identical inputs always produce identical output.
Choose your direction (Roll Over or Roll Under), set your target (2.00–99.98) and bet amount, then place a bet. The dice rolls and shows a result on a 0.00–99.99 scale. The server has already committed to the outcome before you clicked.
Duel.com Dice — Roll Over / Roll Under slider with displayed result. Outcome is locked before the animation plays.
Open the Provably Fair modal on the game page. You'll see the active client seed, the hashed server seed (the casino's pre-commitment), and your current nonce. Below those, you can set the new client seed that will become active after rotation. Click 'Rotate seed' to retire the active seed pair and start a new one — this is what unlocks the revealed plaintext server seed for your previous bets in Step 3.
Provably Fair modal — active client seed, hashed server seed, nonce, customisable new client seed, next pair pre-commitment, and Rotate seed action.
Open Transactions and click a past Dice round. The per-bet modal shows the revealed plaintext server seed alongside the bet ID, client seed, and nonce. The pre-committed hash from Step 2 must match SHA-256 of this revealed seed:
Server Seed (revealed) — plaintext value the casino committed to before your bet. Hash it to confirm it matches the pre-commitment.
Client Seed — your player-controlled entropy input.
Nonce — the sequential bet counter for this seed pair.
Per-bet transaction modal — revealed plaintext server seed, client seed, and nonce for the round.
Click Verify in the per-bet modal to open the Provably Fair page with the seeds pre-populated. The page recomputes the dice result from the disclosed inputs and renders the Game Result inline. If the recomputed result matches your live game result, the bet was provably fair — the casino committed to the outcome before you bet, you contributed entropy via your client seed, and the result is mathematically reproducible by anyone.
Provably Fair page — seeds populated from the per-bet modal, recomputed result rendered inline matching the live game result.
This section consolidates the open-source repository, datasets, output artifacts, and reproducibility posture of the audit. Every finding, every statistic, every pass/fail result can be independently reproduced by anyone with a computer and an internet connection. The repository is the credential — not this report.
Repository Details
- GitHub: ProvablyFair-org/duel-dice
- Commit: 4380a5a9d715467f3a0184b32390dff60580fdb2
- Game: Dice (duel-dice)
- Public Verifier: audit.provablyfair.org/casino/duel/tools/verify-bets
Prerequisites
- Node.js 18+
- npm 8+
- Git
- TypeScript (installed via npm)
Repository Structure
Commands to Reproduce
Audit Reproducibility Pinning
All audit results can be independently reproduced using the pinned commit, dataset, and commands above. The dataset hash ensures you're running against the same 6,700 bets.