Record the full commitment before play, then choose a fresh, independently generated client seed while that same commitment remains active. Save the bet’s exact inputs and result. After disclosure, check the commitment using the operator’s seed encoding and replay the bet.
Why the order matters
A verifier can only work with what you give it. If you only start collecting inputs after something looks wrong, your record does not establish that the commitment was available before play. See Same replay, different evidence for why a hash first seen after the bet supports a much weaker claim.
The routine
Before the first bet
- Open the fairness settings and record the full active server-seed commitment before choosing the client seed or placing a bet. For SHA-256 this is all 64 hexadecimal characters. Save the operator, game and exact seed-pair context too.
- Choose a fresh, independently generated client seed after recording that commitment. A familiar phrase or reused seed may be predictable; choosing it yourself is not enough to rule out server-seed preselection.
- Check that the same commitment remains active. Some client-seed edits also replace the server seed. If that happens, the old hash does not establish an early commitment to the new pair. Save the new hash and document the actual order; do not claim the stronger ordering unless the operator’s workflow supports it.
- Store it somewhere with its own timestamp. A note, a message to yourself or a file all help you reconstruct events. None of them is independent proof of when you saw the hash, so keep the original rather than retyped copies.
While you play
- Record any bet you might want to check: nonce, result, payout, bet amount and game settings (risk level, row count, target or mode, depending on the game).
- Keep each bet’s settings with its record. You may change settings between bets; replay each bet with its original configuration. In balanced Plinko, risk changes payouts, while row count changes the path length. Dice target changes the winning condition rather than the generated roll.
When you want to verify
- Use the operator’s disclosure or rotation controls. Find the revealed old server seed associated with the bet’s recorded pair. Do not substitute the new active seed hash or assume a client-seed edit alone reveals the old seed.
- Compare first, then replay. Check the full saved commitment using the operator’s required seed encoding. Some hash the visible seed text; Duel.com hashes decoded hex bytes. Then replay the exact inputs, nonce, algorithm version and any additional required data in the matching verifier.
- Save the new commitment before the next bet. Record which pair it belongs to, then check the client-seed ordering again. A capture after your client seed was already known does not rule out earlier preselection.
What to keep for each checked bet
| Item | Why it matters |
|---|---|
| Full server seed hash, saved before play | The commitment. Without it, a match can't speak to seed substitution. |
| Revealed server seed | The disclosed secret input; its encoding and role depend on the algorithm. |
| Client seed, exact spelling and case | Part of every result. One changed character changes everything. |
| Nonce | Picks out the exact bet. Use the recorded value; do not infer it from the current counter. |
| Game and settings | Identifies the result mapping, winning condition and applicable payout rules. |
| Result and payout | What you're checking the replay against. |
| Operator and date | Algorithms and tables can change. Note which version applied. |
What this routine still doesn't prove
- That every bet you didn't check was generated the same way.
- That the payout was settled correctly to your balance.
- Anything about withdrawals, licensing or the operator's finances.
The strength of the evidence depends on the authenticity and timing of your record, the supported algorithm and the exact comparison performed. A matched replay is a check of supplied inputs, not a certificate for a casino.
Key takeaways
- Save the full hash before the first bet, not after something looks odd.
- Choose an unpredictable client seed after recording the commitment, and confirm that the same commitment remains active.
- The nonce and settings matter as much as the seeds.
- Rotate to reveal, compare the hash, then replay.
