Dice Game Audit
Provably Fair audit of the Duel Dice game
(add certification badge)
Audit Dashboard
Casino: Duel
Game: Dice
Commit Hash:
fa913ab94883d06950d3c63bbb7007f927648131Audit Period:
<AUDIT_DATE>RTP (Return to Player):
99.9%House Edge:
0.1%Live Bets Tested:
6,200Simulated Bets:
~980,000Parity Rate: 100%
Repository: github.com/ProvablyFair-org/duel-audit
Commit Audited:
fa913abAudit Version: 1.0
Public Verifier: duel.com/dice
Public Certification:
<PUBLIC_CERTIFICATION_LINK>
Casino
Game
Commit Hash
fa913ab94883d06950d3c63bbb7007f927648131
Audit Period
<AUDIT_DATE>
RTP (Return to Player)
99.9%
House Edge
0.1%
Live Bets Tested
6,200
Simulated Bets
~980,000
Parity Rate
100%
Repository
Commit Audited
Public Verifier
Overview
This audit evaluates the Dice game operated by Duel Casino under the ProvablyFair.org Audit Framework v1.0. Dice is a prediction game where you bet on whether a randomly generated number (0.00 to 100.00) lands above or below a target you choose. You control your risk and reward on every bet.
The goal of this audit is to determine whether the game's outcomes are cryptographically reproducible, statistically fair, and resistant to manipulation by either you or the casino.
What was audited
This audit verified that:
✅ The RNG algorithm is deterministic and verifiable
✅ The casino commits to a server seed before you bet
✅ You can set your own client seed
✅ Nonces increment correctly and are never reused
✅ Payout logic matches the advertised multipliers
✅ Theoretical RTP is
<RTP_VALUE>✅ Outcomes are determined by a provably fair algorithm
✅ You can independently verify every bet
✅ The commit-reveal cryptographic system works correctly
What the audit covers
Commit-Reveal System
Server seed hashing, timing, and reveal mechanics
Seed Handling
Client seed control and nonce lifecycle
RNG Analysis
Algorithm verification and bias testing
Payout Logic
Multiplier accuracy and win condition verification
Live Parity
Verifier vs live game result matching
RTP Validation
Theoretical and simulated RTP analysis
Audit verdict
Overall Status
✅ Pass
RTP Verified
✅ 99.9% (±0.1% House Edge)
Section 4
Live ↔ Verifier Parity
✅ 100% across all test rounds
Section 3
Commit-Reveal System
✅ SHA-256 verified
Section 1
Seed Handling
✅ Player control verified
Section 1
RNG Analysis
✅ Unbiased via rejection sampling
Section 2
Payout Logic
✅ All payouts verified correct
Section 4
Known Exploits Tested
✅ 7/7 testable exploits passed
Section 5
Determinism
✅ Full reproducibility confirmed
Section 1
Public links
GitHub Repository: github.com/ProvablyFair-org/duel-audit
Commit Audited:
fa913abPublic Verifier: duel.com/dice (Verify Now feature)
Player Verification Guide
Reproducibility instructions
To reproduce this audit, complete the following commands:
Clone, install, and run commands
1. Clone and setup
2. Run all tests (all games)
3. Run Dice-specific tests only
Game Rules
Dice is a prediction game where you bet on whether a randomly generated number (0.00 to 100.00) will fall above or below a target you choose. The game offers complete control over risk and reward. You accept lower win probability in exchange for higher payouts, or safer bets with smaller multipliers.
Risk vs reward
The core mechanic is the inverse relationship between win probability and payout:
High risk, high reward. Setting a target of 90 with "Roll Over" gives 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.
You control the math. Unlike slots or other games with fixed odds, Dice lets you choose your exact risk profile on every bet.
Game parameters
Roll Range
0.00 to 100.00
Uniform distribution across 10,001 possible outcomes
Target Precision
0.01
You can set targets like 35.00, 50.05, 72.50
House Edge
0.1%
UI may display "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 gets a unique ID (for example, #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 you control the client seed and the server seed is committed before betting, neither party can manipulate the outcome.
Multiplier calculation
Payouts are calculated mathematically based on win probability and house edge. With Duel's 0.1% house edge:
Why Provably Fair Matters
Traditional online casinos require you to trust that games are fair. Provably fair systems remove this trust requirement by letting you mathematically verify that outcomes were not manipulated.
In a Provably Fair system:
The casino commits to a result before you place your bet.
You contribute randomness that the casino cannot predict.
Anyone can verify the outcome after the fact.
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 Duel and similar games.
High-level flow
The process works as follows:
Player Bets. Initial input from you.
Seeds Combined. The system combines server seed, client seed, and nonce.
RNG Output. Random number generation using HMAC-SHA256 with rejection sampling.
Game Logic. Generates a value (0.00 to 100.00) compared against the target.
Payout Result. Final outcome (Win or Lose) multiplied by the multiplier.
(add high-level flow diagram image)
Commit-reveal model
The commit-reveal model ensures fairness and transparency. It has four phases:
Commit
Before any bets are placed, the casino generates a random server seed. Only the SHA-256 hash of this seed is sent to you. You cannot know the seed initially, but you can verify it later.
Bet
You place your bet, incorporating your client seed. This phase combines the client seed with the server seed to influence game outcomes, ensuring you participate in the randomness.
Reveal
Once the bet is resolved, the casino reveals the actual server seed. You can verify that the hash provided during the commit phase corresponds to the server seed used, ensuring no tampering occurred.
Verify
You confirm fairness by hashing the revealed server seed. If the hash matches the one provided during the commit phase, it proves the integrity of the process and that outcomes were not manipulated by the casino.
Technical Glossary
Core concepts
Provably Fair
A cryptographic system that lets you 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 you bet, then reveals the actual value after the bet. This prevents the casino from changing outcomes based on your 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 you before betting, then revealed after the bet is complete.
Client Seed
A random value you control, typically 16 alphanumeric characters. You can set or change your client seed at any time to ensure you 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 you rotate 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 you before betting. After the bet, you can verify that SHA-256(revealed server seed) equals the originally shown hash, proving the casino did not 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. You 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 and nonce, with 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, and "Roll Under" wins if result < target. Rolling exactly on target always loses.
Audit terms
Exploit
A method to gain unfair advantage by manipulating or predicting outcomes. Common exploits include seed prediction, nonce replay, timing attacks, 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 (for example, 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 (for example, #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. Seeed, Nonce & Determinism
Every Dice roll on Duel is generated from three inputs: a server seed, a client seed, and a nonce. The casino commits to its server seed before you bet, you control your own client seed, and the nonce increments automatically with each bet. Together, these inputs guarantee that outcomes are both random and independently verifiable.
This section tests whether Duel's seed handling meets provably fair standards and whether the system is fully deterministic and tamper-proof.
What was tested
The casino commits to a server seed before any bet is placed
You can freely set or change your client seed before betting
A nonce increments automatically for every bet and is never reused
The Dice result is generated only from the server seed, client seed, and nonce
The same inputs always produce the exact same outcome
Verdict
Server seed committed before bet
✅ Pass
The casino cannot change outcomes after you bet
Player client seed control
✅ Pass
You contribute your own randomness to every outcome
Nonce sequencing
✅ Pass
Every bet is unique, even when you keep the same seeds
Deterministic output
✅ Pass
Any result can be independently verified and reproduced
Deterministic and Provably Fair
All tested Dice outcomes are fully deterministic. You can independently reproduce any result using the disclosed server seed, client seed, and nonce.
How Dice seed, nonce, and determinism work
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. This cryptographic commitment prevents the casino from changing the seed after it sees your actions. When the seed session ends, the actual server seed is revealed. You can then hash it and confirm it matches the pre-committed hash, proving the outcome was predetermined.
Code implementation:
Live data example:
Verification:
1.2 Player client seed control
You have full control over your client seed through the Duel interface. You can view, modify, or randomize it at any time before placing a bet. This ensures you contribute your own entropy to the RNG process.
Because the final result depends on a value only you know in advance, the casino cannot predict or manipulate outcomes.
Code implementation:
Client seeds observed in live data:
G3blCQBWQdVfM8sx13aS4FO1Iz32GD7vC9fHewGBx04VbY0ygEXdJyQm
Each client seed is unique and player-controlled.
(Add Duel UI screenshot showing client seed control)
1.3 Nonce incrementation
The nonce starts at 0 and increments by 1 for each bet within the same seed session. This ensures every bet produces a unique RNG input, even when the server and client seeds remain the same. When the casino issues a new server seed (after rotation), the nonce resets to 0.
The audit verified that nonces are never reused, never skip, and never decrement within the same seed session.
Code implementation:
Nonce sequence from live data:
1.4 Deterministic mapping
Given the same server seed, client seed, and nonce, the RNG always produces the exact same output. This determinism is the foundation of provably fair gaming: anyone can independently verify a result at any time using the disclosed inputs.
The audit confirmed that all <LIVE_BETS_COUNT> live game results in the dataset matched precisely when recalculated using the revealed seeds.
Code implementation:
Verified live example:
Independent verification:
Technical evidence and verification
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.
Generated: 2026-02-06
Audit status: ✅ All tests passed (13/13)
1. Evidence Coverage
Nonce reset on seed rotation
✅ Verified
Dataset evidence (see dataset below)
Nonce never decrements or skips
✅ Verified
Dataset evidence (see dataset below)
Full dataset determinism
✅ Verified
<LIVE_BETS_COUNT>/<LIVE_BETS_COUNT> bets matched
2. Code references
2.1 Test suite (Audit Execution Checklist)
Primary test file: tests/dice/DiceAuditExecutionChecklistTests.ts
Server seed commit verification
24-29
Verifies SHA-256(serverSeed) == serverSeedHashed
Client seed usage verification
32-34
Confirms you can manually set the client seed
Nonce increment logic
36-45
Validates nonce starts at 0, increments by 1, never reused
Deterministic mapping assertion
47-52
Recomputes all results and asserts a match with live data
2.2 Core algorithm implementation
Dice result generator: src/dice/DiceNumbersGenerator.ts
Main algorithm
11-32
generateDiceResult(serverSeed, clientSeed, nonce) implementation
Unbiased mapping constants
5-9
MAX_UINT32, RANGE, MAX_FAIR definitions
Class definition
3-33
Complete DiceNumbersGenerator class
3. Datasets
Primary dataset: duel-dice-sim-1767531771390.json
Source
Live Dice game data from duel.com/dice
Schema
duel-dice-sim-min-reveal-v2
Created
2026-01-04T12:54:09.990Z
File size
27,600 lines (~828.8 KB)
Total records
<LIVE_BETS_COUNT> bets across <SEED_SESSIONS> seed sessions
4. Reproduction instructions
Clone the repository, install dependencies, and run the seed/nonce/determinism tests:
Expected output:
5. Reproducibility pinning
Git commit
fa913ab94883d06950d3c63bbb7007f927648131
Dataset hash (SHA-256)
ba3ae70517c7f77e07eaced46900a5f94ebc02bf11c41502fac894f142efb799
npm version
11.3.0 (minimum: 8.x)
Node version
v22.11.0 (minimum: v16.x)
2. RNG & Entropy Model
Duel Dice uses HMAC-SHA256 as its random number generator. The algorithm takes three inputs (server seed, client seed, nonce) and produces a number between 0.00 and 100.00. No other entropy sources are used. The implementation includes rejection sampling to guarantee that every possible outcome has the same probability.
This section tests whether the RNG produces unbiased results and whether each bet is isolated from every other bet.
What was tested
The random number generator used to produce Dice results
The sources of randomness (entropy) feeding into the RNG
Whether outcomes are unbiased and evenly distributed across the full range
Whether randomness is isolated per bet and per player
(Add histogram of outcome distribution image)
Verdict
RNG derived only from disclosed inputs
✅ Pass
No hidden randomness affects your outcomes
Entropy purity
✅ Pass
No timestamps, server state, or external inputs are used
Output uniformity
✅ Pass
Every number between 0.00 and 100.00 has an equal chance
No state leakage
✅ Pass
Previous bets do not influence future results
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 and entropy works
This section explains how the system generates randomness, which entropy sources it uses, and how the RNG ensures unbiased and isolated outcomes for every bet.
2.1 RNG function implementation
The Dice RNG uses HMAC-SHA256 with deterministic inputs and applies rejection sampling against a calculated fair range (MAX_FAIR = 4,294,960,534) to eliminate modulo bias. This produces unbiased outcomes from 0.00 to 100.00.
Unit test: "RNG depends only on (serverSeed, clientSeed, nonce)" ✅
Code implementation:
HMAC-SHA256 base implementation:
2.2 Entropy sources
The system uses three cleanly separated entropy sources with no external contamination. All randomness derives exclusively from the deterministic HMAC-SHA256 function combining these inputs.
Unit test: "No mixed entropy sources" ✅
Server seed
Casino
Base randomness
Client seed
Player
Player-contributed entropy
Nonce
System
Uniqueness per bet
Confirmed absent from the RNG computation:
No timestamps
No
Math.random()No external API calls
No server-side state
Only:
HMAC-SHA256(serverSeed, clientSeed:nonce)
2.3 Bias elimination (rejection sampling)
Rejection sampling eliminates modulo bias by discarding any raw 32-bit value that falls at or above MAX_FAIR (4,294,960,534). The remaining values map uniformly to the 0-10,000 range. The rejection rate is only 0.000157%, which means bias is eliminated with negligible computational cost.
Unit test: "Mapping from RNG to game ranges is unbiased" ✅
Mathematical explanation:
Why this matters:
Probability:
Rejection rate: 6,761 / 4,294,967,295 = 0.000157%
Each outcome (0.00 to 100.00) has exactly equal probability
Rejection sampling loop from the codebase:
2.4 RNG state isolation
The generateDiceResult() function is completely stateless. No class-level variables affect outcomes. Each bet's result depends solely on its unique (serverSeed, clientSeed, nonce) input tuple. Different players receive different server seeds, and seed rotation ensures no state leaks between rounds.
Unit test: "RNG state does not leak across rounds or users" ✅
Code implementation:
Technical evidence and verification
This section indexes the technical artifacts used to verify the Dice RNG implementation, entropy sources, bias elimination, and isolation properties. All evidence is reproducible using the linked scripts and datasets.
Generated: 2026-02-06
Audit status: ✅ All RNG tests passed (4/4)
1. Evidence coverage
RNG depends only on (serverSeed, clientSeed, nonce)
✅ Verified
2. Code references
2.1 Test suite (RNG & Entropy Model)
Primary test file: tests/dice/DiceAuditExecutionChecklistTests.ts
Test block: Lines 55-80, "Randomness & Entropy Model"
RNG depends only on disclosed inputs
68-70
Verifies deterministic function with no external entropy
No mixed entropy sources
71-73
Confirms no timestamps, Math.random(), or external APIs
RNG to game ranges is unbiased
74-76
Validates rejection sampling eliminates modulo bias
RNG state does not leak
77-79
Ensures stateless operation with no cross-contamination
Test setup: Lines 56-66 contain a pre-verification determinism check.
2.2 Core RNG implementation
RNG generator: src/dice/DiceNumbersGenerator.ts
Full RNG class
3-33
Complete DiceNumbersGenerator implementation
Bias elimination constants
5-9
MAX_UINT32, RANGE, MAX_FAIR calculations
Main RNG function
11-32
generateDiceResult(serverSeed, clientSeed, nonce)
Fair range check
22
if (value < this.MAX_FAIR) condition
3. Datasets
Primary dataset: duel-dice-sim-1767531771390.json
Source
Live Dice game data from duel.com/dice
Schema
duel-dice-sim-min-reveal-v2
Created
2026-01-04T12:54:09.990Z
File size
27,600 lines (~828.8 KB)
Fields used for RNG verification:
serverSeed
Server-provided entropy (64 hex characters)
clientSeed
Player-provided entropy (alphanumeric string)
nonce
Uniqueness counter (integer)
drawnNumber
Generated outcome (0.00-100.00)
result
Raw result value before division (0-10000)
Entropy analysis confirmed:
No
timestampfield used in RNG computationNo
Math.random()calls in codebaseNo external API calls during result generation
Pure function: output depends only on (serverSeed, clientSeed, nonce)
4. Reproduction instructions
Expected output:
5. Reproducibility pinning
Git commit
fa913ab94883d06950d3c63bbb7007f927648131
Dataset hash (SHA-256)
ba3ae70517c7f77e07eaced46900a5f94ebc02bf11c41502fac894f142efb799
npm version
11.3.0 (minimum: 8.x)
Node version
v22.11.0 (minimum: v16.x)
3. Live Game ↔ Verifier Parity
Verifier parity is the most critical requirement of a provably fair system. If you can take the revealed seeds after gameplay, input them into an independent verifier, and get the exact same outcome you experienced during the live game, then the casino could not have altered the result.
This section tests whether Duel's live Dice outcomes match the independent verifier's recomputation across a full dataset of real production bets. A single mismatch would invalidate the fairness guarantee.
What was tested
Live Dice game outcomes versus independent verifier recomputation
Whether the backend game logic aligns with the verifier logic
Deterministic parity across real production bets (not mock data)
Parity metrics
Bet sizes
$0.10 - $10.00
Live bets tested
<LIVE_BETS_COUNT>
Matches
<LIVE_BETS_COUNT>
Mismatches
0
Parity rate
✅ 100%
(Add parity flow diagram image)
Verdict
Live result recomputation
✅ Pass
The verifier recalculates your exact outcomes
RNG logic alignment
✅ Pass
The same RNG logic runs in the live game and the verifier
Deterministic parity
✅ Pass
No divergence between systems
Production data tested
✅ Pass
Real bets from live gameplay, not simulated data
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 after you bet.
How verifier parity works
This section explains what verifier parity means, how it is tested, and why 100% parity is the only acceptable result.
3.1 Why parity matters
If the verifier produces results that differ from the live game, you can't trust the verification and the entire provably fair system becomes meaningless. Even a single discrepancy would indicate a bug in the verification logic, manipulation in the live game, or an inconsistent RNG implementation between systems.
You must be able to take the revealed seeds after gameplay, input them into the independent verifier, and receive the exact same outcomes you experienced during live play. This mathematical equivalence proves that the casino committed to outcomes before bets were placed and could not alter results afterward.
(add partity comparison diagram image)
3.2 How parity is verified
The audit verifier recalculates every game result by running the same generateDiceResult() function with the revealed seeds and compares each output against the actual live game outcomes stored in the test dataset. Every bet must produce an exact match.
Unit test: "Generator produces the same numbers as Duel bet Dice verifier" ✅
Code implementation:
Test data source:
3.3 Test results
<LIVE_BETS_COUNT> real bets (mixed $0.10 and $10.00 wagers) from live Duel gameplay achieved 100% parity. Every outcome recalculated by the independent verifier matched the original live game result exactly.
Created
2026-01-04T12:54:09.990Z
Source
Total bets
<LIVE_BETS_COUNT>
Matches
<LIVE_BETS_COUNT> / <LIVE_BETS_COUNT>
Mismatches
0
Parity rate
100% ✅
Sample verification:
Technical evidence and verification
This section indexes the technical artifacts used to verify that the independent Dice verifier produces identical outcomes to the live game. All evidence is reproducible using the linked scripts and datasets.
Generated: 2026-02-11
Audit status: ✅ All tests passed (1/1 verifier parity test + <LIVE_BETS_COUNT> live game verifications)
1. Evidence coverage
Unit test: basic verifier parity
✅ Pass
Single isolated test case confirming generator output matches known Duel result
Live game parity: full dataset
✅ Pass
<LIVE_BETS_COUNT> real production bets verified against independent verifier
Determinism verification
✅ Pass
Same (serverSeed, clientSeed, nonce) always produces the same outcome
Code implementation review
✅ Pass
RNG algorithm matches documented specification
2. Code references
2.1 Test suite (Verifier Parity)
Primary test file: tests/dice/DiceAuditExecutionChecklistTests.ts
Deterministic parity verification
47-52
Recomputes all live results and asserts exact match with verifier
Unit test file: tests/dice/DuelDiceNumbersGeneratorTests.ts
Basic verifier parity
11-19
Single test case confirming generator matches Duel verifier output
2.2 Core algorithm implementation
Dice result generator: src/dice/DiceNumbersGenerator.ts
Main algorithm
11-32
generateDiceResult(serverSeed, clientSeed, nonce) implementation
Unbiased mapping constants
5-9
MAX_UINT32, RANGE, MAX_FAIR definitions
3. Datasets
Primary dataset: duel-dice-sim-1767531771390.json
Source
Live Dice game data from duel.com/dice
Schema
duel-dice-sim-min-reveal-v2
Created
2026-01-04T12:54:09.990Z
File size
27,600 lines (~828.8 KB)
Total records
<LIVE_BETS_COUNT> bets across <SEED_SESSIONS> seed sessions
Fields used for verifier parity:
serverSeed
Server-provided entropy (64 hex characters)
clientSeed
Player-provided entropy (alphanumeric string)
nonce
Uniqueness counter (integer)
drawnNumber
Live game outcome (0.00-100.00)
result
Raw result value from live game (0-10000)
Parity test method:
Extract (serverSeed, clientSeed, nonce) from live bet data
Recompute outcome using independent verifier:
generator.generateDiceResult()Compare verifier output with
drawnNumberfrom the live gameAssert exact match (100% parity required)
4. Reproduction instructions
Expected output:
5. Reproducibility pinning
Git commit
fa913ab94883d06950d3c63bbb7007f927648131
Dataset hash (SHA-256)
ba3ae70517c7f77e07eaced46900a5f94ebc02bf11c41502fac894f142efb799
npm version
11.3.0 (minimum: 8.x)
Node version
v22.11.0 (minimum: v16.x)
4. Game Logic & RTP Validation
This section verifies that the Dice payout mechanics work exactly as documented. The audit checks whether the system calculates every win and loss correctly, whether the multiplier tables match published odds, and whether the Return to Player (RTP) percentage holds up across both mathematical proof and large-scale simulation.
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 actual game behavior
Whether results remain consistent across different targets and bet directions
Advertised vs observed RTP
Advertised RTP
<RTP_VALUE>
Observed RTP (simulation)
<RTP_VALUE>
Simulation size
<SIM_ROUNDS> rounds
Deviation
Within expected variance ±0.05%
Verdict
Dice roll mapping
✅ Pass
Rolls are derived correctly from RNG output
Win/loss logic
✅ Pass
Outcomes are evaluated exactly as the rules describe
Payout calculation
✅ Pass
Multipliers and payouts match published rules
RTP behavior
✅ Pass
RTP converges to the advertised value over time
The Dice payout logic is correct, deterministic, and statistically consistent with the advertised RTP. No abnormal bias or payout manipulation was observed.
How Dice payout and RTP works
This section verifies that the game's payout mechanics are mathematically correct and transparently implemented. The audit validates the payout formula, confirms multiplier tables match published odds, calculates the theoretical house edge, and verifies that the RTP aligns with both advertised values and simulation results.
4.1 Payout formula
Winning payouts are calculated as Bet Amount * Multiplier, where the multiplier comes from predefined game profiles based on the target number and bet direction. Losing bets return zero. The test verifies this formula against all live game outcomes, confirming every payout was calculated correctly to four decimal places.
Unit test: "Payout rules correctness" ✅
Formula:
Code implementation:
Payout test implementation:
4.2 Multiplier formula and house edge
All multipliers are calculated using the formula Multiplier = 99.9 / Win Chance %. This embeds a consistent <HOUSE_EDGE> house edge across every possible bet configuration. Whether you bet on a 1% longshot (99.9x multiplier) or a 98% favorite (1.019x), the theoretical RTP remains exactly <RTP_VALUE>.
House Edge is the mathematical advantage the casino holds over players, expressed as a percentage of each bet the casino expects to keep as profit over time. For example, a 0.1% house edge means for every $100 wagered, the casino statistically retains $0.10 while returning $99.90 to players.
RTP (Return to Player) is the percentage of total wagered money a game is mathematically expected to pay back to players over time. It is the inverse of house edge: RTP = 100% - House Edge.
Multiplier formula:
Where 99.9 = (100 - 0.1% house edge)
Example calculations:
Target 50 Over
50%
99.9 / 50 = 1.998x
50% x 1.998 = 99.9%
0.1%
Target 99 Over
1%
99.9 / 1 = 99.9x
1% x 99.9 = 99.9%
0.1%
Target 2 Under
2%
99.9 / 2 = 49.95x
2% x 49.95 = 99.9%
0.1%
Multiplier table (sample from codebase):
4.3 RTP validation (theoretical)
The test mathematically verifies every multiplier in both ABOVE_NUMBER and BELOW_NUMBER profiles by calculating Win Probability * Multiplier for all 98 target values. Each result falls within the expected 99.9%-100% RTP range, proving the advertised <RTP_VALUE> RTP is consistently applied across all bet configurations.
Unit test: "Advertised RTP matches theoretical RTP" ✅
Code implementation:
Results:
All targets (1-99) have RTP between 99.9% and 100%
Actual RTP:
<RTP_VALUE>(<HOUSE_EDGE>house edge)
4.4 Simulated RTP (Monte Carlo)
A Monte Carlo simulation of approximately <SIM_ROUNDS> bets (10,000 per target across 98 targets) empirically verified that the observed RTP converges to the advertised <RTP_VALUE> within acceptable statistical margins. Each individual target stayed within ±5% and the aggregate RTP within ±1%.
This large-scale simulation uses the exact same RNG and payout code as the live game. It loops through every target number (2-99), generates 10,000 outcomes per target using real seeds from the dataset, calculates win/loss for each bet, and tracks the cumulative return percentage.
Unit test: "Advertised RTP matches simulated RTP" ✅ (113 seconds execution time)
Code implementation:
Simulation engine:
Results:
Targets tested: 2 through 99 (98 targets)
Samples per target: 10,000 bets
Total simulated bets:
<SIM_ROUNDS>Execution time: ~113 seconds
Result: RTP converges to
<RTP_VALUE>± 1% margin ✅
(Add Monte Carlo simulation results chart image)
Technical evidence and verification
This section indexes the technical artifacts used to verify Dice payout mechanics, multiplier formulas, theoretical RTP calculations, and simulated RTP validation. All evidence is reproducible using the linked scripts and datasets.
Generated: 2026-02-11
Audit status: ✅ All RTP and payout tests passed (3/3)
1. Evidence coverage
Payout formula verification
✅ Pass
<LIVE_BETS_COUNT> live payouts verified against formula
Theoretical RTP validation
✅ Pass
All 98 targets confirm <RTP_VALUE> RTP (<HOUSE_EDGE> house edge)
Simulated RTP convergence
✅ Pass
<SIM_ROUNDS> simulated bets converge to advertised RTP
2. Code references
2.1 Test suite (RTP & Payout)
Primary test file: tests/dice/DiceAuditExecutionChecklistTests.ts
Payout rules correctness
89-94
Verifies all live payouts match formula (4 decimal precision)
Advertised RTP matches theoretical RTP
96-125
Validates 98 targets have <RTP_VALUE> RTP
Advertised RTP matches simulated RTP
127-145
Simulates <SIM_ROUNDS> bets, confirms RTP convergence
2.2 Core implementation
Payout calculator: src/dice/DiceWinCalculator.ts
Win calculation logic
5-28
calculateWinnings() applies multiplier or returns 0
Multiplier tables: src/dice/DiceGameProfiles.ts
ABOVE_NUMBER multipliers
103-203
Multipliers for "over target" bets (targets 1-99)
BELOW_NUMBER multipliers
3-101
Multipliers for "under target" bets (targets 1-99)
RTP simulator: src/dice/DiceGameSimulator.ts
Simulation engine
12-46
Monte Carlo simulation of <SIM_ROUNDS> bets
3. Datasets
Primary dataset: duel-dice-sim-1767531771390.json
Source
Live Dice game data from duel.com/dice
Total records
<LIVE_BETS_COUNT> bets
Used for
Verifying live payouts match calculated formula
Fields used for payout verification:
betAmount
Wager amount (USD)
drawnNumber
Dice outcome (0.00-100.00)
targetNumber
Player-selected target
overTheTarget
Bet direction (true = over, false = under)
winAmount
Actual payout from live game
Verification method:
Extract (betAmount, drawnNumber, targetNumber, overTheTarget) from live data
Calculate expected payout:
DiceWinCalculator.calculateWinnings()Compare calculated payout with
winAmountfrom the live gameAssert match to 4 decimal places
4. Reproduction instructions
Expected output (payout formula):
Expected output (theoretical RTP):
Expected output (simulated RTP):
5. Reproducibility pinning
Git commit
fa913ab94883d06950d3c63bbb7007f927648131
Dataset hash (SHA-256)
ba3ae70517c7f77e07eaced46900a5f94ebc02bf11c41502fac894f142efb799
npm version
11.3.0 (minimum: 8.x)
Node version
v22.11.0 (minimum: v16.x)
5. Exploit & Edge-Case Testing
An exploit would allow a player or the casino to predict outcomes before betting, manipulate results after betting, or gain an unfair advantage through implementation weaknesses. This section tests the Dice game against the ProvablyFair.org Exploit Reference Database, a catalog of real, historically observed failures in provably fair systems.
What was tested
Attempts to break provably fair guarantees by:
Predicting outcomes before betting
Manipulating results after betting
Gaining an unfair advantage through implementation flaws
Verdict
Outcome prediction
✅ Pass
No one can know the result before you bet
Post-bet manipulation
✅ Pass
Results cannot be altered after a bet is placed
Seed lifecycle abuse
✅ Pass
The commit-reveal system cannot be bypassed
Nonce reuse or desync
✅ Pass
Every bet is unique and irreversible
RNG bias exploitation
✅ Pass
Every outcome has an equal chance
Cross-bet or cross-user influence
✅ Pass
Your bets are isolated from all other bets and players
All tested exploit categories failed to produce any unfair advantage. No tested vector enabled outcome prediction, post-bet manipulation, house-edge distortion, or unauthorized bankroll advantage.
How exploit and edge-case testing works
This section describes the methodology used to test whether the provably fair system can be manipulated through known attack vectors. Exploit procedures, payloads, and reproduction steps are intentionally abstracted in the public report to avoid disclosing actionable attack vectors.
5.1 What constitutes an exploit
An exploit in a provably fair system allows one party to gain an unfair advantage by violating the fundamental guarantees of fairness.
Outcome prediction
Knowing the result before betting
Player
Casino loses revenue to advantage players
Result manipulation
Changing outcome after bet placed
Casino
Players lose without a fair chance
Seed leakage
Accessing unrevealed server seeds
Player
Predictable outcomes, guaranteed wins
Nonce replay
Reusing nonces to recreate favorable outcomes
Player
Cherry-picking winning results
RNG bias
Non-uniform outcome distribution
Casino
House edge higher than advertised
Verification bypass
Preventing players from verifying results
Casino
Undetectable manipulation
5.2 Exploit reference framework
Testing is based on the ProvablyFair.org Exploit Reference Database, which includes exploit classes derived from:
Incorrect seed lifecycle handling
Nonce reuse or unintended resets
Mixed or hidden entropy sources
Stateful RNG implementations
Hash truncation or modulo bias errors
Cross-round or cross-user state leakage
Testing approach for each exploit class:
Identify the historical failure pattern from the reference database
Target the corresponding fairness invariant
Simulate realistic attack conditions under actual gameplay constraints
Validate the system response and confirm the exploit is prevented
5.3 What would break fairness
Server seed revealed before bet
Player can predict outcomes
Timing analysis
Hash mismatch on reveal
Casino can swap seeds
Hash comparison
Nonce skip or reuse
Verification fails
Sequence analysis
Non-deterministic output
Cannot verify results
Repeat testing
Hidden entropy injection
Outcomes unverifiable
Code audit
Verifier logic differs from live
False verification
Parity testing
5.4 Exploit coverage overview
Outcome prediction
Outcomes are unpredictable before betting
Post-bet manipulation
Results cannot be altered after a bet is placed
Seed lifecycle abuse
Server seed commitment cannot be bypassed
Nonce misuse
Each bet is unique and irreversible
RNG bias exploitation
Every outcome has an equal chance
State leakage
Bets are isolated across rounds and players
Exploit procedures, payloads, and reproduction steps are intentionally abstracted in the public report to avoid disclosing actionable attack vectors.
Technical evidence and verification
This section provides the exploit coverage matrix, an illustrative (redacted) exploit attempt, and the verified invariants.
1. Exploit coverage matrix
Seed manipulation
Commit-reveal integrity
✅ Pass
Seed tests
Seed replay
Seed uniqueness
✅ Pass
Dataset checks
Nonce reuse
Nonce monotonicity
✅ Pass
Nonce sequencing
Nonce desync
Bet ordering integrity
✅ Pass
Transition tests
Client seed abuse
Client entropy isolation
✅ Pass
RNG dependency
Mixed entropy
Entropy isolation
✅ Pass
Code inspection
RNG bias
Uniform distribution
✅ Pass
Bias tests
Hash truncation
Full hash usage
✅ Pass
HMAC verification
State leakage
Stateless RNG
✅ Pass
Isolation tests
Cross-user influence
Session isolation
✅ Pass
Seed scoping
2. Illustrative exploit attempt
Example: Nonce reuse / replay attack
Goal: Attempt to reproduce a favorable outcome by reusing a previously observed (serverSeed, clientSeed, nonce) tuple.
Observed behavior:
Nonce increments strictly per bet
No reuse detected within any seed session
Identical inputs only reproduce historical outcomes
Result: Exploit not possible. This behavior is consistent across all observed seed sessions.
3. Verified exploit invariants
Outcomes cannot be predicted before betting
✅ Verified
Outcomes cannot be altered after betting
✅ Verified
No replay of favorable outcomes
✅ Verified
No cross-bet influence
✅ Verified
No cross-user influence
✅ Verified
No client-side leverage over server entropy
✅ Verified
4. Disclosure and limitations
Full Exploit Test Artifacts
Full exploit test artifacts are retained internally by ProvablyFair.org and may be disclosed to the operator under NDA if required.
6. Player Verification Guide
Provably fair gaming shifts the burden of proof from the casino to mathematics. Instead of trusting that outcomes are fair, you can verify every game result yourself. Every seed, nonce, and calculation is available for independent verification.
This section guides you through the verification process, from one-click verification in the Duel UI to running the exact HMAC-SHA256 algorithms on your own machine.
Core principle: If your calculated result matches the displayed result, the game was provably fair.
Independently verify a Dice game result
Every Dice outcome can be reproduced using publicly disclosed inputs. There are no hidden variables and no reliance on private backend data.
All required inputs for result generation are publicly available
No hidden parameters or undisclosed backend logic are involved
The outcome can be reproduced independently by any player
A matching recalculated result confirms the integrity of the game round
How to verify
Standard verification: Most players can verify results directly through the Duel user interface.
Advanced verification: For technical users, the complete verification logic and reproducible test artifacts are provided below for independent validation.
(add Screenshot of the Duel verification modal showing all four inputs)
Summary table
Server Seed
Verify tab (revealed after seed rotation)
Casino entropy source
Client Seed
Verify tab
Player entropy input
Nonce
Verify tab
Bet counter (ensures uniqueness)
Result
Results tab
Must match your recomputed output
Overall verdict
🟢 Any player can reproduce Dice results
🟢 Only disclosed inputs are used
🟢 Identical inputs always produce identical output
Visual walkthrough (instruction layer)
How to verify your bet
Open bet details: after any bet, click on the bet result to open the details modal. You see the bet ID, result, multiplier, and target.
[add screenshot of bet details modal (Results tab)]
(add screenshot of bet result list showing clickable entries)
Click the "Verify" tab: in the bet details modal, switch from the "Results" tab to the Verify tab. This opens the verification interface linked to the provably fair verification model.
(add screenshot of Verify tab in bet details modal)
Review your seeds: the Verify tab displays:
Client Seed: your player-controlled seed (for example,
G3blCQBWQdVfM8sx)Server Seed: the revealed server seed (64 hex characters)
Server Seed Hash: the pre-committed hash shown before the bet
Nonce: the bet number in the sequence (starts at 0)
When you click "Rotate Seed," a new pop-up opens, displaying verification results and sample code.
Verify the result: the verifier displays the calculated result based on your seeds. Compare this to your actual game result. They must match exactly.
Use Copy code to get the JavaScript verification script shown in the interface.
(add screenshot of verification result comparison showing match)
(add screenshot of verification code copy interface)
How to check the server seed hash
Before placing any bet, you can view the pre-committed server seed hash directly in the game interface:
Click the Provably Fair button located below the game controls.
View the Active server seed (Hashed) field in the modal.
Copy this hash. It is your proof that the server seed was committed before your bet.
The modal also displays your Active client seed, current Nonce, and options to set a New client seed or view the Next server seed (Hashed) for upcoming sessions. Clicking Rotate seed reveals the current server seed and generates a new one for future bets. At that point, you can verify that the revealed seed matches the hash you recorded.
Important: Always copy the "Active server seed (Hashed)" before betting if you want to verify later. Once you rotate seeds, the previous hash is replaced.
(add screenshot of Provably Fair button below game controls)
(add screenshot of Provably Fair modal showing hashed server seed)
How player verification works
How the verification model works
Player verification in the Dice game follows a deterministic flow. The same three inputs always produce the same output. This is the mathematical guarantee behind provably fair gaming.
Why the commit-reveal protocol matters
The commit-reveal protocol prevents the casino from manipulating outcomes after seeing your bet:
Commit
Before you bet, the server seed hash is displayed
Locks the server seed. Changing it would change the hash.
Bet
You place your bet with the current client seed and nonce
Your inputs combine with the locked server seed
Reveal
After seed rotation, the actual server seed is disclosed
You can now verify the hash matches
Verify
You hash the revealed seed and compare to the committed hash
Proves the server seed was not changed after your bet
This protocol ensures:
The server cannot change its seed after seeing your bet
You can independently confirm the seed was pre-committed
Any tampering would produce a hash mismatch
Manual verification (advanced)
Manual verification
While the built-in verifier is convenient, true provably fair verification means you don't need to trust any casino-provided tool. Manual verification lets you:
Run calculations on your own machine with your own code
Eliminate any possibility of a tampered verifier
Understand exactly how your results are generated
Verify using multiple programming languages for cross-confirmation
Verify a Dice roll
The following JavaScript code reproduces the exact Dice RNG algorithm. Run it in any Node.js environment.
(add screenshot of manual verification terminal output)
Verify the server seed hash
The commit-reveal protocol ensures the casino cannot change the server seed after seeing your bet. Use this function to verify the revealed seed matches the pre-committed hash:
(add screenshot of server seed hash verification output)
7. Reproducibility & Artifacts
Every test, dataset, and result in this audit is fully reproducible. The complete audit codebase is open source. You can clone the repository, run the same tests, and verify the same results on your own machine.
Prerequisites
To reproduce the audit results locally, you need:
Node.js 16+
npm 8+
Git
GitHub repository
Verdict
Open source repository
✅ Pass
All audit code is publicly available
Reproducible test suite
✅ Pass
You can run the exact same tests locally
Pinned commit
✅ Pass
The audited code version is locked and verifiable
Dataset integrity
✅ Pass
The dataset hash confirms no tampering
Repository structure and reproduction steps
Repository structure
Commands to reproduce
Step 1: Clone repository
Step 2: Install dependencies
Step 3: Run tests
Run all tests:
Run Dice-specific tests only:
Step 4: Generate audit report
Audit reproducibility pinning
All audit results are pinned to the following versions and artifacts. Any reproduction attempt should use these exact references to guarantee identical results.
Git Commit
fa913ab94883d06950d3c63bbb7007f927648131
Dataset Hash (SHA-256)
ba3ae70517c7f77e07eaced46900a5f94ebc02bf11c41502fac894f142efb799
npm Version
11.3.0 (minimum: 8.x)
Node Version
v22.11.0 (minimum: v16.x)
Audit conducted by ProvablyFair.org
Last updated: 31/01/2026
Last updated