Play on Duel

Verification · Runs locally in your browser

Check any bet you have placed.

Every Duel Original lets you prove a round wasn’t rigged. Duel shows you a locked-in hash before you bet, you supply half the randomness yourself, and afterwards you can recalculate exactly what should have happened. Paste your seeds in below and this page does the maths — nothing leaves your browser.

HMAC-SHA256 verifier

What the verifier is doing

Paste in a revealed server seed, your client seed and the nonce of the round you want to check. It then works out the result the same way Duel does:

  1. Compute HMAC-SHA256(key = server seed, message = "clientSeed:nonce" — plus :cursor for any game needing more than one number).
  2. Take the first four bytes of the digest as a 32-bit decimal.
  3. Reject it if it lands at or above that game’s threshold, and try the next four bytes.
  4. Reduce the accepted value modulo the result space — for Dice, value % 10001 ÷ 100.

Why some numbers get thrown away

A 32-bit number doesn’t divide evenly by 10001, so using every value would make low rolls very slightly more likely. Duel throws away anything above the largest clean multiple — ⌊2³² ÷ 10001⌋ × 10001 = 4,294,959,453 — which removes that bias entirely. Each game has its own cut-off, all built the same way:

  • Dice — modulus 10001, threshold 4,294,959,453
  • Blackjack — modulus 52, threshold 4,294,967,248
  • Mines & Keno — moduli 25 and 40, threshold 4,294,967,275
  • Beef — modulus 20, threshold 4,294,967,280
  • Plinko — none needed; a parity check splits 2³² exactly

If the number the tool produces matches the number Duel showed you, that round was determined by the seeds and nothing else.

Crash and Castle Roulette work differently. Those two do not use your client seed at all — they mix Duel’s server seed with a value from the public drand randomness beacon, with the nonce fixed at 0. You cannot reproduce them offline from a seed pair, which is why they are not in the verifier above. In exchange you get a stronger guarantee — see below.

The scheme

Commit, play, reveal, check.

The whole design rests on one idea: the operator has to publish an unbreakable promise about the outcome before it knows anything about your bet.

01

Commit

The server generates a random seed and publishes SHA-256(seed). A hash is one-way: it reveals nothing about the seed, but any change to the seed changes the hash completely. The promise is now locked.

02

Contribute

You set a client seed. The result depends on both seeds, so the server cannot have chosen its seed to engineer a specific outcome — it committed before it knew yours.

03

Play

Each bet increments a nonce. The seed pair plus nonce feed an HMAC, and the digest deterministically produces the round. Same inputs, same result, every time.

04

Reveal

Rotate your seed. The old server seed is disclosed. Hash it and compare to the commitment from step one — a match means every round in that batch was fixed before you bet.

Duel runs two schemes, not one

Seed pair covers Dice, Mines, Plinko, Keno, Blackjack, Video Poker and Beef — your client seed is half the input, and you can recompute rounds offline once the server seed is revealed.

drand beacon covers Crash and Castle Roulette. Duel commits to a drand round ID before that round's randomness exists anywhere in the world, so the result cannot be known or chosen by either side — but your client seed plays no part, so you verify against the public beacon instead of offline.

What it rules out

Outcomes adjusted after the bet lands. Results that react to your stake size, your balance, or how far ahead you are. Selective re-rolling of a round the house does not like.

What it does not rule out

A paytable that is simply bad — provable fairness says nothing about the payout you are offered, which is exactly how a documented 0.1% constant sits inside a "0% house edge" product line. It also says nothing about limits, withdrawals or the operator as a business.

FAQ

Provably fair, answered.

What does provably fair actually prove?

That the result of a round was fixed before you bet on it, and that the operator could not have changed it afterwards. It does not prove the paytable is generous or that the odds are good — those are separate claims. It proves the dice were not loaded mid-throw.

Why does the client seed matter if the server picks the server seed?

Because the outcome is a function of both. The server commits to its seed before it knows your client seed, so it cannot search for a seed that produces the results it wants. Remove your half and the commitment scheme collapses.

When should I rotate my seed?

Whenever you want to audit. Rotating reveals the old server seed so you can verify every round it produced, and starts a new commitment for the next batch. Many players rotate at the start of each session as a matter of habit.

Is the verifier on this page sending my seeds anywhere?

No. It runs entirely in your browser using the Web Crypto API built into the browser itself. There is no network request, no analytics on the inputs, and the page works offline once loaded.

Does provably fair mean the casino is regulated?

No. It is a cryptographic property of individual game rounds, not a licence, an audit, or any guarantee about solvency or withdrawals. Treat it as one input among several, not as a substitute for due diligence on the operator.

Verify before you trust

Rotate your seed, then check a round.

Open the fairness panel, set your own client seed, play a few rounds, rotate, and paste the revealed seed into the verifier above.

18+. Wagering requirements apply. Terms set by the operator and subject to change.