Executive Summary
ProvablyFair.org conducted an independent audit of the 10 provably fair games Duel.com operates in-house between March and May 2026, with certification granted in June 2026. All 10 games met the framework's certification criteria.
These conclusions are not assertions. Each game is independently rebuilt from its published specification — not from Duel's source code. An executable test suite then runs every live result against that rebuild. Certification required a pass in every area, for every game; a failure in any single area would have prevented it. Each game is verified across five areas:
Coverage scales with the game, from 15 scored checks to 33, and the suite fails the run if a single check diverges. The suite, datasets, and verification code are published open-source, re-runnable and inspectable by anyone.
Duel advertises these games at 100% RTP. This audit measures the return produced by each game's logic, the part anyone can reproduce from seeds, which comes to between 99.2% and 100% depending on the game, exactly as the published mechanics define. Duel attributes the remainder to an instant rakeback credited at the account level.
That rakeback sits outside the cryptographic layer, so this audit does not measure or confirm it; the 99.2–100% is game-logic RTP and does not include any rebate. What this certification establishes is that each game's logic pays exactly what its rules define, and that figure is mathematically correct and independently reproducible.
ProvablyFair.org captures Duel's live outcomes and re-derives every one independently.
Provable fairness requires that any third party can take an operator's published inputs and arrive at the same outcome the player saw. This audit tests exactly that — independently, for every game and every captured bet.
Scope of Certification
This certification covers the cryptographic and statistical correctness of game outcomes in Duel's in-house provably fair games. It does not extend to other aspects of the platform. Both boundaries are stated below.
Games covered: 10 games, all built and operated in-house by Duel — Plinko, Dice, Mines, Keno, Beef, Crash, Castle Roulette, Video Poker, Blackjack, and Groomer's Van. Third-party or licensed titles available on Duel.com are not Duel's own implementations and are outside the scope of this audit.
- Provably fair RNG logic and entropy architecture
- Deterministic reproducibility of every audited bet
- RTP mathematical correctness from first principles
- Commit-reveal chain integrity across seed rotations
- Round, player, and seed-session isolation
- Payout integrity within the audited game logic
- Operator solvency, treasury, or wallet custody
- Regulatory licensing in any jurisdiction
- Infrastructure or server-side security posture
- Cross-account outcome consistency — not assessed in this audit
- Max-win cap enforcement at payout time — platform-level, not game logic
- KYC, AML, responsible gambling controls
- Rakeback and promotional programs — operator-side, outside the audited game logic
What Was Tested, and How
Each audit answers five questions, applied independently to every game in scope.
We rebuilt each game from its published specification in an independent implementation. Re-running an operator's own code only establishes that the operator is internally consistent; rebuilding from the stated specification tests whether the live game matches what is publicly claimed. Live bets were captured through anonymous accounts, every game's audit was independently reviewed before finalisation, and every dataset, result, and line of verification code is published open-source. The complete framework, including per-section pass criteria, is documented on the methodology page.
Entropy Architecture
Duel's 10 games do not share one randomness construction. They split across three cryptographic architectures, because three game structures need three different ways of supplying unpredictable input. The seven single-player games pair a server seed with a player-supplied client seed — the appropriate construction wherever one player faces the house, since the player contributes an input the operator cannot predict.
The two live-multiplayer games, Crash and Castle Roulette, cannot use a client seed: every player in a round shares one outcome, so no single player's seed can drive it. They bind a drand public beacon instead — external entropy no party can forge or withhold. Groomer's Van, a cluster-pays slot, consumes far more randomness per spin than one HMAC output provides, so an HMAC-SHA256 output seeds a PCG32 stream that expands it to the length the game needs.
Construction. Server commits SHA-256(serverSeed) before client seed is supplied. Outcome = HMAC-SHA256(serverSeed, clientSeed:nonce) with rejection sampling for unbiased draws.
Construction. Live multiplayer rounds replace the client seed with a drand quicknet beacon round (publishes every 3 seconds, signature-verifiable). Server commits before the beacon round publishes.
(serverSeed, drandRandomness) · bet timestamp preceded beacon publication on every captured round · beacon signature re-verified against drand public key.Construction. HMAC-SHA256 output seeds a deterministic PCG32 stream (via SplitMix64 expansion). PCG32 supplies bytes for every weighted reel draw, cascade, and bonus session. Full spin reproducible from the original seed pair.
Each architecture was rebuilt and verified independently against its own captured live bets. For the client-seed games, the audit confirmed the client seed is genuinely consumed — bets reproduce under auditor-supplied seeds and diverge under a tampered one. For the drand games, it confirmed the beacon value genuinely enters the outcome computation — not merely that it is present — that every bet was recorded before its beacon round published, and that each beacon signature re-verifies against the public drand chain. For Groomer's Van, it confirmed the full PCG32 stream reproduces from the seed pair.
Results
Across all 10 games, the independent implementation reproduced every one of the 53,475 captured live bets exactly, with no conditional divergence, rounding drift, or fallback path. Parity was checked at the natural granularity of each game — intermediate card order, reel positions, and cascade states, not only the final win or loss. Because every captured bet recomputes exactly from its disclosed inputs, the reconstruction surfaced no hidden entropy inputs, fallback paths, or conditional RNG branches in the audited implementations; in every construction the random value is committed before the player's input is known.
RTP was established independently for each game — by closed-form derivation, exhaustive enumeration, or exact convolution, depending on the game — and corroborated by Monte Carlo totalling 253M rounds across the suite. Anti-circularity was enforced: every derivation and simulation operates from the published game specification, not from operator-supplied RTP figures or simulation output.
win_chance × multiplier = 0.999 for all targets, verified algebraically.B(rows, 0.5) against the payout table across all 27 risk/row configurations.P(hits) against payout multipliers across all 40 configurations.C(52,5) = 2,598,960 five-card hands, cross-validated against the published 9/6 Jacks or Better baseline.P × multiplier = 1.000 exactly.Empirical RTP converged on the independently derived theoretical value within statistical tolerance for every game. The per-game breakdown — RNG model, live bet count, simulation volume, observed RTP, and derived RTP — is presented in the Dashboard game validation matrix.
Findings
The audit applied 151 game integrity checks across the 10 games — a fixed matrix of adversarial probes including replay attempts, parameter injection, parallel-request races, malformed payloads, and seed and nonce tampering, with game-specific extensions for surfaces such as Blackjack's split actions and Groomer's Van's bonus-buy endpoint.
The checks group into five integrity categories
- Nonce integrity — monotonic, server-controlled, no gaps or duplicates.
- Seed commitment lifecycle — commit-reveal chain intact across rotations; revealed seeds match commitments.
- Outcome determinism & replay resistance — identical inputs → identical outcomes; bets cannot be replayed for duplicate payout.
- Round & player isolation — no cross-player or cross-round state leakage.
- Payout & parameter enforcement — payouts match published table; server cannot silently override bet parameters.
Four findings were recorded, all server-side input-validation flags: one on Video Poker, two on Groomer's Van, and one on Crash. All four share one root cause — Duel's API accepts certain malformed or out-of-bounds requests where stricter validation would reject them: in the Video Poker and Groomer's Van cases the server returns an HTTP 200 to a malformed payload, and in the Crash case the auto-cashout multiplier has no enforced upper bound (values above the theoretical maximum crash point are accepted). In every case the cryptographic core, RNG, RTP derivation, and payout logic operated correctly; no finding affects outcome determinism, RTP, or payout integrity, and no fairness failure was recorded. All four were disclosed to Duel.com, with reproducible probes documented in the corresponding per-game audit's Section 5.
What This Audit Establishes for Players
For the 10 in-house games covered, this audit establishes what a player can rely on.
- A game's outcome is cryptographically locked before a bet is placed and cannot be altered afterward.
- The randomness comes from an input the operator can't control — a seed the player provides, or a public randomness beacon — so the outcome is not generated from the operator's input alone.
- The house edge a player is shown is the figure independently derived from the game's published rules, not an estimate supplied by the operator.
- Every captured outcome was reproduced, bet for bet, by an independent implementation — every audited result is provably identical to the live game that produced it.
- Any single result can be recomputed by anyone from its public inputs. A player does not have to trust the operator, this audit, or ProvablyFair.org — only the math.
Across the 10 games, the audit ran a scored verification suite per game and 151 integrity tests in total — tens of thousands of live bets reproduced, and 253 million simulated rounds.
Certification confirms these games are provably fair and operate as specified. It does not change what they are: a provably fair game is one that behaves exactly as its published rules state — not one a player is assured of winning. This audit verifies the games are what they claim to be; it does not eliminate variance, and it does not guarantee a profitable session.
Independence and Reproduction
This audit was conducted independently. Findings are binding and were not negotiated with the operator; the audit outcome does not depend on the result. The complete framework and every per-game audit are published open-source, so the audit can be examined and re-run by any third party rather than taken on assertion.
Residual Risk and Assumptions
Certification reflects the integrity of the audited implementation as deployed during the review period. Three assumptions sit beneath that result:
- Code-to-deployment parity. The production binary is assumed to match the audited implementation. Each per-game repository pins the exact commit the audit was performed against.
- drand availability. Crash and Castle Roulette assume the drand quicknet beacon remains operational and signature-verifiable.
- Operator-published parameters. Reel weights, payout tables, and rule sets are taken as published. Silent changes would invalidate the RTP and integrity guarantees.
This certification reflects the 10 in-house games as audited at the commit hashes recorded in each per-game repository. Material changes to a game's RNG construction, payout tables, or logic require revalidation; pinned commit hashes make any such change verifiable against the audited baseline. Certification is maintained through periodic spot checks and a full annual re-audit. Next scheduled review: June 8, 2027.
Each game has its own audit page carrying the complete methodology, datasets, simulation logs, and verifier code for that game. See the sidebar for individual reports, or the Dashboard for the cross-game validation matrix.