Quick answer: Provably Fair is a verification model, not a single crash-game algorithm. A valid check normally has two parts: first, confirm that the operator did not change a committed seed or hash-chain value; second, reproduce the displayed result with the exact inputs and formula documented for that game. Matching only the pre-round hash verifies the commitment, but it does not by itself prove that the displayed multiplier was calculated correctly.
Crash games ask players to trust a result they cannot see in advance. Provably Fair systems reduce that trust requirement by publishing cryptographic evidence before a result is disclosed and enough data afterward to check the calculation. The important word is check: the system should let a player reproduce a completed result rather than merely accept a casino label or a green “verified” message.
The implementation is not universal. Spribe documents a server seed, player-generated seeds, a combined seed, and SHA-512 for its games. Stake Crash points to a separate salt-hash seeding model built around a long SHA-256 chain and a future Bitcoin block hash. BC.Game Crash publishes another hash-chain method, while the current Bustabit verifier uses chain-specific HMAC inputs and 52-bit multiplier math. These systems share a commitment-and-verification idea, but their seeds, byte handling, formulas, and interfaces are not interchangeable.
Do not use a generic recipe for every platform. A calculation can be cryptographically correct and still produce the wrong result if it uses the wrong algorithm version, key/message order, character encoding, digest segment, rounding rule, or house-edge mapping.
What Provably Fair Actually Proves
A cryptographic hash is a fixed-length digest of an input. NIST describes secure hash algorithms as tools for generating message digests that can be used to detect whether the underlying message has changed. A hash is not encryption: there is no decryption key that turns a SHA-256 digest back into the original seed.
In a commitment-and-reveal system, the operator first publishes a hash of hidden data. Later, it reveals the original data. Anyone can hash the revealed value and compare it with the earlier commitment. A match shows that the revealed value is consistent with the commitment; changing even a small part of the input would normally produce a different digest.
That check is necessary, but it is only one layer. The game must also document how its inputs become the displayed multiplier. Some systems use SHA-256 directly, some use HMAC-SHA256, and Spribe publicly describes SHA-512 for its combined seed. HMAC is a keyed construction: the key and message have different roles, so reversing them changes the output.
Check 1: Commitment
Does the revealed seed, game hash, or chain value reproduce the commitment that was available before the relevant result was disclosed?
SHA256(revealed value) = earlier commitmentCheck 2: Outcome
Do the disclosed inputs, exact algorithm, and rounding rules reproduce the multiplier or other result shown in the completed round?
documentedAlgorithm(inputs) = displayed resultWhen both checks succeed, the available evidence supports two conclusions: the committed data was not silently replaced after commitment, and the disclosed calculation reproduces the recorded result. It does not prove every broader claim about the casino, the quality of its random inputs, or the safety of player funds.
Why There Is No Universal Set of Three Seeds
Many single-player casino games use a server seed, a client seed, and a nonce. That model is common, but the original version of this page incorrectly presented it as the architecture of every Provably Fair crash game. Multiplayer crash systems often use hash chains, external salts, multiple player inputs, or other provider-specific structures instead.
| Architecture | Typical inputs | What is committed | What the player verifies |
|---|---|---|---|
| Server seed + client seed + nonce | Hidden server seed, player seed, bet counter, sometimes a cursor | Hash of the active server seed | Seed commitment and the game-specific output calculation after seed rotation |
| Reverse hash chain | Game hash from a pre-generated chain, sometimes combined with an external salt | Terminating chain hash or another published chain anchor | Relationship between consecutive hashes and the multiplier derived from each game hash |
| Multiplayer combined-seed model | Operator seed plus one or more player-generated seeds | Hash of the operator seed before the round | Revealed seed data, combined hash, and provider-specific round result |
| Precomputed result + secret | Hidden result, secret value, and a client seed applied according to game rules | Hash of the precomputed data | Commitment, disclosed data, and final result transformation |
The correct verification procedure therefore starts by identifying the exact implementation. Do not assume that a Stake Originals formula for a single-player game applies to Stake Crash, or that a Bustabit formula reproduces Aviator because both games display a rising multiplier.
Publicly Documented Crash-Game Verification Models
| Game or platform | Publicly documented model | What can be checked | Important limitation |
|---|---|---|---|
| Aviator / Spribe | Hashed server seed before the round; player-generated client seeds; combined seed hashed with SHA-512 | Spribe says game history exposes the server seed, player seeds, combined hash, and result | Spribe's public page says each game uses different result mathematics and does not publish a standalone Aviator multiplier formula there |
| Stake Crash | Salt-hash model; published seeding event used 10 million SHA-256 chain values and Bitcoin block 584,500 as an external input | Hash-chain continuity, HMAC input, 32-bit extraction, and the published crash-point formula | This is different from the standard per-player seed, nonce, and cursor flow used by many other Stake Originals |
| BC.Game Crash | Ten-million-value reverse hash chain with each hash mapped to a multiplier | Chain continuity and the published 52-bit conversion example | The exact current verifier and chain generation must be used; a generic seed-and-nonce calculator is not equivalent |
| Bustabit v2 | Verifiable hash chain; HMAC-SHA256 with a chain-specific salt or signature; 52-bit multiplier mapping | Current and previous chains through the open-source verifier | Historical tutorials may use a different instant-bust rule and should not be treated as the current v2 implementation |
| BGaming Provably Fair titles | Hash of a precomputed Result + Secret, followed by a player client seed and post-round disclosure | The commitment and the game-specific transformation documented in the provider's widget | The method varies by game type and should not be substituted for another provider's crash algorithm |
Step-by-Step: How to Verify a Completed Round Correctly
The following workflow applies across architectures, but the data fields and formulas must come from the relevant provider documentation or open-source verifier.
Identify the game, provider, and algorithm version
Record the exact game and platform. Find its official fairness documentation, verifier, seeding event, or published source code. A formula with no named implementation and no version is not enough.
Capture the pre-round commitment
Save the hashed server seed, next-server-seed hash, terminating chain hash, or other commitment before the relevant hidden value is revealed. Include the round ID and timestamp where possible. Without evidence of what was committed beforehand, a later hash match has less evidential value.
Save the post-round inputs
After the round, collect every disclosed input required by that implementation: server seed or game hash, player seeds or external salt, nonce, round number, chain generation, signature, displayed multiplier, and any algorithm-version identifier.
Reproduce the commitment with exact encoding
Hash the revealed value exactly as documented. “Hash the seed” can mean UTF-8 text, raw hexadecimal bytes, or the hexadecimal representation of previous bytes. Those inputs are not equivalent. Confirm whether letter case, separators, prefixes, and line endings are significant.
Reproduce the round result
Run the documented hash or HMAC calculation, select the specified bits, and apply the correct multiplier mapping, flooring, minimum, cap, and house-edge rule. Compare the unrounded and displayed values where the interface rounds the output.
Interpret a mismatch carefully
A mismatch is evidence that something in the reproduction does not match the recorded system. Before alleging manipulation, recheck input order, HMAC key versus message, text versus hexadecimal bytes, nonce and cursor values, chain generation, formula version, and rounding. If the exact official process still fails, preserve screenshots and raw values for further investigation.
A strong verification record contains: the pre-round commitment, round ID, disclosed inputs, provider documentation or source-code version, the calculation output, and the displayed result. A screenshot of a built-in “fair” badge alone is weak evidence.
How to Verify Aviator by Spribe
Spribe's public Provably Fair page describes a model in which the operator generates a random server seed and publishes its hashed version before the round. Player client seeds are generated on the player side. At round start, Spribe combines the server seed with player seeds and hashes the combined seed with SHA-512.
The same official page says that the hashed version of the next round's server seed is available in the Provably Fair settings, where the player can also change a client seed. After a completed round, the game-history fairness window exposes the server seed, player seeds, combined hash, and result.
The safe verification procedure is therefore:
- Open Aviator's Provably Fair settings and record the next-server-seed SHA-256 commitment before the round.
- Save the round ID and displayed multiplier.
- Open the completed round in game history and collect the server seed, listed player seeds, combined hash, and result.
- Confirm that the revealed server seed matches the earlier commitment using the exact input format shown by Spribe.
- Compare the combined hash and result with the values shown in the round record.
Do not insert another provider's multiplier formula. Spribe states that each game uses different mathematics to convert the SHA-512 output into a result. Its public Provably Fair page does not provide a universal standalone formula that turns any SHA-256 or SHA-512 string into an Aviator multiplier.
The previous version of this article claimed that Aviator always uses exactly the first three players' seeds and that the result “does not exist” until those three players bet. Spribe's public page confirms player-generated seeds and SHA-512 combination but does not support that exact three-player statement, so it has been removed.
How to Verify Stake Crash
Stake's current Game Events documentation directs Crash users to its BitcoinTalk seeding thread and calls the model salt-hash based. The published 2019 seeding event generated a chain of 10 million SHA-256 hashes. Each chain value was created by hashing the hexadecimal representation of the previous value, and the final chain hash was published before play.
The event also specified Bitcoin block 584,500 as a future external input. Once mined, its block hash was used with each game hash in HMAC-SHA256. The published calculation then reads the first 8 hexadecimal characters and maps that 32-bit integer to the crash point.
For Stake Crash, verification is not the same as entering a personal client seed and nonce into the standard Stake Originals calculator. The relevant checks are:
- Confirm that a revealed game hash links forward to the previously published chain value using the documented hexadecimal representation.
- Use the documented Bitcoin block hash as the HMAC message and the game hash as the HMAC key.
- Extract the first 8 hexadecimal characters and apply Stake's published Crash formula.
- Compare the result with the recorded round, accounting for the platform's display precision.
The complete numerical formula and a worked example are covered in the Crash Game Algorithm Guide. Keeping the formula there avoids turning this trust-model page into a duplicate technical reference.
How to Verify BC.Game Crash
BC.Game's official white paper describes a verifiable chain of 10 million hashes, released in reverse order, with each hash corresponding to one Crash multiplier. Its published example reads the first 13 hexadecimal characters, representing 52 bits, normalizes that integer, and applies an inverse mapping with a 1.00× minimum.
A BC.Game Crash check should establish both chain continuity and outcome reproduction. Verify the relevant hash against its neighboring committed chain value, then run the current official conversion procedure for that hash. Do not use a generic serverSeed:clientSeed:nonce calculation unless BC.Game's current Crash documentation explicitly specifies it for the chain being checked.
Because the provider can update documentation or verifier code, record the source version or access date with any audit. A result that matches an old copied formula but not the current official verifier is not a successful verification of the current implementation.
How to Verify Bustabit v2
Bustabit publishes an open-source verifier. Its current multiplier function calculates HMAC-SHA256 using a chain-specific salt or signature and the game hash, extracts the most significant 52 bits, converts them into a value between 0 and 1, and maps that value to a multiplier.
The verifier also distinguishes current and previous hash chains and handles them differently when stepping through the chain. This is why copying only the multiplier formula is insufficient for a complete historical audit. Use the official verifier version that corresponds to the round and chain generation being checked.
Historical-code note: Many older tutorials describe a divisible(hash, 101) instant-bust rule as “the Bustabit formula.” That rule is not present in the current official Bustabit v2 multiplier function. It belongs to older or different crash implementations.
Why a Generic Online SHA Calculator Is Often Not Enough
A basic SHA calculator can confirm a simple commitment when the provider hashes a text seed directly. It cannot automatically reproduce a full crash result. HMAC requires a key and a message, while many crash implementations also require exact byte interpretation and a separate multiplier formula.
| Common mistake | Why it changes the result |
|---|---|
| Using SHA-256 instead of HMAC-SHA256 | HMAC is a keyed construction, not ordinary concatenation followed by hashing |
| Swapping HMAC key and message | The two fields have different roles and produce a different digest when reversed |
| Hashing hexadecimal text instead of hexadecimal bytes | The character string ab12 is not the same byte sequence as 0xab 0x12 |
| Adding separators or spaces | Every character changes the digest; a:b, ab, and a|b are different inputs |
| Using the wrong nonce, cursor, or round number | The same seeds intentionally generate different outputs when counters change |
| Rounding instead of flooring | A result such as 1.709 can display as 1.70× or 1.71× depending on the documented rule |
An independent check is strongest when it uses inspectable code or a reproducible local script. A provider's built-in verifier is still useful for obtaining the official inputs and expected result, but a second implementation provides better evidence than trusting the same interface that produced the round.
Are Provably Fair Crash Rounds Independent?
The answer depends on what “independent” means. In a hash chain, consecutive hidden chain values are mathematically related: hashing one value produces the next committed value. They are therefore not unrelated objects in a strict structural sense.
However, a secure hash function is designed so that a revealed hash does not provide a practical method for recovering its unrevealed preimage. Past displayed multipliers should not provide usable information about the next unrevealed multiplier when the seeds have sufficient entropy and the implementation is correct. A streak of low or high crash points does not reveal the missing secret input.
This is the relevant conclusion for players: chart patterns do not become a prediction signal merely because the system is Provably Fair. Prediction would require leaked inputs, weak seed generation, an implementation defect, or compromised infrastructure. It does not follow from ordinary round history.
Provably Fair vs Certified RNG
Provably Fair
Primary evidence: commitments, disclosed inputs, and reproducible calculations.
Player check: a completed round can be tested against the published method when sufficient data is exposed.
Main limitation: verification is only as complete as the disclosed inputs, algorithm, and implementation.
Certified RNG or Live Randomness
Primary evidence: testing, certification, regulatory controls, equipment procedures, or audited software.
Player check: individual outcomes are not usually reproducible from public seed data.
Main limitation: players rely more heavily on laboratories, regulators, and operator controls.
The categories are not mutually exclusive. A provider can use cryptographic verification alongside certified random-number generation or other tested systems. Conversely, a Provably Fair label does not replace licensing, security controls, game testing, or responsible handling of player balances.
Can a Provably Fair Game Still Have a House Edge?
Yes. Provably Fair and house edge answer different questions. Verification asks whether the committed inputs and published result mapping were used consistently. House edge describes the long-run expected return created by that mapping.
A crash formula can be fully reproducible while deliberately returning less than the fair-odds payout. The edge may appear as an RTP factor, a reduced numerator, an instant-loss interval, a payout table, a maximum multiplier, or another documented rule. Verifying the calculation confirms that the rule was followed; it does not make the rule favorable to the player.
For provider RTP values and expected-loss calculations, use the Crash Game RTP and House Edge Guide. The present page focuses on evidence and verification rather than comparing payout percentages.
What Provably Fair Does Not Guarantee
It does not remove the house edge
A correctly verified game can still have a negative expected value for the player. Provably Fair checks whether the disclosed procedure was followed; it does not make the payout distribution favorable.
It does not prove the advertised RTP by itself
One verified round says nothing about long-run return. Even many reproduced rounds do not prove the theoretical RTP unless the full mapping, caps, instant-bust rules, and configuration are known and analyzed.
It does not prove that the initial secret was selected fairly
A commitment shows that hidden data was not changed after commitment. It does not automatically prove that the operator generated that hidden data without bias. Player inputs, future external salts, secure randomness, and auditable procedures can reduce this concern.
It does not audit the entire software stack
A published formula may be correct while the production system contains bugs, data-display problems, or undocumented behavior. Open-source verification code and external testing improve confidence but do not make implementation risk disappear.
It does not protect deposits or withdrawals
Game-result verification does not establish that an operator is solvent, secure, licensed for a player's jurisdiction, or willing to process a withdrawal. Those are separate operational and regulatory questions.
Red Flags in a Provably Fair Claim
- No pre-result commitment: the platform reveals seeds after a round but provides no evidence of what was committed before the hidden value became useful.
- No raw verification data: the interface shows a green badge but does not expose the seed, game hash, round ID, nonce, external salt, or other required inputs.
- No documented result mapping: the commitment can be checked, but there is no reproducible explanation of how the digest becomes the displayed multiplier.
- No implementation or version identifier: the provider changes verifier logic without recording which rules apply to historical rounds.
- Only a closed verifier with no exportable inputs: the user cannot reproduce the result outside the same system that generated it.
- Marketing claims exceed the evidence: phrases such as “100% impossible to manipulate” are used without explaining assumptions, implementation limits, or what the check does not cover.
Frequently Asked Questions
What does Provably Fair mean?
It means the game exposes cryptographic data that can be used to check a completed outcome. A strong verification confirms both the earlier commitment and the provider-specific calculation that produced the displayed result.
Is a hash an encrypted result?
No. A cryptographic hash is a one-way message digest, not encrypted text. The operator later reveals the original seed or chain value, and the player hashes it again to test whether it matches the earlier commitment.
Can a casino still cheat in a Provably Fair game?
Provably Fair makes certain forms of post-commitment alteration detectable when the system is correctly implemented and the user has complete data. It does not rule out weak seeds, implementation defects, misleading documentation, compromised infrastructure, or misconduct unrelated to the result calculation.
Does a matching server-seed hash prove the multiplier is correct?
No. It proves that the revealed seed matches the earlier commitment. You must separately reproduce the result with the correct client inputs, HMAC or hash construction, number extraction, multiplier formula, and rounding rules.
Can I verify Aviator with any SHA-256 calculator?
A SHA-256 calculation can be relevant to the server-seed commitment shown by Spribe, but the full round system also uses player seeds, a combined seed, SHA-512, and game-specific result mathematics. A generic SHA-256-to-multiplier calculator does not reproduce Aviator.
Does Provably Fair prove the advertised RTP?
Not by itself. It can prove that disclosed inputs reproduce particular outcomes. Verifying RTP requires the complete result distribution, all game parameters, rounding, caps, instant-loss rules, and enough evidence that the published implementation matches production.
Can Provably Fair predictors forecast the next crash point?
Not from public round history or a visible commitment alone. A valid advance prediction would require information that should still be hidden, such as leaked seeds, or exploitation of a weak implementation. A tool that only recognizes chart patterns is not performing cryptographic prediction.
Primary Sources
- Spribe Provably Fair — server seed, player seeds, SHA-512 combination, settings, and game-history verification.
- Stake Provably Fair: Game Events — directs Stake Crash to the salt-hash seeding model.
- Stake.com Crash Seeding Event — original 10-million-hash commitment, Bitcoin block input, and published Crash formula.
- BC.Game White Paper: Provably Fair — reverse hash chain and 52-bit Crash example.
- Bustabit Official Verifier: Multiplier Math — current HMAC and 52-bit result mapping.
- Bustabit Official Verifier: Chain Logic — current and previous chain handling.
- BGaming Provably Fair — Result + Secret commitment and client-seed workflow.
- NIST FIPS 180-4 — Secure Hash Standard covering SHA-256 and SHA-512.
- RFC 2104 — formal HMAC construction and the distinct roles of key and message.
Last implementation review: July 23, 2026. Provider documentation, verifier code, chain generations, and interfaces can change. Save the source version or access date when auditing a specific historical round.
Related Guides
- Crash Game Algorithm — verified Stake, BC.Game, and Bustabit multiplier math
- Crash Game Hash Verification — calculation-focused round checks and common input errors
- How Crash Games Work — non-technical explanation of betting, cash-out, and crash points
- Crash Game RTP and House Edge — what verification does and does not establish about expected return
- Can You Predict Crash Games? — hidden inputs, implementation weaknesses, and predictor claims