Why your provably fair replay doesn’t match

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.

Sources & references

  1. ProvablyHero engine: supported algorithms, seed encoding and evidence scope
  2. Stake: documented seed, nonce and cursor inputs

FAQ

The verifier matches for one bet but not the next. Why?

Check the exact recorded nonce, seed pair and algorithm variant for each bet. Do not replace a saved nonce with a guessed count; other bets or counter conventions may affect it.

My hash matches but the result doesn't. What does that mean?

The seed matches the supplied hash under the selected encoding. Check the original client seed, nonce, settings and verifier version next. The hash match does not itself establish when the commitment was made.

Can a casino make a replay mismatch on purpose?

A confirmed mismatch may expose inconsistent inputs or execution, but it does not by itself establish intent. A manipulated selection process can also produce matching replays, so commitment timing is a separate question. See Same replay, different evidence.
  • Same replay, different evidence: why commitment timing matters A matching replay checks supplied inputs. See why a full pre-bet seed commitment and its timing matter, with a reproducible Dice example.
  • How to record a bet you can actually check What to save before, during and after a provably fair bet: the full commitment, seed-pair context, nonce, settings and recorded result.
  • Provably fair, explained and checked What provably fair means, which crypto casino algorithms we have checked, and how to verify a Plinko or Dice bet with revealed seeds and nonce. Free.
  • Commitment A commitment is a hash that fixes a secret server seed without revealing it. After disclosure, the seed can be checked against that hash using the required encoding.
  • Replay A replay recomputes a recorded result from the supplied inputs under a selected game algorithm. It may need seeds, a nonce, a cursor, a version or other game data.