A matching replay shows that the supplied inputs reproduce a result under the selected algorithm. It does not establish when the server seed was committed or how the casino actually generated the recorded bet.
What a matching replay actually shows
You ran a verifier and the roll matched. That is useful evidence, but what exactly has been checked? An operator-specific verifier can recompute the outcome from the revealed server seed, client seed, nonce and any other required inputs. If you supply an expected commitment, it can also check the revealed seed against that hash. A match establishes consistency under that algorithm; it does not independently establish the inputs or process used by the casino.
There is no universal three-input formula. Some games also need a cursor, algorithm version or other game data. Seed encoding matters too: hashing the visible seed text is different from decoding hex into bytes first. Choose the matching bet verifier, and distinguish “commitment matched” from “no expected hash supplied”.
The same calculation, two different evidence records
| Input or derived value | Value |
|---|---|
| Revealed server seed, treated as UTF-8 text | a3f1c9e2b7d4058e6f1a2b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e6f70 |
| SHA-256 of that seed text | 15635c156e0ad421716072fd604bfc21e2011287f7abadaf2560052d42f5d851 |
| Client seed | anthony-test-01 |
| Nonce | 7 |
| HMAC message | anthony-test-01:7:0 |
| HMAC-SHA256, server-seed text as key | eb539d7cf65309c69150718153a348fe6f44ae4bb1b4103ab5a1d0ab95f323e6 |
| First four bytes | 235, 83, 157, 124 |
| Unsigned big-endian 32-bit word | 3,948,125,564 |
| Fraction: word ÷ 2^32 | 0.919244616292417 |
| Supported Stake reference roll | 91.93 |
The first four bytes give 235/256 + 83/256² + 157/256³ + 124/256⁴. Multiplying that fraction by 10,001, taking the floor and dividing by 100 produces 91.93. Our Stake Dice verifier reproduces it. The same text seeds and nonce in the supported BCH.games scheme use a 10,000-value conversion and produce 91.92 instead. This is why the algorithm must be named.
| Evidence question | Player A: stronger timing record | Player B: hash first obtained after play |
|---|---|---|
| What was saved? | The complete 64-hex-character commitment, exact seed-pair context and a record of its timing. | A full hash copied from the fairness page after the session. |
| Order of events | The commitment is recorded before the player chooses a fresh, independently generated client seed, then places the bet. The same commitment remains active. | There is no independent record establishing what commitment was available before the bet. |
| Replay and hash check | 91.93; supplied full hash matches. | 91.93; supplied full hash matches. |
| What this supports | Subject to the authenticity and timing of the record, the disclosed server seed matches a commitment that predates the chosen client seed and bet. | The disclosed seed, supplied hash and replayed result are consistent. Pre-bet commitment timing is not established. |
Both calculations can match. The extra information comes from the saved record, not from the colour of the verifier result. Neither row proves that the casino is safe, every bet followed the same process, or the displayed payout was settled correctly.
Why the order of events matters
- The operator commits to a server seed by making its hash available.
- The player records that commitment and supplies a fresh client seed that was not known or predictable when the server seed was selected.
- The bet uses that seed pair and a recorded nonce.
- After disclosure, the player checks the full saved commitment and replays the exact inputs.
Under the security assumptions of SHA-256, finding a different seed with the same complete commitment is computationally infeasible. The commitment limits later seed substitution; it does not show that the initial seed was sampled honestly. If the operator already knew or could predict the client seed and relevant bet settings before selecting its server seed, a pre-bet hash alone does not rule out searching for a favourable seed beforehand.
If your first record of the hash is from after play, the record does not rule out seed selection after the other inputs were known. A matching replay would not expose that selection. This is an evidential gap, not evidence that manipulation actually occurred, and it does not imply that an arbitrary long recorded history could easily be fabricated.
Changing a client seed can also rotate the server seed at some operators. Check the actual sequence and which pair each hash belongs to. Saving the old hash does not establish an early commitment to a new server seed selected after your new client seed became known.
A clipped hash or screenshot is weaker evidence
The prefix 15635c15 contains only eight hexadecimal characters: 32 bits, rather than the full SHA-256 output of 256 bits. A seed matching that prefix has not thereby matched the entire commitment. Save all 64 hex characters. A prefix can be supporting evidence when its limitations are recorded, but it must not be presented as an equivalent full-hash check.
A screenshot timestamp or a message to yourself can help reconstruct events; neither automatically proves when the operator committed. Screenshots and some messages can be edited. Preserve the original record and its context. An independently verifiable timestamp or trustworthy external log can strengthen chronology, but its trust assumptions still need to be stated.
What to save before checking a bet
- The complete server-seed hash and the exact seed-pair or round context.
- The client seed, when it was chosen, and whether changing it also changed the server commitment.
- The bet nonce, algorithm version, game settings, recorded result and payout.
- A timing record with enough provenance to distinguish a pre-bet capture from a post-bet page.
- The old server seed after disclosure or seed rotation, checked using the operator’s required encoding.
Claim check
| Claim | What the evidence supports |
|---|---|
| “My replay matched, so the game was fair.” | Too broad. The supplied inputs reproduce the result under the chosen algorithm. |
| “The hash shown after play matches the revealed seed.” | Consistency with that supplied hash. It does not establish a pre-bet commitment. |
| “I saved the full hash before choosing an unpredictable client seed, and both checks matched.” | Stronger evidence against server-seed substitution for the recorded pair, assuming the record and its chronology are authentic. Not an overall fairness guarantee. |
| “My screenshot shows the first eight hash characters.” | A partial commitment record. Its scope must stay explicit; it does not check all 256 hash bits. |
A replay answers “do these supplied inputs reproduce this result?” The timing record addresses a different question: “was this server seed already committed before the other relevant inputs were known?” Read provably fair explained and our methodology for the distinction between replay evidence, payout calculations and their limits.
Next: how to record a bet you can actually check. If the supplied result differs, use why your replay does not match.
Sources & references
- Stake: published random-number generator, server seed, client seed and nonce
- Stake: Dice game-event conversion; the engine also documents captured floor rounding
- NIST: hash-function collision, preimage and second-preimage resistance
- ProvablyHero engine: operator adapters, evidence notes and reproducible tests
