“Provably Fair” is a technical description, not a trust badge. It normally means that a game publishes enough cryptographic material for a player to reproduce a completed result. That can be valuable: a claim based on inputs and a formula is stronger than a claim based on a logo, a chat message, or a screenshot. It also has a narrow scope. Reproducing a multiplier does not prove that a site is licensed in your country, that a withdrawal will be processed, that a promotion is suitable, or that a future round will be favourable. This guide explains how to check the evidence that the protocol actually exposes and how to write down the limits of that check.
Start with a precise question
Before opening a verifier, write the question you want to answer. A useful question is: “Do the disclosed inputs for round 184 reproduce the displayed crash point under the published algorithm?” An unhelpful question is: “Is this platform safe?” The first has observable inputs and a calculation. The second combines legal status, customer support, payments, responsible-gambling controls, account rules, and personal risk. Those areas need separate evidence from the operator, regulator, payment provider, or independent consumer sources.
Use a separate record for every claim. Label a cryptographic result as reproducible only when you can repeat it yourself. Label a claim as published when it appears in documentation but you have not confirmed it. Label a claim as not assessed when the available material cannot answer it. This simple language prevents an audit note from accidentally becoming marketing.
Understand the usual commitment sequence
Many crash systems use a server seed, one or more client seeds, a nonce or round counter, and a hash function such as SHA-256 or HMAC-SHA256. Before bets are accepted, the game may show a hash of an undisclosed server seed. That hash is called a commitment. After the round, the system reveals the server seed and the other inputs. You hash the revealed seed yourself and compare it with the earlier commitment. If the values match, the operator could not have substituted a different revealed server seed after showing that commitment.
That is a meaningful property, but it depends on the published sequence. Record when the commitment was visible, whether it was associated with a round identifier, and whether the reveal occurred after the round. A seed that appears only after a dispute is weaker evidence than a commitment you captured before play. A screenshot alone is also weak: save the text values, the page URL, date and time, and, when possible, the raw response exported by the browser. Do not modify those files after collection.
Collect the inputs before calculating
A reproducible record normally includes the server-seed commitment, revealed server seed, client seed or seeds, nonce, round identifier, game version, displayed multiplier, and the full algorithm description. Do not guess missing values. Different providers place the seed on different sides of an HMAC operation, concatenate fields in a different order, encode text differently, or apply an additional rule for instant crashes. Two formulas that look similar can produce different outputs.
Copy values as plain text and preserve letter case where the documentation requires it. Note whether the values are hexadecimal, base64, decimal, or ordinary UTF-8 text. If the interface hides a value behind a button, save both the visible state and the revealed value. If the user can change a client seed, record when it was changed and whether the change was confirmed before the relevant round. A protocol cannot be evaluated from a remembered value or a partial history row.
Reproduce the commitment
First calculate the commitment independently. For example, if the documentation says the displayed commitment is SHA256(serverSeed), hash the revealed server seed with a local, transparent tool. Compare every character, not only the first or last part. If it differs, stop the calculation and document the mismatch. Possible causes include an undocumented encoding rule, a copied value from another round, a stale interface, or a defect. Do not “correct” the input until it matches.
Next reproduce the result exactly as the documentation specifies. A generic description such as “we use SHA-256” is not enough. The method must state the key and message order for HMAC, separators, nonce format, the number of digest bits taken, rounding rules, and any special cases. If those instructions are incomplete, write that the result cannot be independently reproduced from the published method. That is a valid audit finding; inventing a conventional formula is not verification.
Check the multiplier conversion
A hash is only an intermediate value. The game converts it into a multiplier through a mathematical rule. Some implementations take a fixed number of bits, convert them into a fraction between zero and one, and apply a reciprocal formula. Others use divisibility tests or a capped value. The same hash can therefore lead to different displayed outcomes under different published rules.
Write the formula next to your result. Include the exact rounding moment: rounding before a threshold test can change an outcome. Use decimal arithmetic with enough precision, then apply the provider’s stated display rule. If a verifier gives only a green tick without showing inputs and intermediate values, treat it as a convenience tool, not as independent evidence. A local calculation, a simple script you can inspect, or a spreadsheet with visible formulas is easier to review later.
Use RTP correctly
Return to player, or RTP, describes a model over a very large number of wagers under stated conditions. It is not the percentage a particular person should expect to receive in an evening. A crash distribution has a long tail: rare high multipliers contribute heavily to the average, while most small samples remain noisy. A sample can therefore differ from a published RTP without proving manipulation, and it can look close to the model while revealing little about a hidden implementation detail.
If you analyse a sample, publish the collection rule before looking at the result. State the source, start and end time, number of consecutive rounds, missing values, duplicate handling, conversion rule, and whether the rounds were selected manually. Report the sample mean with uncertainty or, at minimum, the fact that it is only a descriptive sample. Do not call an observed percentage “certified RTP,” and do not turn a near match into a promise about future play.
Keep network observations separate
Network capture can answer limited delivery questions. It may show the order in which a browser received a commitment, a round event, and a result. It may also expose a visible round ID or a documented API response. It cannot by itself prove that a cash-out command was processed fairly or that a server clock was accurate. Device time, network congestion, page rendering, and local extensions can all affect what you observe.
When recording network evidence, state the device, browser version, approximate location, connection type, capture time zone, and whether any proxy or extension was active. Remove account identifiers, session tokens, wallet addresses, and personal data before sharing a trace. If latency is relevant, report a range over repeated measurements and explain the measurement point. Do not present a single fast response as an infrastructure guarantee.
Build an audit record someone else can repeat
A useful record contains a scope statement, source URLs, timestamps, raw inputs, a copy of the documented formula, calculation steps, observed output, and a limitations section. Save the original evidence separately from your notes. A reader should be able to take the same disclosed values and arrive at the same multiplier without trusting the author.
- Scope: the exact technical claim being tested.
- Evidence: commitment, revealed inputs, round ID, formula version, and capture time.
- Method: the tool or script, input encoding, calculation steps, and rounding rule.
- Result: match, mismatch, or insufficient documentation.
- Limits: questions the test does not answer, including legal, payment, account, and future-outcome claims.
Use the result responsibly
A successful reproduction says only that a particular disclosed round follows a particular disclosed method. It does not change the negative expected value that may be built into a game, reduce volatility, or make gambling a source of income. If the published method cannot be reproduced, if inputs are missing, or if the commitment does not match, preserve the evidence and ask the operator for a written explanation. For licensing, payment, or consumer-protection questions, use the competent regulator and the terms that apply to your country.
CrashMath’s tools are independently verified by CrashMath for the stated calculation purpose. They are not official tools of any operator and do not endorse, certify, or represent a gambling service. Treat a verifier as a way to inspect a completed claim, then keep the conclusion as narrow as the evidence.