A mismatch alone does not identify the cause. Check the commitment, recorded seed pair, nonce, exact seed text, game settings and verifier version. A commitment mismatch and a result mismatch are different findings; either can be worth investigating once the inputs and record are confirmed.
Check 1: does the hash match?
Check the revealed seed against your full saved commitment using the operator’s required encoding. Many adapters hash seed text; Duel.com decodes hex into bytes before SHA-256. A generic text-hash tool can therefore disagree with a correctly implemented verifier.
- Hash matches: the seed is consistent with the supplied full hash. A pre-bet commitment claim also depends on when and how you recorded that hash. Continue with the result checks.
- Hash does not match: check the seed pair, full copied hash and seed encoding first. If those are confirmed and the mismatch remains, preserve and report it; a failed commitment check is itself relevant evidence.
- No saved hash: you can still replay the supplied inputs, but the check cannot establish consistency with a commitment you recorded before play.
Check 2: is it the right seed pair?
Every rotation starts a new pair. A bet can only be replayed with the server seed and client seed that were active when it was placed. The values shown in settings now are usually not the ones for an older bet. Find the bet in your history and use the pair listed with it.
Check 3: is the nonce exact?
A wrong nonce selects a different calculation. Check it against the original bet record.
- Use the nonce recorded with the bet, not the current counter.
- Operators differ on whether the first bet uses 0 or 1. An off-by-one error gives a completely different result.
- A rotation may restart the counter; follow the operator’s documented convention. The same nonce value can appear under different pairs, so the nonce alone does not identify a bet.
Check 4: is the client seed character-perfect?
Spelling, case, spaces and invisible characters all count. “Anthony”, “anthony” and “anthony ” (with a trailing space) are three different seeds. Copy and paste rather than retyping.
Check 5: are the settings the same?
Enter the original game variant and settings. Row count changes a Plinko path’s length; in balanced mode, risk changes the payout table rather than the path. A Dice target changes whether a roll wins, not the roll itself. Result, multiplier and settlement mismatches must be considered separately. ProvablyHero currently replays supported Plinko and Dice schemes; other games require their own matching tools.
Check 6: is it the right verifier?
Operators implement the same idea differently: how the message is built, how bytes become a number, which conversion constant is used, and how seed text is encoded. A Stake verifier won't reproduce a BC.Game bet. Choose the matching operator, game and algorithm version. Reference means the implementation lacks the equivalent captured-round and saved-commitment evidence required for our Verified label; it can still have published examples or constructed tests. Read the individual scope. Duelbits Plinko currently calculates a reference ticket, not a validated path, slot or payout.
If everything checks out and it still doesn't match
If confirmed inputs still produce a commitment mismatch or a different recorded result, preserve the exact comparison and report it. That's worth reporting, but keep the claim narrow:
- What you can say: this verifier, with these inputs, produces a different result from the one recorded.
- What you can't say yet: that the casino manipulated it. The operator may have changed its algorithm, or the verifier may have a gap.
You can send the page link, algorithm version, exact nonce, recorded result and already disclosed seed inputs to the operator’s support and us. Include the original commitment record and its timing context if available. Never send an active secret server seed, passwords, account access or raw captures containing credentials. Inputs are not submitted automatically by our verifiers.
Key takeaways
- Check the full hash using the operator’s seed encoding; record whether it was saved before play.
- Check the original seed pair and nonce before drawing a conclusion.
- Seeds are case- and space-sensitive.
- Each operator needs its own verifier.
- A confirmed mismatch is a reason to report, not yet a verdict.