Server seed, client seed and nonce are labels for inputs, not a universal guarantee of fairness. Their meaning depends on the game's protocol and version. This guide focuses on copying and interpreting those inputs correctly, including encoding, counter scope and seed rotation. It uses complete public test strings for an educational model. It does not ask for an active secret, promise a winning client seed or claim that every crash game requires a nonce.
1. Find the input specification before copying a seed
A server seed is an input contributed by the server side. In some systems its hash is shown before a wager and its original value is revealed later. That original value and its commitment are different fields. A 64-character string may be a displayed SHA-256 digest, hexadecimal seed text or something else. Length alone does not identify its role or prove 256 bits of random entropy. Copy the field label and the record's context along with the value.
The timing of disclosure also varies. A retired seed might be revealed after rotation rather than after every individual bet. Do not assume that logging out, playing a particular number of rounds or opening a generic history panel reveals it. Check the selected game's documented lifecycle. Without the revealed input, a retrospective reproduction may be incomplete. It is better to retain an unresolved field than to substitute a value from another round.
The public SPRIBE description and Stake implementation page illustrate different input systems. Our Aviator branch uses its separate SHA-512 calculation without a nonce. The educational HMAC model in this guide should not replace it, and a provider's general random-byte generator should not be mistaken for every game's final multiplier mapping.
| Input | Role in educational model | Do not infer |
|---|---|---|
| Server seed | Literal UTF-8 HMAC key | Entropy from displayed length |
| Client seed | Part of the message | Guaranteed unpredictability |
| Nonce | Nonnegative integer counter | New random entropy or unique multiplier |
2. A client seed is not a password or a profitable setting
A client seed is an input associated with the player side under the protocol. Some products allow editing it; multiplayer games may use multiple player inputs. Who supplies it, who can see it and when it becomes fixed must be documented. Do not infer that the client value is created only at the last instant or is unknowable to the server. A familiar word or personally chosen phrase is not automatically high-entropy randomness.
A client contribution can limit one party's ability to select outcomes only under the relevant commitment timing and unpredictability conditions. If the operator already knows all inputs while choosing among server candidates, merely naming one of them client seed does not prevent preselection. These are protocol conditions, not a finding that a particular operator selects seeds. A seed hash does not supply missing evidence about the generation process.
There is no validated winning client string here. Trying many public examples and choosing one whose past results look favourable is selection after observing outcomes, not a prospective edge. Changing a seed does not increase the return parameter of a fixed declared model. It can also change the record you need for reproducing a completed bet. Preserve the old pair identifier and historical inputs rather than overwriting them with current settings.
3. Understand what the nonce counts
In the educational model, nonce is a nonnegative integer included in the message clientSeed:nonce. An unchanged key and unchanged message give the same HMAC. Changing a counter is one way to change that message; using new per-round seeds is another. Therefore a nonce is not indispensable in every game. A deterministic public counter also does not supply new independent random entropy just because it increases.
Find the counter's scope and start value. It may belong to a seed pair, account or another documented grouping. A counter starting at zero is not the same input as one starting at one. A cursor used to select additional generated bytes is a separate parameter, not simply another name for the nonce. Do not add or remove either field without the relevant specification. A complete record names the seed pair, counter and any required cursor.
A gap alone does not establish manipulation. Other eligible bets, another game in the counter's scope or a reset may need to be considered. Equally, a smooth sequence does not prove that a separate history display is complete. Ask for the defined scope and preserve the original sequence. The calculation below checks one input set; it does not inspect an account's entire nonce history or automatically explain a missing number.
4. Strings and bytes must agree exactly
Cryptographic functions consume bytes. In our educational example both seed strings are used as literal UTF-8 text. The string 6162 therefore becomes four bytes representing the characters 6,1,6,2. Decoding it as hexadecimal would instead produce the two bytes for a,b. Both are coherent conventions, but they are different inputs. A real protocol must specify which it expects; appearance alone is not enough.
Spaces, case, Unicode characters and separators also matter. Copying a line break, changing a letter's case or reversing client order can change the digest. The public helper does not silently trim or normalise seeds. Its nonce argument must be a safe nonnegative integer and is formatted in ordinary decimal notation. The integer 2 therefore produces :2, not :02. A different protocol could prescribe a different representation.
Do not repair a mismatch by repeatedly modifying the evidence until a value matches. Keep the original record, document an encoding hypothesis and calculate it separately. A successful calculation with changed inputs does not show those were the inputs used in the selected round. Conversely, an initial mismatch can be a copying or version error and is not, by itself, a diagnosis of fraud.
5. Trace the complete educational calculation
The downloadable illustrative_crash.mjs uses HMAC-SHA256 with a UTF-8 server key and message clientSeed:nonce. Its first 13 digest characters form integer I, with N=2^52 and u=I/N. The displayed multiplier is max(1, floor(100(1-E)/(1-u))/100), where E=0.03. Integer arithmetic in the file evaluates the equivalent cent value max(100, floor(97N/(N-I))). There is no added divisibility condition.
{
"serverSeed": "crashmath_demo_server",
"clientSeed": "crashmath_demo_client",
"nonce": 2,
"status": "calculated",
"model": "HMAC-SHA256, 3% reciprocal, cent floor, no divisibility rule",
"commitment": "da780fd3750c0f33a24c9db836f254463f96ca06f95e17f46b54900a442d25f7",
"roundHash": "55b8a44e6e1065c9fa7e86f9c7a073df271ba21b6307bb029cf4961ea6bb6be5",
"integer": "1508024303149318",
"multiplier": "1.45"
}Keeping fraction and percentage units consistent matters. At u=0.5, the model gives 1.94x. Writing 100-E with E=0.03 would instead use 99.97 in the numerator and is incorrect for a 3% edge. With I=1 the lower bound keeps the displayed result at 1.00x rather than 0.99x. The displayed 1.00x mass is approximately 3.9604% after rounding, not simply 3%. The commitment and conversion guide gives the full finite-grid derivation.
| Nonce | Full round digest | Model multiplier |
|---|---|---|
| 33 | 6ee2ea7bf800e1fe442daf393072494c01e0390e0c5f9c4efbb448fef81b98e7 | 1.71x |
| 38 | 6f5edd047e570bce458ebc9f916514f88ac3e3af767006664b06ee19971fce62 | 1.71x |
The two example nonces above have different full digests but the same rounded multiplier. This is not a hash collision. It is a many-to-one conversion into displayed amounts. A rule promising different outcomes for all nonces would be wrong even when the hashes differ. These are synthetic controls, not observed live rounds or evidence that any player received a payment.
6. Keep seed rotation and historical checking separate
A possible lifecycle is commitment, active use, retirement, disclosure and retrospective checking. This sequence is an explanatory model; actual controls and timing must come from the selected product. Preserve the commitment and seed-pair identifier before a rotation if you want to check that relationship later. Do not assume that disclosure itself proves when the original hash appeared.
There is no universal requirement to rotate after 200 or 300 rounds, and no privacy guarantee follows from such a schedule. Rotation does not erase account records, hide network metadata or authenticate settlement. It also does not prevent every replay attack by itself. Bet identifiers, authorisation and server state are separate concerns. Do not replace these questions with a general assertion that increasing the nonce neutralises every threat.
7. Read a calculation status honestly
The browser hash walkthrough calculates under its selected model. It does not have separate expected commitment and recorded-result fields for an automatic match. Its HMAC contexts are labelled illustrative, and their extra divisibility rules differ from the downloadable no-modulo example. Its Aviator calculation is a separate branch. Select the appropriate specification before comparing output; a familiar game label alone is insufficient.
A calculated seed hash is not evidence of a prior commitment without the independently saved value. A reproduced multiplier is not proof that a wager was accepted or paid. For a real comparison, retain the expected commitment and recorded result, state which checks were possible and leave missing ones unverified. Never pass an active unrevealed seed to an unfamiliar service merely to fill a form. Public historical test data is enough for learning the method.
8. Finish with a usable record
A useful record identifies game, version, round or seed pair, original commitment and timing, revealed inputs, exact encoding and the conversion rule. It distinguishes the calculated digest from the recorded digest and the calculated multiplier from the displayed one. If a required field is unavailable, note it. You can stop without making another wager or obtaining a supposed secret key from a signal seller.
Our public synthetic dataset lets you practise reproducibility, not certify an operator. Expected-value tools explore declared assumptions and do not optimise a lucky seed. Direct partner registration is separate and does not require completing a verification exercise. Knowing the meaning of the inputs improves the quality of a check; it does not create positive expectation or guarantee account privacy, payments or future results.
