Provably fair only means something if you actually run the check. This tutorial walks you through verifying a real crash round on Aviator, Stake and BC.Game: the exact menus, the seeds to copy, the hashes to match and the formulas to re-run, all with a free browser tool and about five minutes.
The 30-second version
Reveal the server seed, hash it to confirm it matches the commitment published before the round, then re-run the platform’s formula to reproduce the crash point. Aviator combines one server seed with three players’ client seeds under SHA-512, while Stake and BC.Game use HMAC-SHA256 with your single client seed. Whichever platform you are on, cross-check with an independent tool rather than the casino’s own verifier.
🛡️ What you are actually checking
Verifying a provably fair round means proving two things: the result was locked in before you bet, and the multiplier on your screen really came from that locked-in value. Every provably fair crash game runs on a commit-reveal scheme. The casino publishes a hash of its secret server seed before the round, then reveals the seed afterwards so anyone can check it.
The cryptography behind that promise is covered in our provably fair explainer. This page is the hands-on companion: where to click, what to copy, and what the numbers must equal. You need three things: your bet history, the platform’s fairness panel, and a free in-browser hash calculator, ideally one that runs entirely client-side through the Web Crypto API so your seeds never leave your device.
Reveal the server seed
Rotate your seed pair (Stake, BC.Game) or open the round’s fairness panel (Aviator). The previously hidden seed becomes visible.
Match the commitment
Run SHA-256 on the revealed seed. The output must equal the hash that was published before the round began.
Recompute the result
Feed the revealed seed, your client seed and the bet’s nonce into the platform’s formula. The output must equal the crash point you watched on screen.
Cross-check independently
Repeat steps 2 and 3 in an independent tool, not just the casino’s built-in checker. Identical results from two separate code bases is the strongest assurance available.
⚠️ Important
Never trust only the casino’s own verifier. A dishonest operator could build a checker that always says fair, so the cross-check in an independent tool is the step that makes the whole exercise meaningful.
🏆 Aviator, Stake and BC.Game at a glance
All three platforms commit to the result before bets close; they differ in how the seeds combine and whether the exact formula is public. The differences matter when you check by hand, because the right method on one platform produces a false mismatch on another.
Aviator’s three-player design means no single party, Spribe included, knows the result until three independent client seeds are committed. Stake is the easiest to verify rigorously, because every step of its algorithm is public and every past bet stays verifiable indefinitely. BC.Game’s chain design means every crash number in its history already existed before the first round was ever played.
⚡ Verify an Aviator round
Aviator verification is two hash checks: confirm the revealed server seed matches its pre-round commitment, then confirm the combined SHA-512 hash of all four seeds matches the one shown in the round panel. Before each round the operator generates a 16-character server seed and publishes its hash. When the round starts, that seed is combined with the client seeds of the first three players to bet and hashed with SHA-512 to drive the result.
That three-player design is unique among the big crash titles: the house cannot pick the outcome alone, and neither can any player. The game itself, its features and its maths are covered in our Aviator guide. Here is the verification routine.
Set your own client seed
Open the user menu and go to Provably Fair Settings. Replace the random default with a string of your own before you bet, so the casino could not have predicted your input.
Copy the commitment
In the same panel, note the value labelled Next Server Seed (SHA256). This is the fingerprint of the seed about to be used.
Play the round
Place your bet and let the round finish as normal. Nothing else needs doing while the multiplier runs.
Open the round’s fairness panel
In your bet history, click the green shield icon next to the round. The window shows the revealed server seed, the three player seeds, the combined SHA-512 hash and the result.
Check the commitment
Paste the revealed server seed into a SHA-256 calculator. The output must equal the hash from step 2, proving the seed was fixed before you bet.
Check the combined hash
Concatenate the server seed and the three client seeds in the exact order shown, with no spaces, and run SHA-512. The output must equal the displayed combined hash, proving none of the inputs were tampered with.
📝 For the record: Aviator commits to its next server seed with SHA-256 but computes the round with SHA-512. Using the wrong function at the wrong step is the most common reason an Aviator check appears to fail.
Reproducing the multiplier itself is the loose end. The widely used method takes the first 13 hex characters of the combined hash, divides by 2 to the power of 52 to get a number x between 0 and 1, then computes 0.97 / (1 – x). That output matches Aviator’s fixed 97% RTP, including the roughly 3 in 100 rounds the algorithm forces to end at 1.00x.
🔍 Worth noting
Spribe has not published its exact hash-to-multiplier formula as of mid-2026, so that reconstruction is community consensus, not source code. Treat the two hash matches as the rigorous proof and the multiplier reproduction as a strong approximation.
⚠️ Scam alert: Predictor apps and Aviator hack repositories are scams without exception. The round is sealed before bets close, so predicting it would mean breaking SHA-512, and the fee or API key they ask for is the real product.
⚙️ Verify a Stake Crash round
Stake publishes its complete algorithm, source code included, which makes it the easiest crash game to verify end to end. Every verifiable bet is generated by HMAC-SHA256 with the server seed as the key and clientSeed:nonce:cursor as the message. The cursor stays at 0 for Crash, and the nonce counts your bets under the current seed pair. The game itself is covered in our Stake Crash guide.
Stake’s published conversion
houseEdge = 0.99 floatPoint = (1e8 / (float * 1e8)) * houseEdge crashPoint = floor(floatPoint * 100) / 100 result = max(crashPoint, 1)
The float comes from the first 4 bytes of the HMAC output, each divided by 256 to the power of its position and summed, which is the same as reading the first 8 hex characters as a 32-bit integer. The whole calculation is algebraically identical to the simpler form crashPoint = max(1, (2^32 / (int + 1)) * 0.99), which is the version most independent verifiers implement.
Set your client seed
Go to Settings, then Fairness, or click the shield icon in any game. Edit the client seed to your own string before playing.
Copy the commitment
The active server seed is displayed only as a SHA-256 hash. Save it: this is the value the revealed seed must reproduce later.
Play, then find the nonce
Each bet’s nonce sits in its detail view in your bet history. Note it for any round you want to check.
Rotate the seed pair
Click Rotate Seed Pair, or Unhash next to the active seed. The previous server seed is revealed, the nonce resets to 0, and only bets made before the rotation are checkable.
Check the commitment
Run SHA-256 on the revealed server seed. The output must equal the hash you saved in step 2.
Recompute the crash point
Run HMAC-SHA256 with the revealed server seed as the key and clientSeed:nonce:0 as the message. Take the first 8 hex characters as an integer, apply the formula above, and the result must match the round you saw.
Worked example: an HMAC output whose first 8 hex characters give the integer 726,928,685 produces 4,294,967,296 / 726,928,686 x 0.99 = 5.84x. If your numbers reproduce the round like that, the check has passed.
For the independent cross-check, provablyfair.me, Spindex, Dyutam and Stake Analyzer all reimplement Stake’s published algorithm in the browser and run client-side, so seeds never leave your device. Stake’s own help centre points players to external verification, and the casino is a verified operator with the Crypto Gambling Foundation. Use the external tool as the deciding vote, not the in-house calculator.
🔢 Verify a BC.Game Crash round
BC.Game pre-generated a chain of 10 million SHA-256 hashes and plays them in reverse order, so every crash number in the game’s history existed before the first bet was placed. Each round consumes one hash from the chain, and hashing any round’s value with SHA-256 produces the previous round’s hash. That lets you walk the chain backwards to the publicly committed terminating hash, proving the whole sequence was fixed in advance.
Per-player results then mix in your client seed through HMAC-SHA256 before the conversion below, so the operator could not have tailored an outcome to you. The game itself is covered in our BC.Game Crash guide; here is the white paper’s own worked example of how a hash becomes a multiplier.
From hash to multiplier (white-paper example)
hash = 6b5124897c3c48d0... first 13 hex = 6b5124897c3c4 = 1,887,939,992,208,324 X = 1,887,939,992,208,324 / 4,503,599,627,370,496 = 0.419206... raw = 99 / (1 - X) = 170.45... crash point = floor(170.45) / 100 = 1.70x
The 13 hex characters carry 52 bits, and the divisor is the largest 13-character hex value, which normalises X to between 0 and 1. Any raw value below 100 is set to 100, which is the roughly 1-in-100 instant bust at 1.00x that carries the house edge.
🔍 Worth noting
BC.Game flips the HMAC inputs relative to Stake: the client seed is the key and the round hash is the message. Hand checks that fail on BC.Game usually fail right here.
Set or note your client seed
Go to Profile, then Fairness, or click the fairness shield inside any in-house game. Set your own seed before betting.
Play your rounds
Bet as normal. Every round you play consumes the next hash in the pre-generated chain.
Reveal the seed
Click Change Seed in the fairness panel. The old seed is revealed and a new hashed seed takes over for future rounds.
Verify the round
Combine the round’s chain hash with your client seed under HMAC-SHA256, client seed as the key, then apply the 13-hex-character conversion above. The output must match the multiplier you saw.
Verify the chain
Run SHA-256 on the round’s hash: the output must equal the previous round’s hash. Repeat as far back as you like towards the published terminating hash to prove the chain was pre-generated.
BC.Game publishes an open-source chain verifier on GitHub, hosted at game-verify.github.io. Because its crash variant differs from the generic Stake-style method, test any third-party tool against a round you have already verified with the official one before relying on it.
◆
⚠️ Eight mistakes that break a verification
Almost every failed check is an input error, not evidence of rigging, and these eight cover nearly all of them. Work through the list before concluding anything about the casino.
- Using the hashed seed instead of the revealed one. The pre-round hash is a fingerprint of the seed, not the seed. Reveal first, then hash what was revealed.
- Not rotating before checking. On Stake and BC.Game the server seed stays hidden until you rotate. That is deliberate: it stops anyone reading future rounds in advance.
- Using the wrong nonce. Each bet has its own, recorded in the bet’s details, and the counter resets to 0 after every rotation.
- Swapping the HMAC inputs. Stake uses the server seed as the key; BC.Game uses the client seed. Crossing them produces a clean-looking mismatch.
- Applying the wrong formula for the platform. Stake’s 32-bit method, BC.Game’s 13-hex chain and Aviator’s three-seed SHA-512 are not interchangeable.
- Confusing the commitment with the result. The published hash identifies the seed; it is not the crash multiplier in disguise.
- Trusting only the in-house verifier. A checker built by the operator is a second opinion from the same party. The independent cross-check is the point.
- Treating a pass as a green light to bet more. Verification proves the round was honest, not that the odds are good.
🎯 Picking an independent verifier
A trustworthy verifier runs entirely in your browser, shows its source, and produces the same answer as the casino’s tool from the same inputs. Open-source options include the verifier apps hosted by the provably-fair GitHub organisation and BC.Game’s own chain checker, while the four browser tools named in the Stake section reimplement Stake’s published algorithm.
To confirm a tool really is client-side, open your browser’s developer tools with F12, watch the Network tab and run a check: there should be zero outbound requests. Then run the same seeds, client seed and nonce through both the casino’s verifier and the independent one. Identical results from two unrelated code bases is the strongest practical assurance you can get.
◆
🔍 What a matching hash proves, and what it does not
A passed verification proves the result was sealed before your bet and untouched afterwards; it says nothing about the price of playing. Be precise about what each side of that line means before you draw any conclusions from a check.
- The result predates your bet. The commitment hash was published first, and the revealed seed reproduces it exactly.
- The operator could not react to your wager. Changing the seed after seeing the bets would break the hash match.
- Your input mattered. Your client seed feeds the calculation, so a result could not be pre-tailored to you.
What it does not prove: that the game is beatable, or that the return is generous. A game can verify perfectly and still run at 94%, because the edge is written into the very formula you reproduced, the 0.97 in Aviator’s method and the 0.99 in Stake’s and BC.Game’s. It also says nothing about deposits, withdrawals or whether the platform can pay you. Honest and cheap are different claims, and verification only ever speaks to the first.
“A matching hash proves nobody touched the result. The formula behind it is where the house takes its cut.”
Run the routine once and watch the hashes line up, and the anxiety behind our is Aviator rigged deep dive answers itself. The maths is honest, the result was sealed before you bet, and the cost of playing is exactly the advertised edge, collected on every round wherever you cash out.
Proof of honesty is not proof of safety: certainty that the game is fair can make it easier to play longer, while the verified edge keeps compounding with every round. We cover the research evidence, the risk factors and what regulators are doing in a dedicated guide: crash gambling and player harm.
One last filter before you deposit anywhere new.
The bottom line: if a site shows no pre-round hash, will not let you set your own client seed, or never reveals past server seeds, it is not genuinely provably fair. Treat that as a hard filter when choosing a crash game, then verify a few rounds on anything that passes.
❓ Frequently asked questions
Quick answers to the questions players ask most about running these checks.
How do I check if a crash game is provably fair?
Look for three things before betting: a server seed hash published before the round, an editable client seed, and a way to reveal past server seeds. If all three exist, run the four-step check at the top of this guide on a real round. If any is missing, the game is not verifiably fair, whatever the marketing says.
Can I verify Aviator rounds?
Yes. The round’s fairness panel exposes the server seed, the three client seeds and the combined SHA-512 hash, and both hash checks can be reproduced exactly in any independent calculator. Only the final multiplier formula is unofficial, so treat that last step as an approximation rather than proof.
What tools can I use to verify provably fair rounds?
Any client-side SHA-256, SHA-512 or HMAC calculator covers the hash checks. For Stake, provablyfair.me, Spindex, Dyutam and Stake Analyzer reimplement the full algorithm in the browser, and BC.Game publishes an open-source chain verifier. Confirm a tool sends no network requests before trusting it with your seeds.
Why do I need to rotate my seed before verifying?
Rotation is what reveals the previous server seed; until then you only ever see its hash. That design stops anyone, you included, from reading future results in advance. After rotating, the nonce resets to 0 and a fresh hidden seed takes over.
Does provably fair mean I will win?
No. It proves the results were generated honestly and were not altered after your bet. The house edge sits inside the verified formula itself, so a perfectly fair game still costs you its edge over time.