Duel Provably Fair: Server Seed, Client Seed and Nonce Explained
The in-house games use a provably fair model built around committed inputs. The practical idea is simple: a result should be reproducible from known data, rather than hidden behind a black-box result screen. This page explains the core terms, the verification logic and the limits of what the system can prove.
Important distinction: provably fair is not the same as 100% RTP. A provably fair losing round can still be perfectly fair. Fairness verification checks whether the result came from the committed inputs; RTP describes expected return over a large number of wagers.
What provably fair means here
In plain terms, the casino should not be able to secretly change a result after the bet is placed. The Duel Provably Fair model derives a result from pre-committed and player-visible inputs, and the player can then verify that result after the round.
Server seed
The server seed is the operator-side input. In a proper flow, the player sees a commitment to this seed before the result, then later checks that the revealed seed matches that commitment.
Client seed
The client seed is the player-side input. Letting the player set or influence this value helps stop the result from depending only on data chosen by the operator.
Nonce
The nonce is a round counter. It keeps repeated wagers from using the exact same input set, so each result can be tied to a specific round in the seed sequence.
The verification flow
The exact display varies by game, but the Duel Provably Fair audit pattern is the same: commit first, resolve the round, then reveal enough data for the player to reproduce or check the result.
The simplified result formula
Duel publicly summarises the fair-result inputs as server seed, client seed and nonce. This page keeps it high-level: the plus sign is shorthand for a cryptographic combination of those inputs, not literal addition, and each game maps the result into outcomes differently.
Fair result = Server seed + Client seed + NonceThe combined value is mapped into a dice roll, crash point, mine layout, plinko path, card deal, wheel-segment result or slot outcome.Whether the revealed inputs recreate the same result shown in the completed round.What it can and cannot prove
This distinction matters. Duel Provably Fair is a transparency mechanism, not a winning system.
| Question | Can it answer this? | Explanation |
|---|---|---|
| Was this result generated from the published inputs? | Yes | That is the main purpose of the check. |
| Could the casino secretly change the result after the bet? | It should expose that | If the revealed server-side input does not match the prior commitment, the check should fail. |
| Will the next round be a win? | No | It does not predict future outcomes. It verifies completed or committed randomness. |
| Does this remove volatility? | No | A fair random result can still be unfavourable, and losing streaks still happen. |
| Does this prove 100% RTP? | No | RTP and fairness answer different questions. RTP needs payout and probability analysis. |
| Does this prove that a strategy works? | No | A strategy can be applied to a fair game and still have no predictive edge. |
Editorial rule for this site: do not publish game-specific verifier code or exact result-mapping assumptions unless they have been checked against the current Duel interface. High-level seed logic can be explained safely, but each game may map randomness into outcomes differently.
How verification differs by game
The seed model is shared across the Originals, but the output is not identical. A dice roll, a mine layout and a blackjack hand are different kinds of outcomes, so the Duel Provably Fair check reads differently for each.
Dice →
The combined value maps into a roll or target-number result. Dice is the simplest page for explaining single-number verification.
Crash →
The result maps into a crash point. The verification question is whether that point came from the committed inputs.
Mines →
The values map into a hidden tile layout. Verification can check the layout after the round, but it cannot identify safe tiles before play.
Plinko →
The path maps into a final multiplier bin. Rows and risk settings change the distribution, not the basic verification principle.
Keno →
The output maps into drawn numbers. Verification should prove the draw, while return still depends on the paytable.
Blackjack →
Cards need sequential randomness. The fairness check is separate from whether the player followed an optimal decision strategy.
Video Poker →
Verification should cover the dealt and drawn cards, while the practical return depends on paytable and draw decisions.
Castle Roulette →
A live multiplier wheel (game-show style, not classic roulette). The result maps to a wheel segment; fairness here is operator-stated, so in-round verifiability is the thing to confirm.
Groomer’s Van →
A slot-style original needs a different explanation: result generation, feature triggering, volatility and the max-win cap should be kept separate.
Common verification mistakes
Most misunderstandings come from treating fairness data as a prediction tool. It is better understood as an audit trail.
“The seed can show the next result.”
Seed data should not be treated as a forward-looking signal. A proper verification process audits committed or completed outcomes, not profitable future plays.
“A fair loss is suspicious.”
A fair game can produce a losing result. The check asks whether the result was generated correctly, not whether the player liked the outcome.
“Provably fair equals zero edge.”
Separate concepts. A game can be provably fair and still carry a house edge. A game can be promoted as zero edge and still carry variance.
“All games verify the same way.”
The seed inputs can be similar, but the mapping from randomness to visible result differs between dice, mines, plinko, crash, cards and slot-style games.
Independent-site notice: DuelOriginalGames.com is not Duel.com and is not operated by or affiliated with Duel. This page is technical education only. It is not gambling, legal or financial advice, and it provides no prediction systems or methods for manipulating game outcomes. Gambling carries financial risk, may be restricted where you live, and is for adults only.
Common fairness questions
Short answers to the main questions about Duel Provably Fair verification.
What does provably fair mean?
It means a player can verify that a result was generated from committed inputs rather than trusting a hidden black-box result. In Duel’s public wording, the main inputs are a server seed, a client seed and a nonce.
What is a server seed?
The server seed is the operator-side input. A proper flow commits to it before the result and later reveals enough information for the player to check that the same committed value was used.
What is a client seed?
The client seed is the player-side input. It helps ensure the result is not based only on a value chosen by the operator.
What is a nonce?
The nonce is a round counter. It changes from one wager to the next so repeated rounds do not use the same exact input set.
Does provably fair mean I will win more often?
No. It does not increase win frequency, reduce volatility or create a player edge. It only helps verify how a result was generated.
Is provably fair the same as RTP?
No. RTP describes expected return over many wagers. Fairness verification checks whether a specific result came from committed inputs.
Can provably fair predict Mines safe tiles or Crash multipliers?
No. Treating fairness data as a prediction system is a mistake. It is an audit mechanism, not a tool for knowing future outcomes.
Why do different games need different fairness explanations?
Because the same input concept maps into different result types. Dice maps to a number, Mines maps to a grid layout, Plinko maps to a path and bin, while card and slot-style games need more complex result handling.