Proposed Single Game Structure
ProvablyFair.org — Dice Game Audit
Casino: DUEL
Game: Dice (duel.com/dice)
Audit Version: v1.0
Audit Date: January 30, 2026
Audited Commit: fa913ab
Public Certification: Provably Fair Certification
0. Dice Audit Overview
Purpose
This audit verifies that the DUEL Dice game behaves exactly as advertised.
It checks that outcomes are deterministic, reproducible, and match the public verifier, and that no known exploit paths were observed at the time of audit.
What Was Audited
✅ The RNG algorithm is deterministic and verifiable
✅ Server seeds are cryptographically committed before play
✅ Players can set their own client seeds
✅ Nonces increment correctly and are never reused
✅ Payout logic matches advertised multipliers
✅ Theoretical RTP is 99.91%
✅ Game outcomes are determined by a provably fair algorithm
✅ Players can independently verify every bet
✅ Commit-reveal cryptographic system verification
What This Audit Guarantees
Outcomes are deterministic and reproducible
Live game results match the public verifier
Randomness behaves as advertised
No known exploit classes were observed at audit time
What This Audit Does Not Cover
Infrastructure or server security
Wallet, payments, or custody systems
Operational controls outside game logic
Summary Verdict
Audit Verdict
Overall Status
✅ Pass
RTP Verified
✅ 99.91% ± [0.09% House Edge]
Live ↔ Verifier Parity
✅ 100% - All test rounds matched
Commit-Reveal System
✅ Passed - SHA-256 verified
Seed Handling
✅ Passed - Player control verified
RNG Analysis
✅ Passed - Unbiased via rejection sampling
Payout Logic✅
✅ Passed - All payouts verified correct
Known Exploits Tested
✅ Passed - 7/7 testable exploits
Determinism
✅ Passed - Full reproducibility confirmed
Links
Public GitHub Audit Repo: https://github.com/ProvablyFair-org/duel-audit
Raw Datasets: <datasets folder link>
Reference
Dice - Game Rules
Dice - Game Rules
Dice is a prediction game where players bet on whether a randomly generated number will fall above or below a chosen target. Its transparent mechanics and verifiable math make it a natural starting point for provably fair auditing.
Game Rules
Dice is a prediction game where players bet on whether a randomly generated number will fall above or below a target threshold they choose. The game offers complete control over risk and reward: players who accept lower win probability receive higher payouts, while those preferring safer bets receive smaller multipliers.
Risk vs Reward
The core mechanic of Dice is the inverse relationship between win probability and payout:
High risk, high reward: Setting a target of 90 with "Roll Over" gives only a 10% chance to win, but pays approximately 9.99x
Low risk, low reward: Setting a target of 50 with "Roll Over" gives a 50% chance to win, but pays approximately 1.998x
Players control the math: Unlike slots or other games with fixed odds, Dice lets players choose their exact risk profile on every bet
Roll Range
0.00 – 100.00
Uniform distribution across 10,001 possible outcomes
Target Precision
0.01
Players can set targets like 35.00, 50.05, 72.50
House Edge
0.1%
UI displays "Zero Edge." Verified house edge is 0.1%.
Theoretical RTP
99.9%
Verified across all 196 target configurations
Betting Modes
Manual, Auto
Auto mode enables rapid sequential betting
Bet ID Format
Numeric
Each bet assigned unique ID (e.g., #308953686)
Seed Formats
Every Dice bet uses three cryptographic inputs to generate the result:
Server Seed
64-char hex (32 bytes)
4f775f81301c7fe8...
Casino-provided randomness
Client Seed
16-char alphanumeric
kJbhRHVAg4lh_OY7
Player-controlled randomness
Nonce
Integer, starts at 0
0, 1, 2, ...
Ensures unique result per bet
The combination of these three inputs, using HMAC-SHA256, produces the random roll. Because the player controls the client seed and the server seed is committed before betting, neither party can manipulate the outcome.
Multiplier Calculation
Payouts in Dice are calculated mathematically based on win probability and house edge:
With Duel's 0.1% house edge:
Why Provably Fair Matters
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 Overview
High-Level Flow
To get an overview of how the process works, here is a high-level diagram alongside details
Player Bets → Initial input from the player
Seeds Combined → Combining serverSeed, clientSeed, and nonce
RNG Output → Random number generation using HMAC-SHA256 with rejection sampling
Game Logic → Generates a value (0.00-100.00) compared against the target
Payout Result → Final outcome (Win/Lose) multiplied by the multiplier
Provably Fair Model
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.
Commit-Reveal Model
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 this 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, incorporating their client seed. This phase combines the client seed with the server seed to influence game outcomes, ensuring player participation in the randomness.
Reveal Phase: Once the bet is resolved, the casino reveals the actual server seed. By disclosing this information, players can verify that the hash provided during the commit phase corresponds to the server seed used, ensuring no tampering occurred.
Verify Phase: The player can now confirm the fairness of the outcome by hashing the server seed revealed so far. If the hash matches the one provided during the commit phase, it proves the integrity of the process and ensures that outcomes were not manipulated by the casino.
Technical Glossary
Technical Glossary
Core Concepts
Provably Fair A cryptographic system that allows players to mathematically verify that game outcomes were not manipulated. Unlike traditional "trust-based" systems, provably fair games provide cryptographic proof of fairness.
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. This prevents the casino from changing outcomes based on player actions.
Determinism The property that identical inputs always produce identical outputs. In provably fair systems, using the same server seed, client seed, and nonce must always generate the same game result.
Seed System
Server Seed A random value generated by the casino, typically 64 hexadecimal characters (32 bytes). The server seed is hashed and shown to players before betting, then revealed after the bet is complete.
Client Seed A random value controlled by the player, typically 16 alphanumeric characters. Players can set or change their client seed at any time to ensure they contribute entropy that the casino cannot predict.
Nonce A sequential counter (0, 1, 2, 3...) that increments with each bet under the same seed pair. The nonce ensures each bet produces a unique result even when using the same server and client seeds.
Seed Pair The combination of a server seed and a client seed. A seed pair remains active across multiple bets, with the nonce incrementing for each round. When a player rotates seeds, a new seed pair begins with the nonce reset to 0.
Hashed Server Seed The SHA-256 hash of the server seed, shown to players before betting. After the bet, players can verify that SHA-256(revealed server seed) equals the originally shown hash, proving the casino didn't change the seed.
Cryptographic Functions
HMAC-SHA256 Hash-based Message Authentication Code using SHA-256. A cryptographic function that combines the server seed, client seed, and nonce to produce a deterministic, unpredictable hash used for random number generation.
SHA-256 Secure Hash Algorithm 256-bit. A one-way cryptographic hash function that converts any input into a unique 64-character hexadecimal output. Cannot be reversed to discover the original input.
Rejection Sampling A technique to eliminate modulo bias in random number generation. Values outside a "fair range" are discarded and the next portion of the hash is used instead, ensuring perfectly uniform distribution.
Verification Terms
Verifier A tool (usually web-based or code snippet) that independently calculates game outcomes using provided seeds and nonce. A proper verifier should produce identical results to the live game.
Parity The degree of matching between verifier results and live game results. 100% parity means every single outcome matches perfectly, which is required for provably fair certification.
Reproducibility The ability to regenerate exact game outcomes using the same inputs. Players should be able to reproduce any historical bet result using the revealed seeds and nonce.
Game Mechanics
RNG (Random Number Generator) The algorithm that produces random outcomes. In provably fair systems, the RNG must be deterministic and based only on seeds + nonce (no hidden entropy sources).
RTP (Return to Player) The percentage of wagered money returned to players over time. Calculated as (1 - House Edge) × 100%. For Duel Dice, RTP = 99.9%.
House Edge The casino's mathematical advantage, expressed as a percentage of each bet. For Duel Dice, house edge = 0.1%, meaning the casino expects to keep 0.1% of all wagers long-term.
Multiplier The payout ratio for a winning bet. Calculated as: (100 - House Edge) / Win Probability. For example, a 50% win chance with 0.1% house edge yields a 1.9980x multiplier.
Win Condition The rule that determines if a bet wins or loses. In Dice: "Roll Over" wins if result > target; "Roll Under" wins if result < target. Rolling exactly on target always loses.
Audit Terms
Fairness Violation A condition where a player or casino could predict, alter, or unfairly influence outcomes. Examples include seed prediction, nonce replay, or hidden entropy injection.
Entropy Randomness or unpredictability in a system. In provably fair games, entropy comes from both the casino (server seed) and player (client seed).
Bias Non-uniform probability distribution. An unbiased RNG gives all outcomes equal likelihood. Rejection sampling eliminates bias that would otherwise occur from modulo operations.
Edge Case Unusual or extreme scenarios that might behave differently than normal operation. Examples: concurrent betting, nonce overflow, malformed seeds, or maximum bet limits.
Data Formats
Hexadecimal (Hex)
Base-16 number system using digits 0-9 and letters A-F. Server seeds and hashes are typically shown in hex format (e.g., 4f775f81301c7fe8...).
Hash The output of a cryptographic hash function. In provably fair systems, hashes serve as commitments that cannot be reversed but can be verified.
Bet ID A unique identifier assigned to each bet (e.g., #308953686). Used to reference specific rounds during verification.
Common Abbreviations
PF
Provably Fair
RNG
Random Number Generator
RTP
Return to Player
HMAC
Hash-based Message Authentication Code
SHA
Secure Hash Algorithm
CI
Confidence Interval
N/A
Not Applicable / Not Tested
1. Seed, Nonce & Determinism
What Was Tested
The casino commits to a server seed before any bet is placed
Players can freely set or change their client seed before betting
A nonce increments automatically for every bet and is never reused
The Dice result is generated only from (server seed, client seed, nonce)
The same inputs always produce the exact same outcome
What This Means for Players
The casino cannot change outcomes after you place a bet
You contribute your own randomness via the client seed
Every bet is unique, even with the same seeds
Any Dice result can be verified independently
Outcomes are tamper-proof and reproducible, even months later
Main Visual: Diagram Visible (Use icons) Seed → RNG → Outcome Diagram
: Server Seed + Client Seed + Nonce
↓
Deterministic RNG
↓
Dice Roll
Verdict Summary
Seed & Determinism Integrity
Server seed committed before bet
✅ Pass
Casino cannot change randomness after betting
Player client seed control
✅ Pass
Player contributes entropy
Nonce sequencing
✅ Pass
Each bet uses a unique input
Deterministic output
✅ Pass
Same inputs always produce same result
Overall Verdict:
🟢 Deterministic and Provably Fair
All tested Dice outcomes are fully deterministic and can be independently reproduced using the disclosed server seed, client seed, and nonce.
🔍 How Dice seed, nonce, and determinism work
Layer 2
1.1 Server Seed Commitment
Before any bet is placed, the casino generates a secret server seed and publicly commits to it by displaying its SHA-256 hash to the player. This cryptographic commitment prevents the casino from changing the seed after seeing player actions. Upon game completion, the revealed server seed is verified by hashing it and confirming it matches the pre-committed hash, proving the outcome was predetermined.
Code Implementation:
Real Example from Live Data:
Verification:
1.2 Player Client Seed Control
Players have full control over their client seed through the Duel UI, allowing them to view, modify, or randomize it at any time before placing bets. This ensures players contribute their own entropy to the RNG process. This player-controlled input makes it mathematically impossible for the casino to predict or manipulate outcomes, as the final result depends on a value only the player knows in advance. Players can view and change their client seed at any time via the Duel UI.
Code Implementation:
Real Data Evidence: From the test data, client seeds are player-controlled and vary:
"G3blCQBWQdVfM8sx"
"13aS4FO1Iz"
"32GD7vC9fH"
"ewGBx04VbY"
"0ygEXdJyQm"
1.3 Nonce Incrementation
The nonce begins at 0 and increments sequentially by 1 for each bet under the same server/client seed pair, ensuring every bet produces a unique RNG input even with identical seeds. This prevents outcome repetition. When a new server seed is issued (after rotation), the nonce resets to 0, and the system verifies nonces are never reused within the same seed session to guarantee cryptographic uniqueness.
Code Implementation:
Real Data Verification:
1.4 Deterministic Mapping
The RNG algorithm is fully deterministic; given the same server seed, client seed, and nonce, it will always produce the exact same output, allowing any party to independently verify results at any time. This mathematical certainty is the cornerstone of provably fair gaming: the test confirms that all 100+ live game results from the dataset match precisely when recalculated using the revealed seeds.
Code Implementation:
Real Example Verified:
Verification:
🧪 Technical Evidence & Verification
Layer 3
3.0 Purpose
This section indexes the technical artifacts used to verify Dice seed handling, nonce behavior, and determinism.
All evidence is reproducible using the linked scripts and datasets. Inline content is intentionally minimal; full artifacts are available via links.
3.1 Evidence Coverage Summary
Verification Area
Coverage
Result
Server seed commit & reveal
All observed seed sessions
PASS
Client seed usage
UI + live data
PASS
Nonce incrementation
1,199 transitions
PASS
Deterministic recomputation
1,200 / 1,200 bets
PASS
Edge-case checks (seed/nonce)
Targeted tests
PASS
3.2 Code References
DiceAuditExecutionChecklistTests.ts
Seed commit verification, client seed usage, nonce sequencing, determinism checks
DiceNumbersGenerator.ts
generateDiceResult algorithm
DuelNumbersGenerator.ts
HMAC-SHA256 helper functions
3.3 Datasets Used
Dataset: duel-dice-sim-1767531771390.json (link)
Source: Live Dice game data Records: ~6,200 bets
Fields used:
serverSeed
serverSeedHashed
clientSeed
nonce
drawnNumber
3.4 Determinism Verification
Using the linked determinism test suite, all recorded Dice outcomes were recomputed using the disclosed server seed, client seed, and nonce.
The recomputed results matched the live game outcomes exactly for all verified bets (1,200 / 1,200). No partial matches, rounding deviations, or conditional discrepancies were observed.
Evidence Artifacts:
Determinism test suite: DiceAuditExecutionChecklistTests.ts (link)
Determinism result log: determinism-results.json (link)
Same inputs → same output
PASS
RNG depends only on declared inputs
PASS
3.5 Reproduction Instructions
git clone https://github.com/ProvablyFair-org/duel-audit
npm install
npm test -- --grep "Dice Audit"
Expected result: All determinism and nonce verification tests pass.
Audit reproducibility pinned to:
Git commit: <commit-hash>
Dataset hash (SHA-256): <hash>
3.6 Verified Invariants (Seed / Nonce)
The following invariants were verified across the observed dataset:
Nonce resets to 0 on server seed rotation
Nonce never decrements or skips within a seed session
Nonce values are never reused within the same seed session
Observed maximum nonce aligns with operational seed rotation policy
Evidence:
Nonce sequencing tests: DiceAuditExecutionChecklistTests.ts (link)
Seed rotation dataset slice: duel-dice-sim-1767531771390.json (link)
2. RNG & Entropy Model
What was tested
The random number generator used to produce Dice results
The sources of randomness (entropy) feeding the RNG
Whether outcomes are unbiased and evenly distributed
Whether randomness is isolated per bet and per player
What this means for players
Dice outcomes are generated fairly and cannot be skewed
No hidden randomness or server-side tricks influence results
Every number between 0.00 and 100.00 has an equal chance
Outcomes cannot be predicted or manipulated across bets
Main Visual:
Histogram of dice outcomes (0–100)
Verdict Summary
RNG & Entropy Integrity
Check
Result
What this means
RNG derived only from disclosed inputs
✅ Pass
No hidden randomness affects outcomes
Entropy purity
✅ Pass
No timestamps, server randomness, or external inputs
Output uniformity
✅ Pass
Results are evenly distributed as expected
No state leakage
✅ Pass
Previous bets do not influence future results
Overall Verdict:
🟢 Unbiased and Cryptographically Sound
All tested Dice outcomes are generated using only the disclosed server seed, client seed, and nonce. The RNG output is statistically uniform, deterministic, and free from hidden entropy or bias.
🔍 How Dice randomness & entropy work
Layer 2
2.1 RNG Function & Inputs (Expandable) Include:
Short explanation (1–2 paragraphs) describing:
RNG is HMAC-SHA256 based
Inputs are strictly (serverSeed, clientSeed, nonce)
Output is deterministic for identical inputs
One simple function reference:
generateDiceResult(serverSeed, clientSeed, nonce)
One real input → output example (JSON)
Do not include:
Full RNG class implementation
Full hashing pipeline
Test loops or assertions
From PDF pages (RNG overview section):
Keep the high-level explanation of how RNG is derived
Keep one real bet example showing seeds + nonce → result
Remove any repeated explanations of the same concept
2.2 Entropy Purity & Sources (Expandable)
Include:
Clear bullet list of allowed entropy:
Server seed (casino)
Client seed (player)
Nonce (system)
Explicit bullet list of excluded entropy:
No timestamps
No Math.random
No server-side randomness
No external APIs
One paragraph explaining why entropy purity matters for fairness
Do not include:
Code-level checks
Assertions validating absence of Math.random
Internal helper functions
From PDF pages (entropy discussion):
Keep the explanation of entropy sources
Keep any simple table or diagram listing allowed vs excluded entropy
Remove code that checks for entropy purity
2.3 Bias Elimination & Uniformity (Expandable)
Include:
High-level explanation of bias avoidance (e.g. rejection sampling)
One sentence explaining why modulo bias is dangerous
One simple diagram or visual reference showing:
RNG output → accept/reject → final range
Statement confirming observed uniform distribution
Do not include:
Probability math
MAX_FAIR / MAX_UINT derivations
Numeric constants or bitwise explanations
From PDF pages (distribution analysis):
Keep the explanation of bias prevention
Keep one histogram or distribution visual
Remove the mathematical derivation and constant definitions
2.4 RNG State Isolation (Expandable)
Include:
Explanation that RNG is stateless per bet
Statement that:
Outcomes do not depend on previous bets
RNG state does not persist across users or sessions
Simple diagram showing isolated bets
Do not include:
Internal state objects
Memory or caching logic
Test loops validating isolation
From PDF pages (state discussion):
Keep the conceptual explanation
Keep one simple illustration if present
Remove implementation-level details
🧪 Technical Evidence & Verification
Layer 3
Code references (exact scope)
RelevantStatistics.ts
RNG output normalization logic
Floating-point handling and scaling to dice range
MersenneTwisterRandomNumberGenerator.ts (if applicable)
RNG core implementation used for Dice
DiceWinCalculator.ts
Mapping from raw RNG output to game outcome
rng_distribution_test.ts
Statistical validation and distribution testing logic
Raw datasets (RNG output only)
Dataset used for randomness distribution testing
Example:
dice_distribution.csv
Fields included:
drawnNumber
normalizedValue
roundIndex
This dataset contains large-scale simulated outputs generated directly from the RNG pipeline without payout logic applied.
Full test logs (distribution & bias checks)
Logs showing:
Total sample size (e.g. 1M+ rolls)
Min / max observed values
Mean vs expected mean
Distribution variance
Confirmation that:
No clustering or skew is observed
No state leakage across rounds
Output distribution matches theoretical uniform expectation
Reproduction artifacts
Script: rng_distribution_test.ts
Instructions:
How to generate the RNG output dataset locally
How to re-run statistical checks
Expected output:
Histogram data
Summary statistics matching published results
Edge-case evidence (RNG-specific)
Proof RNG output remains within expected bounds (0–100)
Proof no hidden entropy sources are used
No timestamps
No Math.random
No external state
Proof RNG state is reset correctly between sessions
3. Live Game ↔ Verifier Parity
What Was Tested
Live Dice game outcomes versus independent verifier recomputation
Backend game logic alignment with verifier logic
Deterministic parity across real production bets
What This Means for Players
The verifier is not a “simulation” or approximation
Every bet you play can be independently recomputed
The casino cannot alter outcomes after bets are placed
Visuals
Primary Visual (Required): Parity Flow Diagram
Server Seed + Client Seed + Nonce
↓
Live Game RNG
↓
Dice Result
↓
Independent Verifier
↓
Exact Match ✅
Secondary Visual : Parity Summary Table
Metric
Result
Bet Sizes
$0.1 - $10
Live Bets Tested
6,200
Matches
6,200
Mismatches
0
Parity Rate
✅ 100%
Verdict Summary
Live ↔ Verifier Parity Integrity
Check
Result
What this means
Live result recomputation
✅ Pass
Verifier recalculates exact outcomes
RNG logic alignment
✅ Pass
Same RNG logic used live and in verifier
Deterministic parity
✅ Pass
No divergence across systems
Production data tested
✅ Pass
Real bets, not mock data
Overall Verdict:
🟢 Live Game and Verifier Fully Aligned
All tested live Dice outcomes matched the independent verifier exactly. This confirms that the verifier reflects real gameplay behavior and that outcomes cannot be altered post-bet.
🔍 How Verifier Parity Works
Layer 2
3.1 What Verifier Parity Means (Expandable)
Include:
Short explanation (1–2 paragraphs) describing:
What “parity” means in a provably fair context
That the live game and verifier use the same deterministic logic
That any mismatch would indicate post-bet manipulation or logic divergence
One clear statement:
“Given the same server seed, client seed, and nonce, both systems must always return the same result.”
Do not include:
Code
Test loops
Assertions
RNG math (already covered in Section 2)
From PDF (parity explanation pages):
Keep the conceptual explanation of why parity matters
Remove repeated references to determinism already explained in Section 1
3.2 How Live Outcomes Are Verified (Expandable)
Include:
Short explanation (1–2 paragraphs) describing:
How live bets are captured from the production environment
How each bet is independently recomputed using the verifier
That results are compared one-to-one
Simple step flow (text or diagram):
Capture live bet data
Recompute outcome via verifier
Compare live result vs verifier result
One simple confirmation sentence:
“If even one result differs, parity fails.”
Do not include:
Dataset dumps
Script names
File paths
Loops iterating over bets
From PDF (live verification section):
Keep the high-level description of the comparison process
Remove raw JSON blocks and loop explanations
3.3 Parity Results Summary (Expandable)
Include:
Short summary paragraph stating:
Number of live bets tested (e.g. hundreds or thousands)
That all results matched exactly
That no discrepancies were observed
One simple result line:
“Matched: 1000 / 1000 live bets”
Optional small table:
Metric
Result
Live bets tested
1000
Verifier mismatches
0
Parity rate
100%
Do not include:
Full datasets
Test logs
Script output
From PDF (results section):
Keep the final counts and conclusions
Remove verbose output logs
3.4 Why This Matters for Players (Expandable)
Include:
Short explanation (1 paragraph) describing:
That the verifier is not a simulation or estimate
That it proves outcomes cannot be changed after the bet
That players can independently validate fairness
One clear takeaway sentence:
“This ensures the game you see is the game being verified.”
Do not include:
Repetition of exploit testing
RNG internals
Certification language
🧪 Technical Evidence & Verification
Layer 3
Code References (Exact Scope)
compare_live_vs_verifier.ts
Logic that recomputes outcomes from live bet data using the verifier and compares results one-to-one.
DiceAuditExecutionChecklistTests.ts
Live vs verifier parity assertions ensuring:
Same inputs produce identical outputs
No post-processing or rounding divergence
DiceWinCalculator.ts
Confirms payout and win/loss logic used by verifier matches live game logic.
generator.generateDiceResult(…)
Core function used identically by:
Live game backend
Verifier recomputation
Purpose:
To ensure there is no logic drift between production gameplay and verification tooling.
Raw Datasets (Live Parity Only)
Dataset used for live ↔ verifier comparison:
live_rounds.json
Fields included:
serverSeed
clientSeed
nonce
drawnNumber
bet parameters (target, over/under, etc.)
liveResult
verifierResult
This dataset contains real bets captured from the live game, not simulations.
Full Test Logs (Parity Validation)
Logs demonstrating:
Total live bets tested (e.g. 500–1000+)
Recomputed verifier results for each bet
Zero mismatches observed
Key confirmations:
liveResult === verifierResult for every bet
No rounding differences
No conditional logic divergence
No missing or reordered nonce usage
Example summary output:
Matched: 1000 / 1000
Mismatches: 0
Reproduction Artifacts
Script: compare_live_vs_verifier.ts
Instructions:
How to load the live bet dataset
How to recompute outcomes locally
How to verify parity programmatically
Expected output:
Exact 1:1 match between live results and verifier results
Fail-fast behavior if any mismatch occurs
Edge-Case Evidence (Parity-Specific)
Evidence confirming:
Verifier logic does not diverge under different bet parameters
No dependency on session state or prior bets
No conditional payout adjustments post-RNG
No environment-specific behavior between live and verifier
Explicitly verified:
Same code paths
Same math
Same rounding
Same final result
4. Dice Game Logic & RTP Validation
What was tested
How Dice outcomes are mapped to wins and losses
Whether payouts are calculated correctly for all bet types
Whether the advertised RTP matches the actual game behavior
Whether results remain consistent across different targets and bet directions
What this means for players
Wins and losses are calculated exactly as the game rules describe
Payouts cannot be altered after the roll is generated
The house edge is consistent and transparent across all bets
Over time, the game returns the percentage it claims to return
Advertised vs Observed RTP
Metric
Value
Advertised RTP
99.00%
Observed RTP (Simulation)
✅98.99%
Simulation Size
100,000,000 rounds
Deviation
Within expected variance +-0.05%
The observed RTP converges tightly toward the advertised RTP as the number of rounds increases, which is expected behavior for a fair Dice game.
Main Visual
RTP Convergence Chart
X-axis: Number of simulated bets
Y-axis: RTP
Line showing convergence toward advertised RTP (99.91%)
Shaded variance band
This visual shows that as more bets are placed, the observed RTP converges to the advertised value.
Verdict Summary
Game Logic & RTP Integrity
Check
Result
What this means
Dice roll mapping
✅ Pass
Rolls are derived correctly from RNG output
Win/loss logic
✅ Pass
Outcomes are evaluated correctly
Payout calculation
✅ Pass
Multipliers and payouts match rules
RTP behavior
✅ Pass
RTP converges to advertised value
Overall Verdict:
🟢 RTP behaves as advertised
The Dice game’s payout logic is correct, deterministic, and statistically consistent with the advertised RTP. No abnormal bias or payout manipulation was observed.
🔍 How Dice payouts and RTP are calculated
Layer 2
4.1 Payout Rules & Win Conditions (Expandable)
Include:
Short explanation of how Dice payouts work:
Winning payout = bet amount × multiplier
Losing bets return zero
Clear statement that:
Multipliers are fixed and predefined
No conditional logic changes payouts after the roll
One simple example:
Bet amount
Roll result
Target
Win or loss
Final payout
Do not include:
Full class definitions
Input validation branches
Error handling logic
Multiple repeated examples
From PDF pages 37–39:
Keep the plain-English explanation of payout mechanics
Keep one simple payout example
Keep the visual flow diagram showing:
Bet → Validate → Compare → Apply multiplier → Payout
Remove full DiceWinCalculator source dump from this layer
4.2 Multiplier & House Edge Model (Expandable)
Include:
One paragraph explaining:
All multipliers are derived from a fixed house edge
House edge is consistent across all targets
Simple explanation of:
RTP = 100% − house edge
One worked example (single target):
Target
Win chance
Multiplier
Resulting RTP
Do not include:
Full multiplier tables
Repeated examples for many targets
Code loops or assertions
From PDF pages 40–42:
Keep the explanation of:
Multiplier = (100 − house edge) ÷ win chance
Keep one example calculation
Remove the full ABOVE_NUMBER / BELOW_NUMBER tables from this layer
4.3 Simulated RTP Behaviour (Expandable)
Include:
Plain explanation of what simulation proves:
Game behaves correctly over many bets
RTP converges to advertised value
High-level summary stats:
Number of bets simulated
Targets covered
Final observed RTP
One sentence explaining statistical tolerance
Do not include:
Monte Carlo implementation details
Nested loops
Tracker objects
Timing logs
From PDF pages 45–49:
Keep the summary bullet points:
~980,000 bets
98 targets
RTP converges to 99.91%
Keep the RTP convergence visual
Remove all simulator source code from this layer
🧪 Technical Evidence & Verification
Layer 3
Code References (Exact Scope)
DiceWinCalculator.ts
Core payout logic used by the live game and verifier
Validates:
Bet amount input constraints
Drawn number bounds (0–100)
Correct multiplier selection (ABOVE_NUMBER / BELOW_NUMBER)
Final payout calculation
Source:
src/dice/DiceWinCalculator.ts (lines 5–28)
Purpose:
Ensure win/loss logic and payout calculation exactly match documented game rules
DiceGameProfiles.ts
Multiplier tables for all Dice targets and bet directions
Confirms:
Multipliers embed a consistent 0.09% house edge
RTP remains constant across all target values
Source:
src/dice/DiceGameProfiles.ts (lines 103–203)
Purpose:
Verify advertised RTP is mathematically encoded in the game profiles
DiceAuditExecutionChecklistTests.ts
Unit tests validating:
Payout rules correctness
Advertised RTP matches theoretical RTP
Advertised RTP matches simulated RTP
Source:
tests/dice/DiceAuditExecutionChecklistTests.ts (lines 89–145)
Purpose:
Assert payout logic and RTP behavior across all bet configurations
DiceGameSimulator.ts
Monte Carlo simulation engine used for RTP validation
Uses:
Same RNG and payout logic as live game
Source:
src/dice/DiceGameSimulator.ts (lines 12–46)
Purpose:
Empirically verify RTP convergence using large-scale simulations
Raw Datasets (RTP & Payout Only)
Simulation Dataset
Dataset generated via Monte Carlo simulation
Example:
duel-dice-sim-1767531771390.json
Contains:
serverSeed
clientSeed
nonce
drawnNumber
betAmount
winAmount
Scope:
Nearly 1,000,000 simulated bets
10,000 bets per target (targets 2–99)
Purpose:
Validate RTP convergence and payout correctness empirically
Full Test Logs (RTP & Payout Validation)
Logs demonstrate:
Targets tested: 2–99 (98 targets)
Samples per target: 10,000 bets
Total simulated bets: ~980,000
Execution time: ~113 seconds
Observed RTP: 99.91%
House edge: 0.09%
Key confirmations:
Every multiplier falls within the expected RTP acceptance range
Aggregate RTP remains within ±1% statistical margin
No payout anomalies or calculation errors observed
No conditional logic altering payouts post-RNG
Example test assertions:
"Payout rules correctness" ✅
"Advertised RTP matches theoretical RTP" ✅
"Advertised RTP matches simulated RTP" ✅
Reproduction Artifacts
Simulation Script
DiceGameSimulator.simulate(samplesPerTarget)
Reproduction Steps
Load seed dataset
Run Monte Carlo simulation
Aggregate win/loss results per target
Compare observed RTP to theoretical RT
Expected Output
RTP convergence toward 99.91%
Per-target RTP within tolerance
Aggregate RTP within ±1% margin
Edge-Case Evidence (Game Logic & RTP)
Explicitly verified:
Payout calculation uses no hidden adjustments
Max-win enforcement occurs after outcome determination
Floating-point rounding is consistent and deterministic
Invalid inputs are rejected before payout calculation
No dependency on previous bets or session state
5. Exploit & Edge-Case Testing (Dice)
TBA
6. Player Verification Guide (Dice)
What Was Tested
Whether players can independently verify Dice outcomes without trusting the casino
Whether all inputs required for verification are fully disclosed
Whether the public verifier reflects real game behavior
Whether verification can be performed both in-browser and offline
What This Means for Players
You do not need to “trust” the casino or this audit
Every Dice bet can be independently checked by anyone
Verification works using the same math and inputs the game uses
Results cannot be altered after a bet is placed
Visuals
Primary Visual: Verification Flow Diagram
Server Seed (revealed)
Client Seed (player)
Nonce
↓
Deterministic RNG
↓
Dice Result
↓
Player Verification
↓
Exact Match ✅
Secondary Visual: Independent Verification Calculator (We need to build this)
Verification Method
Who Runs It
Result
Duel built-in verifier
Player
✅ Match
Manual verification (code)
Player
✅ Match
Independent recomputation
ProvablyFair.org
✅ Match
Overall Verdict:
🟢 Fully Verifiable by Players
All tested Dice outcomes can be independently verified using disclosed seeds and nonce values. Verification works both through Duel’s interface and via manual offline calculation, confirming that outcomes are transparent, reproducible, and not reliant on trust in the casino.
🔍 How to Verify Your Dice Bets Yourself
Layer 2
6.1 Verifying a Bet Using Duel’s Built-In Verifier (Expandable)
Include:
Short explanation (1–2 paragraphs) explaining:
Every Dice bet can be independently verified after it completes
The verifier recomputes the result using the same inputs used by the game
If the recomputed result matches the displayed result, the bet was provably fair
Step-by-step list:
Open bet details
Click “Verify” tab
Review seeds and nonce
Compare calculated result to displayed result
UI screenshots showing:
Bet details modal
Verify tab
Seed and nonce fields
One short explanation of what each field means:
Server seed (revealed)
Server seed hash (commit)
Client seed
Nonce
Do not include:
Any cryptographic code
Any hashing logic
Any JavaScript snippets
Any loops or internal tests
From PDF pages ~50–54:
Keep:
Step-by-step instructions
Screenshots of Duel UI
Explanation of what each field represents
Remove:
Repeated explanations
Anything that looks like developer documentation
6.2 Manual Verification (Advanced) (Expandable)
This is for power users, streamers, and skeptics. Include:
One short paragraph explaining:
Why manual verification matters
Why you shouldn’t blindly trust any casino-provided tool
Bullet list of benefits:
Verify results offline
Eliminate risk of a tampered verifier
Cross-check using your own environment
One minimal code example (collapsed by default):
JavaScript example showing how to recompute a Dice roll
One real input → output example:
serverSeed
clientSeed
nonce
verified result
Do not include:
Full RNG pipeline
Rejection sampling internals
MAX_UINT / MAX_FAIR constants
Multiple language examples
From PDF pages ~55–57:
Keep:
One JavaScript verification example
One real example result (62.91 etc.)
Remove:
Long explanations of hashing steps
Multiple screenshots of the same flow
6.3 What Successful Verification Proves (Expandable)
Include:
Short bullet list:
The casino could not change the result after the bet
The verifier reflects real gameplay logic
The bet outcome was fixed before it was revealed
One sentence reinforcing:
If your calculated result matches the displayed result, the game was provably fair
Do not include:
Any new technical material
Any code
🧪 Technical Evidence & Verification
Layer 3
Code References (Exact Scope)
DiceNumbersGenerator.ts
Core Dice RNG and result generation logic
DiceAuditExecutionChecklistTests.ts
Determinism and verifier parity assertions
Client-side verifier implementation
Same logic used by Duel’s production verifier
Same logic used in manual verification examples
Raw Datasets (Verification-Specific)
Dataset used for verification parity examples:
Live bet examples used in manual verification
Fields included:
serverSeed
clientSeed
nonce
drawnNumber
Source:
Extracted from live production gameplay
Reproduction Artifacts
Script:
verifyDiceRoll.js
Instructions:
How to run verification locally
Required inputs
Expected output
Expected result:
Calculated result exactly matches displayed Dice roll
7. Reproducibility & Artifacts
GitHub Repository
Repository Structure
Commands to Reproduce
Prerequisites
Node.js 16+
npm 8+
Git
Last updated