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: 23 verification steps, 24M simulated rounds, 7,050 live bets re-verified.
Mines Audit Overview
This audit independently validates the Mines 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 7,050 real bets across 151 seed entries 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 within a seed pair
- Mine positions are computed via HMAC-SHA256 backward Fisher-Yates with bias-free rejection sampling
- Outcomes are reproducible from server seed, client seed, and nonce
- Single-reveal and multi-reveal payouts match the combinatorial formula C(25,k) / C(25−m,k) × 0.999 for all 300 (mine count, reveals) combinations
- The mine set is fixed at round start and unchanged by reveal sequence or cash-out timing
- Theoretical RTP is 99.9% across all 24 configurations (flat 0.1% house edge)
- Bet amount does not influence mine placement or outcome
- 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, seed pair rotation |
| RNG Analysis | HMAC-SHA256 backward Fisher-Yates verification, rejection sampling, bias analysis |
| Payout Logic | Combinatorial multiplier formula, multi-reveal chains, cash-out correctness, bet-size invariance (Phase C) |
| Live Parity | Independent mine-position recomputation vs live game results across all capture phases |
| RTP Validation | Anti-circularity proof, simulated RTP (24M rounds), cherry-pick detection (Pass 2) |
| Fairness Integrity | Standard integrity matrix — 15 tests across commit-reveal, determinism, payout, isolation, and parameter enforcement |
What Audit Guarantees
- Outcomes are deterministic and reproducible from the recorded inputs
- Live game results match independent recomputation for the verified sample (7,050 / 7,050)
- Mine positions follow the uniform distribution expected from the backward Fisher-Yates shuffle across all 24 mine counts
- RTP is proven analytically: winChance × payoutMult = 0.999 for all 300 (mine count, reveals) combinations by combinatorial cancellation
- Simulated RTP of 99.904% across 24 million rounds (1M per mine count) — matches the theoretical 99.9% within expected variance
- The mine set is fixed at round start and independent of which tile the player reveals
- Client seed is a genuine, browser-generated input that materially influences results
- The house edge is a flat 0.1% across all 24 mine counts — no scaling edge
- All 16 fairness integrity tests passed at audit time, including the Mines-specific multi-step state integrity test
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
Mines — Game Rules7 sections▶
Mines is a grid-based reveal game: choose how many mines hide on a 5×5 board, then flip tiles one at a time. Every safe reveal grows the payout; hit a mine and the round ends.
Mines is a grid-based game on a 5×5 board of 25 tiles. Before each round the player chooses a mine count between 1 and 24. The platform places the mines on the grid server-side using a backward Fisher-Yates shuffle seeded with HMAC-SHA256. The player then reveals tiles one at a time: each safe reveal grows the multiplier; hitting a mine ends the round and forfeits the bet. The player may cash out after any safe reveal. More mines means a higher reward per safe reveal but a higher chance of hitting one.
1. Choose mine count — Select between 1 and 24 mines. More mines means higher reward per safe reveal but a higher chance of hitting a mine.
2. Enter bet amount — Choose how much to wager.
3. Reveal tiles — Click tiles one at a time. Each safe reveal grows the running multiplier.
4. Cash out or continue — After any safe reveal, choose to cash out at the current multiplier or push on for more.
5. Outcome — If you hit a mine, the round ends and the bet is lost. If you cash out, payout = bet × multiplier at the current reveal count.
The win condition in Mines depends on whether the revealed tile is in the mine set.
| Outcome | Condition | Example (mines=3, k=5) |
|---|---|---|
| Safe reveal | Revealed tile is not in mine set | Multiplier grows; player may cash out or continue |
| Cash out | Player stops after k safe reveals | k=5 → payout × 2.017× |
| Loss | Revealed tile is in mine set | Round ends, bet is lost |
The core mechanic of Mines is the tradeoff between mine count and safe-reveal risk.
- Mine count controls risk per reveal — more mines means fewer safe tiles, higher multiplier growth per reveal, and a higher chance the next reveal ends the round
- Reveal count controls total multiplier — each additional safe reveal multiplies your running payout by the ratio
(25−k) / (25−m−k) - RTP is constant — all 24 mine counts have the same theoretical RTP (99.9%) regardless of how many reveals you take
| Parameter | Value | Notes |
|---|---|---|
| Grid Size | 25 tiles (5×5) | Fixed; all rounds use this layout |
| Mine Count | 1–24 | Player-selected; determines risk and multiplier curve |
| Configurations | 24 | One per distinct mine count |
| House Edge | 0.1% flat | No scaling — same edge for all mine counts and all bet sizes |
| Theoretical RTP | 99.9% | Verified across all 24 mine counts |
| RNG Algorithm | HMAC-SHA256 | Backward Fisher-Yates with bias-free rejection sampling; key = hex-decoded server seed |
Every Mines bet uses three cryptographic inputs to generate the mine layout.
| Seed Type | Format | Example | Purpose |
|---|---|---|---|
| Server Seed | 64-char hex (32 bytes) | 01b20487103f970a… | Casino-provided randomness |
| Client Seed | Alphanumeric string | NxcarOV28bkerHJk | Player-contributed entropy |
| Nonce | Integer ≥ 0 | 6 | Per-round counter within the active seed pair |
serverSeedHashed (SHA-256 of the raw hex bytes) before play and revealed only on seed rotation. The HMAC key is the hex-decoded bytes of the server seed, not its UTF-8 text.The payout multiplier after k safe reveals with m mines is the combinatorial ratio of unrevealed configurations multiplied by the house-edge factor.
multiplier(k, m) = C(25, k) / C(25−m, k) × 0.999| Reveals (k) | Mines (m) | Raw multiplier | With 0.1% edge |
|---|---|---|---|
| 1 | 1 | 1.0417× | 1.0406× |
| 1 | 3 | 1.1364× | 1.1352× |
| 1 | 5 | 1.2500× | 1.2488× |
| 3 | 5 | 2.0175× | 2.0155× |
| 5 | 3 | 1.9409× | 1.9390× |
| 10 | 3 | 4.3636× | 4.3592× |
multiplier as the raw combinatorial ratio C(25,k)/C(25−m,k) without the edge applied, and no_house_edge_multiplier as the actual payout multiplier with the 0.999 edge factor applied. Payout is computed as amount_won = amount × no_house_edge_multiplier. The naming is counter-intuitive — the field labelled no_house_edge_multiplier is the one that includes the house edge. We verify against the correct field throughout.Why Provably Fair Matters▶
Traditional online casinos ask you to trust them. Provably fair cryptography replaces that trust with independently verifiable proof. Every bet you place can be reconstructed from three public inputs — the server seed, your client seed, and the nonce — and the result you see should match the result anyone else can compute from those inputs.
- No outcome manipulation — the server seed is committed (SHA-256 hashed) and published before you play. The casino cannot change the outcome based on your bet size or history without breaking the commitment.
- Your seed matters — the client seed is controlled by your browser, not the casino. Changing it produces a different outcome for the same server seed and nonce, which proves your input is genuinely part of the computation.
- Verifiable by anyone — once the server seed is revealed on rotation, anyone with the seed triple can recompute the result with a few lines of code. The casino has no way to hide a tampered outcome.
- Mathematically bounded — the published multiplier formula determines payouts. We prove from first principles that win-chance × payout-multiplier equals 99.9% for every configuration, so the house edge cannot be inflated silently.
High-Level Overview8 sections▶
This section walks through how a Mines bet moves through the system end-to-end — from the server seed commitment, through the bet and reveal flow, to the post-rotation verification step that closes the loop.
Checklist Reference
Commit-Reveal
| Check | What it proves |
|---|---|
| Server seed committed before play | Casino cannot change outcome post-bet |
| SHA-256 of revealed seed matches committed hash | Revealed seed is the one that was actually committed |
| Hash identical across all bets in an epoch | All bets within a seed pair share the same commitment |
Seed System
| Check | What it proves |
|---|---|
| Nonces are sequential within an epoch | No nonce skipping or reuse |
| Single client seed per epoch | Client seed cannot be silently rotated mid-epoch |
| Next-seed pre-committed before rotation | Future commitment chain is locked in before reveal |
RNG & Parity
| Check | What it proves |
|---|---|
| Mine positions recompute from seeds + nonce | Outcome is deterministic and verifiable |
| Independent verifier matches live API for every bet | No hidden inputs to the RNG |
| Mine set invariant across reveal sequence | Layout fixed at round start, not rewritten per reveal |
Payout & RTP
| Check | What it proves |
|---|---|
| Multiplier matches C(25,k)/C(25−m,k) × 0.999 | Payout formula matches published rules |
| amount_won = amount × no_house_edge_multiplier | Payout arithmetic is exact to 1e-8 |
| winChance × payoutMult = 0.999 for all m | RTP is fixed at 99.9% by construction, not observation |
Integrity
| Check | What it proves |
|---|---|
| Wrong client seed produces different mines | Client seed genuinely influences outcome |
| Bet size does not influence outcome | Phase C $10 bets match Phase A/B $0.01 bets |
| No cherry-picking in seed selection (Pass 2) | Casino is not curating favourable seeds |
A Mines round runs through five stages — from the casino committing to a server seed before you play, through the bet and reveals, to the post-rotation verification that anyone can run.
1. Commit — Server generates server seed, publishes SHA-256 hash as `serverSeedHashed`. Player sees only the hash.
2. Seed pair activated — Client seed is browser-generated (or player-set). Nonce starts at 0. Next server seed is pre-committed.
3. Bet — Player selects mine count and bet amount. Platform computes mine positions via HMAC-SHA256 backward Fisher-Yates using the active seed pair + nonce.
4. Reveals — Player reveals tiles one at a time. Multiplier grows per safe reveal. Player may cash out at any point.
5. Rotate — On client-seed change or manual rotation, the active server seed is revealed. The next-committed seed becomes active.
6. Verify — Anyone with serverSeed, clientSeed, nonce, and mine count can recompute the exact mine set.
Mines is a commit-reveal provably fair game. The casino commits to a server seed by publishing its SHA-256 hash before any bet is placed. Once play on that seed is complete and the seed is rotated, the casino reveals the raw server seed. Anyone can then verify two things: (1) that the revealed seed hashes to the previously-published commitment, and (2) that the mine positions for every bet in that epoch recompute correctly from the seed triple. The model does not require trust in the casino — only that SHA-256 and HMAC-SHA256 are cryptographically sound, which is a well-established assumption.
Mines uses a four-phase commit-reveal cycle. Each phase has a single, well-defined purpose, and every phase produces artefacts that can be verified after the fact.
Commit phase
Server generates a 32-byte random server seed, computes `SHA-256(hex_bytes(serverSeed))`, and publishes the hash as `serverSeedHashed`. The raw seed is kept secret. A next-seed hash is also pre-committed.
Bet phase
Player places bets against the active seed pair. For each bet, mine positions are computed via `HMAC-SHA256(key=hex_bytes(serverSeed), msg=clientSeed:nonce:cursor)` followed by backward Fisher-Yates on the 25-tile grid. Nonce increments per bet.
Reveal phase
Player (or system) rotates the seed pair — typically by changing the client seed. The previously-active server seed is now revealed in the API. The pre-committed next-seed hash becomes the active `serverSeedHashed`.
Verify phase
Anyone with the seed triple can run HMAC-SHA256 + Fisher-Yates independently and confirm that mine positions match the values returned by the live API. The commitment chain is preserved: revealed hash = prior commitment.
The client seed is the player's lever into the RNG. It is generated in the browser (not the server) and can be replaced at any time, which forces a seed rotation.
- Browser-generated — a fresh 16-character alphanumeric string is produced client-side on first load
- Player-editable — the player can overwrite it with any value they choose; changing the client seed triggers a seed rotation and reveals the active server seed
- Materially influences outcome — we verified that changing
clientSeedto a random alternative produces different mine positions in 646 / 650 tests (99.4%); the remaining 4 collisions are expected at low mine counts where the sample space is small - Not known to the server at commit time — the server publishes
serverSeedHashedbefore your client seed is known, so it cannot cherry-pick a commitment that favours the casino against your specific seed
Nonce Lifecycle
The nonce is a per-round counter within the active seed pair. It starts at 0, increments by 1 per bet, and resets only on seed rotation. The nonce is reused across all reveals in a single round — the mine set is computed once, at bet time, and is unchanged by subsequent reveals.
- Starts at 0 on every new seed pair
- Increments sequentially — no skipping, no reuse within an epoch
- Resets on rotation — every rotation produces a fresh nonce=0 sequence
- Shared across reveals — all reveals in a round use the same nonce; the mine set is fixed at
noncetime
// Per seed pair, nonce sequence:
// bet 1 → nonce=0
// bet 2 → nonce=1
// bet 3 → nonce=2
// ...
// On client seed change:
// serverSeed revealed, new pair activated, nonce resets to 0Determinism Guarantee
Given serverSeed, clientSeed, nonce, and mineCount, the mine set is fully determined — there is no randomness, no hidden input, and no dependence on bet amount, timestamp, or any other variable. The pipeline is:
// Inputs: serverSeed (hex), clientSeed (string), nonce (int), mineCount (1–24)
key = Buffer.from(serverSeed, 'hex') // hex-decoded bytes, NOT utf-8
grid = [0, 1, 2, ..., 24]
cursor = 0
for i from 24 down to 1:
range = i + 1
maxFair = 0xFFFFFFFF - (0xFFFFFFFF % range)
loop:
hash = HMAC-SHA256(key, `${clientSeed}:${nonce}:${cursor}`)
scan 4-byte chunks of hash:
if chunk < maxFair:
j = chunk % range
swap grid[i] ↔ grid[j]
break out of loop
cursor++ // only if no chunk passed rejection
mine_positions = grid[0 .. mineCount-1] // sorted ascendingTechnical Glossary7 categories▶
Terms and definitions used throughout this audit report, grouped by category.
| Term | Definition |
|---|---|
| Provably Fair | A system where every game outcome can be independently verified from public cryptographic inputs, without trusting the operator. |
| Commit-Reveal | A two-phase protocol where a party publishes a hash of a secret before play (commit), then reveals the secret afterward (reveal). The hash proves the secret was fixed in advance. |
| Determinism | A property where the same inputs always produce the same output. Mines is deterministic: `(serverSeed, clientSeed, nonce, mineCount)` uniquely determines the mine set. |
| Epoch | The set of bets placed under a single active seed pair, from activation to rotation. Also called a seed pair lifecycle. |
| Term | Definition |
|---|---|
| Server Seed | A 32-byte random value generated by the casino. Represented as a 64-character hex string. Used as the HMAC key (hex-decoded). |
| Server Seed Hashed | `SHA-256(hex_bytes(serverSeed))`. The commitment published before play. |
| Client Seed | A player-controlled alphanumeric string, browser-generated by default. Part of the HMAC message. |
| Nonce | A per-round counter within the active seed pair. Starts at 0, increments per bet, shared across all reveals in a single round, resets on seed rotation. |
| Cursor | A rejection-sampling retry counter appended to the HMAC message. Increments only when every 4-byte chunk of the previous hash exceeded the fairness threshold. |
| Seed Pair | The combination of one server seed and one client seed. A seed pair defines an epoch. |
| Next Server Seed Hash | A pre-commitment to the server seed that will become active after the current one is rotated. Locks the future chain in advance. |
| Term | Definition |
|---|---|
| SHA-256 | A 256-bit cryptographic hash function. Used here for server seed commitment: `SHA-256(hex_bytes(serverSeed)) = serverSeedHashed`. |
| HMAC-SHA256 | Hash-based message authentication code built on SHA-256. Takes a key and a message, returns a 256-bit (64-hex-char) digest. Used here for mine position generation. |
| HMAC-SHA256 Backward Fisher-Yates | The full RNG pipeline: HMAC-SHA256 produces the 4-byte random chunks; backward Fisher-Yates uses those chunks to shuffle the 25-tile grid. Mines-specific implementation. |
| Rejection Sampling | A technique for bias-free uniform sampling. A 4-byte chunk is accepted only if it falls below `maxFair = 0xFFFFFFFF − (0xFFFFFFFF mod range)`. Guarantees every position in `range` is equally likely. |
| Term | Definition |
|---|---|
| Parity | Agreement between the live game's reported outcome and an independent recomputation from the same inputs. 100% parity means zero mismatches. |
| Recomputation | Running the audit's standalone RNG implementation on captured seed triples and comparing the output to the live API response. |
| Anti-Circularity Proof | A proof that RTP is not an empirical observation but a mathematical identity — `winChance × payoutMult = 0.999` by algebraic cancellation, independent of any simulation. |
| Cherry-Pick Detection (Pass 2) | A statistical test over revealed casino seeds that checks whether early-epoch win rates systematically exceed later-epoch win rates — the signature of seed pre-selection. |
| Term | Definition |
|---|---|
| Mine Count | The number of mines placed on the 25-tile grid for a given round. Player-selected, range 1–24. |
| Reveal | The act of clicking a tile. A safe reveal grows the multiplier; a mine reveal ends the round. |
| Multiplier Chain | The sequence of running multipliers as a player reveals tiles: `m₁, m₂, ..., mₖ`. Each step satisfies `mₖ = C(25,k) / C(25−m,k) × 0.999`. |
| Cash-Out | Stopping after k safe reveals and collecting `amount × mₖ`. Only available after at least one safe reveal. |
| Mine Set Invariance | The property that the mine set is fixed at round start and does not change based on which tiles the player reveals, or in what order. |
| Combinatorial Identity | The algebraic cancellation that proves Mines' RTP: `winChance(k, m) × payoutMult(k, m) = (C(25−m, k) / C(25, k)) × (C(25, k) / C(25−m, k) × 0.999) = 0.999` for all valid `k, m`. |
| Term | Definition |
|---|---|
| Fairness Integrity (FI) Matrix | The standard 15-test matrix applied to every audit, covering commit-reveal, determinism, payout, isolation, and parameter enforcement. Documented in S5. |
| Chi-Squared Test | A goodness-of-fit test comparing observed distributions (e.g., mine positions, win counts) to theoretical expectations. Used with Bonferroni correction where multiple configurations are tested. |
| Bonferroni Correction | A multiple-comparison adjustment: when testing N hypotheses at significance α, the per-test threshold is α/N. Prevents false positives from mass testing. |
| Point-in-Time Audit | An audit verdict that applies to the code and configuration in force at the audit date. Subsequent changes are outside scope unless re-certified. |
| Term | Definition |
|---|---|
| mines-master-6500bets.json | Primary capture dataset. 6,500 auto-bet rounds across Phases A–D, all with `k=1` safe-reveal outcomes. SHA-256 pinned in S1. |
| mines-phaseE-550bets.json | Multi-reveal and cash-out capture dataset. 550 rounds across 5 sub-phases (E1–E5) covering `k` up to 5 and varied reveal positions. SHA-256 pinned in S1. |
| verification-results.json | Output of the 23-step verification pipeline. Contains per-step pass/fail status and per-step detail strings. |
| simulation-results.json | Output of the 24-configuration × 1M-round simulation. Contains Pass 1 (fresh seeds, RTP + chi²) and Pass 2 (casino seeds, cherry-pick detection). |
Every Mines round 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 142 epochs
- Mine positions are fully determined by the seed inputs before any tile is revealed
- Identical inputs always produce the same mine set — confirmed across all 7,050 bets
- Your client seed is a genuine input — changing it changes the mine layout
What This Means for You
- The casino cannot change where the mines are 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
- Cherry-picking favourable seeds is structurally impossible
| Test | Status | Finding |
|---|---|---|
| Server seed committed before bet | Pass | SHA-256 hash of server seed published before play — casino cannot change mine layout 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 epoch, 0 gaps, 0 duplicates across 142 epochs |
| Hash consistency within epoch | Pass | serverSeedHashed constant across all bets within each of 142 epochs |
| Seed hash integrity | Pass | 130 / 130 revealed seeds hash-verified — commitment chain intact |
| Deterministic output | Pass | Same (serverSeed, clientSeed, nonce, mineCount) always produces same mine SET — 7,050 / 7,050 confirmed |
| Client seed participation | Pass | Client seed is a genuine input — changing it changes the mine positions (646 / 650, 99.4%) |
All 130 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 mine layout. The casino cannot change your result after you bet.
This section verifies that Duel.com's Mines random number generation produces cryptographically sound, unbiased outputs using only the disclosed inputs. The RNG uses a backward Fisher-Yates shuffle with HMAC-SHA256 — each shuffle step derives a swap index from a 4-byte HMAC chunk with bias-free rejection sampling via the maxFair ceiling. 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 shuffle step
- Only disclosed inputs affect outcomes — no timestamps, no server-side state, no hidden entropy
- Rejection sampling via `maxFair` ceiling eliminates modulo bias for all ranges (2–25)
- Mine placement follows uniform distribution for all 24 configurations (confirmed over 24M simulated rounds)
- Consecutive outcomes are statistically independent — no patterns, no streaks
- 99.4% of outcomes change with a different client seed (646 / 650 tested bets)
What This Means for You
- Each mine placement is generated fairly and cannot be skewed
- All 25 grid positions are equally likely to host a mine — no positional bias
- No hidden randomness or server-side tricks influence where mines appear
- 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:cursor) — no hidden entropy |
| Entropy purity | Pass | No timestamps, external APIs, Math.random, or server-side state |
| Algorithm independently implemented | Pass | Independent implementation produces identical mine sets for all 7,050 bets |
| Modulo bias | Pass | Rejection sampling via `maxFair` ceiling eliminates bias for all ranges (2–25) |
| Key encoding verified | Pass | Server seed hex-decoded to bytes (not UTF-8) — confirmed via 7,050-bet recomputation |
| Serial independence | Pass | Lag-1 autocorrelation near zero and runs tests pass across all 24 configs at 1M rounds each |
| Client seed influence | Pass | 99.4% of outcomes change with an alternate client seed — confirmed across 650 tested bets |
The Mines RNG uses only the disclosed inputs, produces uniform mine-position distribution across all 24 configurations, and shows no serial dependence across 24M simulated rounds. The client seed is a genuine input — 99.4% of outcomes change with a different seed.
This section validates that the independent verifier produces the exact same mine set 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 mine SET verified, not just the payout
- Payout correctness: amount_won = amount × no_house_edge_multiplier, exact to 8 decimal places for all 7,050 bets
- Multiplier formula C(25,k) / C(25−m,k) × 0.999 produces the correct value for all 24 mine-count configurations
- Bet amount is not an input to the RNG — mine layout depends only on seeds and nonce
- All five capture phases recomputed identically (config coverage, high-mine edge case, elevated stake, client-seed variation, multi-reveal + cash-out)
What This Means for You
- The verifier isn't a simulation — it produces the exact same mine set 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 many tiles you reveal
- The game engine in production matches the published algorithm exactly
| Test | Status | Finding |
|---|---|---|
| Mine-set recomputation | Pass | 7,050/7,050 exact match — mine SET verified for every bet |
| Payout correctness | Pass | All 7,050 bets: amount_won = amount × no_house_edge_multiplier, exact to 8 decimal places |
| Multiplier formula integrity | Pass | All observed multipliers match C(25,k) / C(25−m,k) × 0.999 for all 24 mine-count configurations |
| Bet-size independence | Pass | Bet amount is absent from the RNG input — mine layout depends only on seeds and nonce |
| Config completeness | Pass | All 24 mine-count configurations (1–24) covered in live data |
| Multi-reveal parity | Pass | Phase E: 795 reveal steps verified across k ∈ {1..5}; 550 multi-reveal bets match recomputed mine set |
| Multi-phase coverage | Pass | 5 structured phases: config coverage (A), high-mine edge case (B), elevated stake (C), client-seed variation (D), multi-reveal + cash-out (E) |
All 7,050 bets matched the independent verifier exactly — mine sets verified across all five capture phases, including 550 multi-reveal bets with up to 5 reveals each. Payout math correct. Multiplier formula confirmed across all 24 mine-count configurations.
This section mathematically verifies that the flat 0.1% house edge is exactly what's advertised across all 24 mine-count configurations. The key test is anti-circularity: we prove the RTP from first principles using combinatorial cancellation — the win-chance ratio and the payout-multiplier ratio cancel algebraically to produce exactly 0.999, independent of any casino-supplied probability data. We then confirm it against 24 million simulated rounds and test whether the casino pre-selected favourable seeds.
What We Verified
- House edge is exactly 0.1% — flat across all 24 mine-count configurations and all bet sizes
- RTP proven from first principles: winChance × multiplier = 0.999 for every configuration — by algebraic cancellation, not summation
- 24M-round simulation converges on theoretical RTP (mean 99.904%)
- Cherry-pick detection: 130 casino seeds tested — no evidence of seed pre-selection
- Bet amount does not influence mine placement — confirmed at $0.01 and $10
What This Means for You
- The house edge on Mines is a flat 0.1%, the same regardless of which configuration or bet size you choose
- 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 where the mines are placed
- No scaling house edge — Mines' margin is uniform across all 24 configurations
| Test | Status | Finding |
|---|---|---|
| Anti-circularity | Pass | winChance × payoutMult = 0.999 for all 300 (mine count, reveals) combinations — proven by algebraic cancellation of C(25−m,k)/C(25,k) × C(25,k)/C(25−m,k) × 0.999, no casino data used |
| House edge audit | Pass | Flat 0.1% house edge across all 24 mine-count configurations — derived from `× 0.999` factor in the multiplier formula `25/(25−m) × 0.999`; flat across all bet sizes |
| Simulated RTP (Pass 1) | Pass | 24M rounds, avg RTP = 99.904%, 0/24 chi-squared failures, 0/24 serial independence failures |
| Cherry-pick detection (Pass 2) | Pass | 130 casino seeds tested at mines=3 × 10K nonces — Test A: 1/130 fails (expected), Test B: 7 cherry-pick flags, 0 broad — no evidence of seed pre-selection |
| Bet-size invariance | Pass | Bet amount is not an input to the RNG — same mine-set distribution at $0.01 and $10. Tested in Phase C (200/200) |
| Multiplier formula | Pass | C(25,k) / C(25−m,k) × 0.999 independently verified for all 24 configs at k=1 and all 795 multi-reveal steps at k ∈ {1..5} |
| Config completeness | Pass | All 24 mine-count configurations (1–24) covered |
The 99.9% RTP is proven mathematically from combinatorial cancellation — winChance × multiplier = 0.999 for all 24 mine-count configurations, and the identity extends unchanged to any reveal count k. This is a first-principles proof, not a statistical estimate. 24M simulated rounds and cherry-pick detection confirm no anomalies. The house edge is flat at 0.1% — no scaling structure.
Sections 1–4 prove the game is mathematically fair. Section 5 proves the implementation maintains integrity under non-standard conditions. We applied 16 fairness integrity tests covering nonce integrity, seed commitment, outcome determinism, cross-player isolation, and payout integrity (including Mines-specific multi-step game-state checks). All 16 tests passed, including one Mines-specific multi-step state integrity test.
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 mine counts or grid sizes be submitted?
- Mines-specific — can the same tile be revealed twice to advance the multiplier?
What This Means for You
- Across the 16 tests we ran, no API path allowed outcomes to be altered, replayed, or injected — by player or casino
- Once a bet is placed, the mine layout 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 130 primary epochs |
| Seed commitment integrity | Pass | Locked at bet acceptance, unique per epoch — 130/130 primary epochs verified |
| Outcome determinism | Pass | Identical inputs produce identical mine sets — 7,050/7,050 confirmed including multi-reveal |
| Round & player isolation | Pass | Per-user seeds, serial independence confirmed (0/24 fail in 24M-round simulation) |
| Payout integrity | Pass | Parameter limits enforced (5/5 invalid mineCount rejected); injected payout fields ignored (0 honoured); duplicate-reveal advancement blocked |
16 fairness integrity tests: all 16 pass, including one Mines-specific multi-step state integrity test.
Every Mines outcome can be independently reproduced using publicly disclosed inputs. No hidden variables, no private backend data. If your calculated mine layout 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 Mines outcome can be independently reproduced
- No hidden variables — no private backend data
- If your computed mine SET 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; increments within each epoch)
- Mine Count — the number of mines you chose for the round (1–24)
Only disclosed inputs are used. Identical inputs always produce identical output.
Choose your mine count (1–24) for the 25-tile grid and place a bet. The platform locks the mine layout using the provably fair backward Fisher-Yates shuffle. The server has already committed to the outcome before you clicked — you just don't know which tiles are mines until you start revealing.
Duel.com Mines — 25-tile grid with mine-count selector. Mine placement is locked before you reveal any tile.
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 Mines 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 mine positions from the disclosed inputs and renders the Game Result inline as a 25-tile grid. If the recomputed mine set 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 mine set 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-mines
- Commit: 6927bec239024666a22a4767ec5c28461a857063
- Game: Mines (duel-mines)
- 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, datasets, and commands above. The dataset hashes ensure you're running against the same 7,050 bets.