Duel Provably Fair: How to Verify Any Round Yourself

The short answer

Yes — Duel Originals are provably fair, and you can check it in about three minutes without any technical background. Before you bet, Duel shows you a SHA-256 hash of a secret server seed. That hash is a commitment: it fixes the outcome in advance. After you rotate the seed, Duel reveals the original seed, and you re-hash it yourself. If the hash matches, the outcome could not have been altered after you placed the bet.

What that does not cover is everything outside the round itself — the license, whether your balance is segregated, whether withdrawals actually pay. Those are different questions, and we get to them at the bottom of this page rather than letting "provably fair" stand in for them.

The only window where tampering could occur is between steps 1 and 3 — which is exactly the window the hash closes.

What provably fair actually proves

It proves one narrow, valuable thing: the outcome existed before your bet did. A cryptographic hash is a one-way fingerprint — you can compute the hash from a seed instantly, but you cannot work backwards from the hash to the seed, and you cannot find a second seed that produces the same hash. So when Duel shows you a hash before the round and a seed after it, and the two match, the casino has demonstrated it was locked into that seed the whole time.

Concretely, this rules out the failure mode players actually worry about: a house that watches your bet size, then picks a losing result. It cannot happen inside a valid commitment, because the commitment was published before the bet existed.

What it does not prove — the part most guides skip

Being straight about the limits is what makes the check worth anything.

• It doesn't audit the odds. A provably fair game can be provably fair and still pay badly. The commitment proves the result wasn't tampered with; it says nothing about whether the payout table is generous. RTP and house edge are a separate claim — that one is covered in Zero Edge.
• It doesn't cover seed selection. The commitment binds the operator from the moment it's published — not before. This is exactly why you should set your own client seed rather than accepting the auto-generated one: your input is mixed into every result and is chosen after the server seed is committed.
• It doesn't apply to third-party slots. The several thousand slot titles on Duel run on their providers' RNGs. Only Duel Originals — Crash, Dice, Plinko, Mines, Blackjack, Castle Roulette — go through this system.
• It doesn't touch solvency. Verified rounds on an operator that can't pay out are verified rounds you can't withdraw. See license and safety for that half of the picture.

How to verify a Duel round, step by step

Six steps. You need nothing but a browser.

1. Set your own client seed first. Open the fairness panel and replace the auto-generated client seed with something you chose — a word, a date, anything. This is the single step most players skip, and it's the one that closes the seed-selection gap described above.
2. Copy the hashed server seed. That string is the commitment. Paste it somewhere outside the casino — a notes app is fine. Copying it after the fact proves nothing.
3. Play, and note the nonce. Every bet on that seed pair increments the nonce: 1, 2, 3. Write down the nonce of the round you want to check.
4. Rotate the server seed. Rotation is what triggers the reveal — the previous seed is only unmasked once it can no longer be used. Duel then shows you the unhashed seed.
5. Hash the revealed seed. Paste it into any SHA-256 tool. The output must match the hash you saved in step 2, character for character. A mismatch would be the actual scandal; a match means the commitment held.
6. Re-derive the outcome. Feed the server seed, your client seed and the nonce into a third-party provably-fair verifier, or follow the per-game algorithm in Duel's own fairness documentation. The number it produces should be the number you were paid on.

We ran this on five separate Originals rounds during testing for our full review, and the hashes matched every time. That's a sample of five, not an audit — but it's five more than most sites reporting on this have run.

A worked example you can reproduce right now

Nothing below is a screenshot you have to trust. These are real values — paste any of them into a SHA-256 or HMAC tool and you will get the same output we did, which is the entire point of the system.

Reproducible: hash the server seed yourself and you get the published hash; run the HMAC and you get the same digest, every time, on any machine.

Two things are worth pulling out of that. First, the published hash is derived from the server seed and nothing else — so a casino that swapped the seed after seeing your bet would produce a hash that no longer matches what it showed you, and the mismatch is instantly visible. Second, your client seed goes into the HMAC message, which is why changing it changes every subsequent result: you are an input to the outcome, not a spectator.

This is the standard construction used across this family of implementations. The per-game step at the end — converting that float into a dice roll, a Plinko path or a mine layout — differs by game, and Duel documents its own conversion in the fairness panel. We could not access Duel's live documentation from our testing location to transcribe each game's exact formula, so treat the final conversion as game-specific and check it in the panel; the commitment and HMAC steps above are what actually carry the guarantee.

Crash works differently: the drand beacon

Per-player seed pairs work for single-player games, where only your bets consume the nonce. Crash is multiplayer — everyone in the round shares one outcome — so a per-player seed doesn't fit. Per Duel's own fairness documentation, Crash settles against the drand beacon run by the League of Entropy: a distributed randomness network operated by a consortium of independent organizations, publishing a fresh public random value on a fixed schedule.

A live Crash round during our testing. Note the Zero Edge and Provably Fair badges in the bottom corners of the game panel — both are surfaced in-game rather than buried in a terms page. Screenshot, June 2026.

The practical implication is stronger than the standard model, not weaker. With a seed commitment, you're verifying that the operator kept a promise it made to itself. With drand, the randomness comes from outside the casino entirely — Duel isn't a participant in generating it, so there is no promise to keep and nothing to select in advance. We haven't independently reproduced a Crash settlement against a specific drand round, so treat the mechanism as documented-but-unverified by us; the seed-based verification above is the part we've actually run.

"I lost twelve in a row — it must be rigged"

This is the most common reason people land on a page like this, so it's worth answering directly. Twelve losses in a row on a near-coinflip bet happens roughly once every 4,000 sequences. If a few thousand players each place a few hundred bets a night, it happens to somebody every single night, in a perfectly fair game. Streaks are what randomness looks like from the inside; a distribution with no streaks would be the rigged one.

The useful response isn't to argue about it — it's to check. Take the seed pair from the session that felt wrong, rotate it, and verify three or four of those specific rounds. Either the hashes match, in which case the streak was a streak, or they don't, in which case you have something concrete and reportable rather than a feeling.

Where this fits in the bigger safety picture

Duel operates under an Anjouan gaming license (ALSI-202411026-FI1) through Immortal Snail LLC, registered in Nevis. That's a lighter-touch tier than an MGA or UKGC license, with no mandated player-fund segregation and no binding dispute resolution. We also haven't found a published, named third-party RNG audit for the platform.

Provably fair verification is what partly offsets that: it hands you a check that doesn't require trusting a regulator, an auditor, or the operator. But it offsets one specific risk, not all of them. The full trade-off — licensing, KYC thresholds, what happens to balances if the platform stops operating — is laid out in our license and safety breakdown, and the payout side is in deposits and withdrawals.

FAQ