Quick answer: A complete crash-game verification has more than one step. First, confirm that the revealed seed or game hash matches the value committed before the round. Next, reproduce the platform's exact hash or HMAC input. Finally, apply the correct multiplier formula, rounding rule, minimum and chain version. A matching commitment alone proves that the hidden input was not changed; it does not by itself prove that the displayed multiplier was calculated correctly.
Provably Fair is useful only when the player can reproduce the relevant checks. A green badge or a built-in verifier is evidence provided by the platform, not an independent calculation. This guide shows what data to collect, which checks are actually possible, and why the procedure differs between Bustabit, BC.Game, Stake Crash and Aviator.
This page is the practical part of the CrashGamesPlay technical cluster. For the trust model behind commitments, seeds and nonces, read Provably Fair Explained. For provider-specific multiplier mathematics, use the Crash Game Algorithm Guide.
What a Successful Verification Proves
Verification can establish several separate facts. They should not be collapsed into a single “fair” result.
Commitment check
The disclosed seed or game hash matches the digest published before the result became known. This shows that the committed input was not silently replaced.
Chain check
A game hash belongs to the previously committed sequence and links correctly to adjacent hashes under the platform's documented chain rules.
Input check
The server value, player value, external salt, nonce, game number and byte encoding were combined in the documented order.
Result check
The resulting digest produces the displayed crash point after the correct bit extraction, formula, flooring, minimum and maximum rules are applied.
What it does not prove: A valid round calculation does not establish that the advertised RTP is favorable, that the operator is solvent, that withdrawals will be processed, or that the game is legal in your location. Provably Fair verifies a defined calculation, not the entire casino.
Collect the Round Data Before Calculating Anything
Save the raw values exactly as the interface displays them. Do not retype long hexadecimal strings when a copy button is available. One missing character, uppercase conversion in a case-sensitive seed, invisible space or reversed HMAC field is enough to create a mismatch.
| Data item | Why it matters | Common mistake |
|---|---|---|
| Pre-round commitment | Provides the value against which the later disclosure is checked | Recording the value only after the round |
| Revealed server seed or game hash | Supplies the hidden input used by the verification calculation | Using the active unrevealed seed instead of a completed seed set |
| Client seed, player seeds or external salt | Completes the provider-specific input | Assuming every game uses one player-set client seed |
| Nonce, cursor or game number | Selects the correct event or position in a sequence | Starting the nonce at 1 when the implementation starts at 0 |
| Displayed crash point | Provides the result to reproduce | Comparing a rounded interface value with an unrounded calculation |
| Algorithm version or chain generation | Determines encoding, salts and formula details | Applying old tutorial code to a current chain |
The Four-Step Verification Workflow
Identify the implementation
Determine whether the round uses a hash chain, a seed-and-nonce system, multiple player seeds, an external salt or another provider-specific model. Do not start with a generic online formula.
Verify the commitment or chain
Hash the revealed seed using the documented encoding, or move through the chain using the exact current chain rule. Compare the output with the value committed earlier.
Reproduce the digest and multiplier
Use the documented HMAC key, message, seed order, byte representation and formula. Then reproduce the platform's flooring, truncation, minimum and cap.
Compare and diagnose
A match confirms the disclosed inputs reproduce the displayed result under the tested implementation. A mismatch is a reason to investigate, not immediate proof of manipulation.
Local Commitment and Chain Checks
Running a small script locally avoids sending seeds to an unknown website and makes the calculation reproducible. The first example hashes a UTF-8 server seed with SHA-256.
# Python 3: verify a SHA-256 seed commitment
import hashlib
revealed_seed = "PASTE_REVEALED_SERVER_SEED_HERE"
expected_hash = "PASTE_PRE_ROUND_SHA256_HERE".lower()
calculated_hash = hashlib.sha256(
revealed_seed.encode("utf-8")
).hexdigest()
print("Calculated:", calculated_hash)
print("Expected: ", expected_hash)
print("Match: ", calculated_hash == expected_hash)The next example checks one common text-based hash-chain relationship. Use it only when the provider documents hashing the hexadecimal text itself. Some current chains hash the binary bytes represented by the hex string instead.
# Python 3: two different SHA-256 chain encodings
import hashlib
current_hash = "PASTE_CURRENT_GAME_HASH"
# Method A: hash the visible hexadecimal text as UTF-8
next_from_text = hashlib.sha256(
current_hash.encode("utf-8")
).hexdigest()
# Method B: decode the hexadecimal string and hash its binary bytes
next_from_bytes = hashlib.sha256(
bytes.fromhex(current_hash)
).hexdigest()
print("Hash of text: ", next_from_text)
print("Hash of bytes:", next_from_bytes)Do not guess the encoding. The current Bustabit verifier, for example, handles its current and previous chains differently: one path hashes binary hash bytes, while the earlier chain hashes the hexadecimal representation. A calculator can be cryptographically correct and still return the wrong chain value because the input representation is wrong.
How to Verify Bustabit v2
Bustabit provides a public verifier repository that handles chain navigation and multiplier calculation. Its current multiplier function computes HMAC-SHA256 using a chain-specific salt or signature as the key and the game hash as the message. It then reads the 52 most significant bits and maps them through an inverse distribution.
Data needed
- game number;
- game hash;
- the chain generation to which the game belongs;
- the appropriate public salt or signature used by that generation;
- the displayed bust multiplier.
Current Bustabit multiplier mapping
// Simplified from the current official Bustabit verifier
hmacHex = HMAC_SHA256(
key = saltOrSignature,
message = gameHash
)
seed = hmacHex.slice(0, 13)
r = parseInt(seed, 16)
X = r / 2^52
crashPoint = max(
1,
floor(99 / (1 - X)) / 100
)The official verifier should be preferred for chain-level checking because it contains version-specific rules. A standalone recreation is useful only after the relevant salt, signature and chain encoding have been confirmed.
Outdated tutorial warning: The current Bustabit multiplier function does not contain a separate divisible(hash, 101) instant-bust test. That rule appears in older or different crash implementations. Adding it to the current verifier changes the result.
How to Verify BC.Game Crash
BC.Game's published Crash model uses a chain of 10 million hashes released in reverse order. Its white paper explains both the chain logic and the conversion of the first 13 hexadecimal characters into a multiplier.
Chain check
Record adjacent game hashes and reproduce the documented SHA-256 relationship. Confirm the exact direction shown by the platform: the chain is released in reverse, so wording such as “previous” and “next” can become confusing when compared with chronological game order.
Published 52-bit result calculation
gameHash = "PASTE_BC_GAME_HASH"
hex13 = gameHash.slice(0, 13)
n = parseInt(hex13, 16)
X = n / 2^52
rawHundredths = 99 / (1 - X)
crashPoint = max(
1,
floor(rawHundredths) / 100
)BC.Game's public example uses the game hash directly for this 52-bit conversion. That is different from Bustabit's current verifier, which first calculates an HMAC value. Similar formulas do not make the complete implementations interchangeable.
How to Verify Stake Crash
Stake's general Provably Fair implementation uses a server seed, client seed, nonce and cursor for many Stake Originals. Crash is a documented exception: Stake's Game Events page directs Crash users to a separate salt-hash seeding model and its published seeding event. Therefore, a generic Stake formula such as HMAC_SHA256(serverSeed, clientSeed:nonce:cursor) should not be presented as the Stake Crash verifier.
What to check
- Open Stake's Provably Fair calculation or round-verification interface for the completed Crash round.
- Record the game hash, chain position and external salt identified for the relevant seeding event.
- Confirm that the game hash links to the committed chain under Stake's documented chain procedure.
- Reproduce the published HMAC input and 32-bit multiplier mapping for that chain.
- Compare the result after applying the same display precision used by the platform.
// Stake Crash mapping published for its hash-chain seeding event
hmac = HMAC_SHA256(
key = gameHash,
message = externalBlockHash
)
n = parseInt(hmac.slice(0, 8), 16)
rawCrashPoint = max(
1,
(2^32 / (n + 1)) * 0.99
)This is a chain-specific published model, not a universal formula for every Stake game or every historical implementation. Use the version and external value referenced by the round being checked.
How to Check an Aviator Round
Spribe's public documentation describes a server seed, player-generated client seeds, a combined seed and a SHA-512 hash. The game history's Provably Fair window shows the values available for a completed round.
- Open Aviator's round history and select the completed round.
- Open the Provably Fair details and copy the server seed, player seeds, combined hash and displayed result.
- Combine the seeds in exactly the order and format shown by the interface.
- Calculate SHA-512 locally and compare it with the displayed combined hash.
- Use Spribe's round-verification interface to confirm the game-specific result calculation.
Public-detail limitation: Spribe states that each game uses different mathematics to convert the SHA-512 output into a result, but its public Provably Fair page does not publish a standalone Aviator multiplier formula. You can independently reproduce the combined SHA-512 hash from the disclosed seed data. A full independent multiplier recreation requires the exact Aviator mapping and byte rules, which should not be replaced with a Stake, BC.Game or Bustabit formula.
Why a Mismatch Does Not Immediately Prove Cheating
| Mismatch cause | What to check |
|---|---|
| Wrong round or nonce | Match the round ID, timestamp, bet ID and nonce shown in history |
| Key and message reversed | HMAC-SHA256 is directional; confirm which value is the key |
| Text versus binary hashing | Check whether the implementation hashes UTF-8 text or decoded hex bytes |
| Invisible separators | Confirm colons, commas, line breaks, spaces and concatenation order |
| Wrong chain generation | Use the constants, salt and hashing rule for the round's actual chain |
| Rounding difference | Distinguish floor, truncation and normal rounding; apply them at the documented stage |
| Incomplete provider disclosure | A matching commitment may be reproducible even when the complete multiplier mapping is not public |
Repeat the calculation with copied raw values and the provider's current documentation. Preserve screenshots and text values if the discrepancy remains. A credible report should identify the round ID, commitment, disclosed inputs, expected result, calculated result, implementation version and complete reproduction steps.
Safe Verification Tools
Local code is the strongest option because it exposes the exact operations and does not send seeds to a third party. Official open-source verifiers are useful when they contain chain-specific constants and version logic. Generic online hash calculators are suitable for a simple digest check, but they are easy to misuse for HMAC or binary data.
| Tool | Best use | Limitation |
|---|---|---|
| Local Python or Node.js | Independent SHA, HMAC, hex and formula calculations | You must reproduce encoding and rounding correctly |
| Official open-source verifier | Versioned chain checks and provider-specific constants | Confirm the repository and commit are official |
| Platform verifier | Quick comparison and access to round data | Not independent unless the calculation can be reproduced elsewhere |
| Online hash calculator | Simple SHA-256 or SHA-512 digest checks | May mishandle HMAC, binary hex input or sensitive values |
Red Flags in a Provably Fair Claim
- No value is committed before the result. A disclosure created only after the round cannot prove pre-commitment.
- The raw inputs are unavailable. A “verified” badge without seeds, hashes or a round ID cannot be independently checked.
- The formula or verifier version is unidentified. The same digest can map to different results under different rules.
- The verifier always receives only a result ID. The platform may be returning a stored answer rather than exposing a reproducible calculation.
- Documentation mixes unrelated games. Stake Crash, BC.Game Crash, Bustabit and Aviator do not share one universal seed format or formula.
- A predictor is presented as a verifier. Verification checks completed rounds; it does not reveal future crash points.
Frequently Asked Questions
How do I verify that a server seed was not changed?
Copy the revealed seed exactly, hash it with the provider's documented function and encoding, and compare the output with the commitment recorded before the round. A match confirms that the disclosed input corresponds to the earlier commitment.
Does matching the server-seed hash verify the multiplier?
No. It verifies the commitment only. To verify the multiplier, you must also reproduce the provider-specific input construction, digest, number extraction, formula and rounding rules.
How do I convert SHA-256 into a crash multiplier?
There is no universal conversion. BC.Game's published model reads 52 bits directly from a game hash, current Bustabit first creates an HMAC and reads 52 bits, while Stake published a separate 32-bit mapping for its Crash hash chain. Use the formula documented for the exact implementation.
Can I verify Aviator with a generic SHA-512 calculator?
You can reproduce the combined SHA-512 hash if you have the exact disclosed seed values and order. Spribe's public page does not provide a standalone Aviator multiplier formula, so a generic calculator alone cannot independently reproduce the final multiplier.
Why does the Bustabit formula in older guides give a different result?
Older guides often include a separate divisibility-by-101 rule or use a different chain generation. The current official Bustabit verifier uses a 52-bit HMAC mapping through 99 / (1 - X) and contains version-specific chain logic.
Does Provably Fair prove that future rounds are unpredictable?
A secure commitment and correctly implemented cryptographic construction are designed to keep unrevealed inputs impractical to derive. Verification of completed rounds does not prove that an implementation has no weak seed, software bug or compromised server, but past charts do not supply the missing secret input.
Primary Sources and Implementation Notes
- Bustabit official verifier: multiplier function
- Bustabit official verifier: current and previous chain logic
- BC.Game white paper: Crash chain and 52-bit example
- Stake Provably Fair game events: separate Crash salt-hash model
- Stake Crash seeding event: hash chain, external block hash and published formula
- Spribe Provably Fair: server seed, player seeds and SHA-512 process
- NIST Secure Hash Standard: SHA-256 and SHA-512
Last implementation review: July 23, 2026. Providers can rotate chains, change salts, update verifier code or revise result mappings. Confirm the current documentation and round version before treating a calculation as authoritative.
Related Guides
- Provably Fair Explained — commitments, seeds, nonces and verification limits
- Crash Game Algorithm — verified provider formulas and implementation differences
- SHA-256 to Crash Multiplier Formula — calculation-focused worked examples
- Crash Game Odds — multiplier probabilities and expected value
- Crash Game RTP and House Edge — theoretical return and expected session cost
- Can You Predict Crash Games? — why verification is not prediction