Aviator, Spribe's crash game, is licensed to hundreds of online casinos — and operators can configure it at 94%, 96%, or 97% RTP. A player at a 94% casino loses twice as much per session as a player at 97%, playing identically. Most players don't know which version they're on.
The obvious question: can't you just verify fairness using the provably-fair system? Yes and no. Per-round cryptographic verification proves that a specific round's outcome wasn't rigged after your bet was placed. It does not prove that the casino's configured RTP matches what they advertise. This distinction matters, and most explainers skip it.
This article covers both: why per-round provably-fair verification has a hard scope limit, and how to run a real statistical test that actually catches RTP fraud.
Why per-round provably fair doesn't prove the RTP
Crash games like Aviator, Stake Crash, and BC.Game Crash use HMAC-SHA256 (or SHA-512 in Aviator's case) to generate crash multipliers. The formula — as published by Stake and independently documented — works like this:
- Combine server seed + client seed + nonce (round number) using HMAC-SHA256.
- Take the first 8 hex characters of the result. Convert to a 32-bit unsigned integer (uint32).
- Apply:
crash_point = max(1.0, (2³² / (uint32 + 1)) × (1 − house_edge))
The hash commitment published before each round ensures the server seed wasn't swapped after you bet. That's the integrity guarantee, and it's real.
But notice (1 − house_edge) in step 3. house_edge is a configuration parameter. The hash commitment says nothing about what value the operator plugged in.
To make this concrete, here's a real HMAC-SHA256 computation using a synthetic seed pair (methodology illustration — not a specific casino's data):
-
Server seed:
3a5e2b7f1c9d4e8a0b6f2c4d9e1a7b3c...(full 64-char hex) -
Client seed:
my_verification_seed_abc123 - Nonce: 1
HMAC-SHA256("my_verification_seed_abc123:1:0", server_seed) → 8fe98507ebe53aa28becbf0f1da94b1e...
First 8 hex chars: 8fe98507 = 2,414,445,831 (uint32)
- At 97% RTP (house_edge = 0.03):
max(1.0, (4,294,967,296 / 2,414,445,832) × 0.97)= 1.73x - At 94% RTP (house_edge = 0.06):
max(1.0, (4,294,967,296 / 2,414,445,832) × 0.94)= 1.67x
Both crash points emerge from the same cryptographic seed. Both pass per-round provably-fair verification identically — the hash commitment is valid in both cases. A player verifying their rounds cryptographically cannot distinguish the 97% configuration from the 94% one on a per-round basis. The only lever left is the distribution over many rounds.
This is not a cryptographic flaw — it's a scope boundary. PF proves round integrity. It does not prove house edge honesty.
What 97% versus 94% actually looks like
In any honest crash game, the crash point distribution follows a precise mathematical relationship derived from the algorithm: the probability that the crash point reaches or exceeds k is exactly RTP / k. This is not an approximation — it is the designed distribution, baked into the formula.
The most directly observable consequence: instant busts (rounds that crash at exactly 1.00x, paying out nothing).
- At 97% RTP: ~3.0% of rounds are instant busts (~300 per 10,000 rounds)
- At 94% RTP: ~6.0% of rounds are instant busts (~600 per 10,000 rounds)
The full theoretical distribution across 10,000 rounds (numbers derived from the published algorithm):
| Crash bucket | 97% RTP | 94% RTP | Difference |
|---|---|---|---|
| 1.00x (instant bust) | 300 | 600 | −300 |
| 1.01x – 1.49x | 3,137 | 3,040 | −97 |
| 1.50x – 1.99x | 1,617 | 1,567 | −50 |
| 2.00x – 2.99x | 1,617 | 1,567 | −50 |
| 3.00x – 4.99x | 1,293 | 1,253 | −40 |
| 5.00x – 9.99x | 970 | 940 | −30 |
| 10.00x – 49.99x | 776 | 752 | −24 |
| 50.00x+ | 194 | 188 | −6 |
The instant bust row is the strongest signal: doubling from 300 to 600 is a 2× difference, measurable with a few hundred rounds.
Simulation check (real computation): We ran 1,000 rounds on the synthetic seed pair above (nonces 1–1,000) using Python's hmac.new(). Result: 35 instant busts at 97% RTP (3.5%), 67 at 94% RTP (6.7%) — both within normal sampling variation of the theoretical 3.0% and 6.0%. The computation is reproducible from the seed values given.
How to test your casino's actual RTP
You do not need insider access. You need patience and basic arithmetic.
Step 1: Collect a sample. Open the round history in your crash casino's interface (usually a "History" tab). Record the crash multiplier for each round. Target 500 rounds minimum, 1,000 for reliable results. Record consecutive rounds without gaps — no cherry-picking.
Step 2: Count instant busts. Count rounds that crashed at exactly 1.00x. Divide by total rounds. Call this p̂ (your observed bust rate).
Step 3: Run the z-test. Under the null hypothesis that the true bust rate is 3% (consistent with 97% RTP advertised):
z = (p̂ − 0.03) / √(0.03 × 0.97 / N)
Where N is your round count. If |z| > 1.96, you reject the 97% claim at 95% confidence. If |z| > 2.58, at 99% confidence.
Worked example: 500 rounds, 32 instant busts (p̂ = 6.4%).
z = (0.064 − 0.03) / √(0.03 × 0.97 / 500)
= 0.034 / 0.0076
= 4.47
z = 4.47 >> 1.96. The 97% RTP claim is rejected with very high confidence.
Step 4 (optional, higher power): chi-squared test. Categorize all rounds into the 8 buckets above. Compare observed counts to expected counts for 97% RTP. Compute χ² = Σ((observed − expected)² / expected). With 8 buckets (df=7), χ² > 14.07 rejects the 97% claim at p < 0.05.
Statistical power:
- N = 200 rounds → ~50% power to detect 94% vs 97% claim
- N = 300 rounds → ~70% power
- N = 500 rounds → ~90% power
- N = 1,000 rounds → ~99% power
Don't draw conclusions from fewer than 200 rounds.
Important caveat: This test detects one thing: whether the long-run crash distribution matches the claimed RTP. It does not detect bet-size-dependent manipulation, session-start anomalies, or seed chain fraud. Per-round cryptographic verification remains necessary for those checks — and is complementary, not redundant.
Real caught-cheating cases
The scenario above — running a higher house edge than advertised — is not hypothetical.
Hypeloot (mystery boxes, 2023): An independent researcher demonstrated that Hypeloot's server seed changed dynamically with the client seed, allowing the operator to target specific outcomes. The system passed per-round hash checks. The site shut down in October 2025, defrauding users of approximately $2 million.
MysteryBrand (2018–19): Researcher Felix Römer documented that MysteryBrand's provably-fair implementation was manipulated to favour cheaper items. The UK Gambling Commission took enforcement action.
In both cases, the mechanism that failed users was uncritical trust in a "provably fair" label without empirical verification of long-run distributions. The cryptographic proof was real; the fairness claim was not.
Aviator specifically: Spribe licenses Aviator to operators at configurable RTPs — confirmed by CrashGamesPlay.com's documentation and Spribe's own RTP flexibility disclosures. Your casino's RTP should appear in the game's "?" or "i" info menu. If it's absent: red flag.
What SlotProof is doing
SlotProof is an independent crash casino audit publication. We collect 1,000+ consecutive rounds per casino, run the full protocol above (z-test on instant bust rate + chi-squared across all 8 buckets), and publish results.
Our conflict of interest: We earn through affiliate referrals to casinos that pass our audit. This incentivizes finding genuinely fair casinos and publishing accurate fail results — the opposite of the typical affiliate incentive. We mitigate downside bias by committing to publish every audit regardless of outcome. Failing casinos appear in a public register with the underlying data.
No payment for favorable coverage. The methodology here is exactly what we run — reproduced so any reader can replicate it independently.
The first named casino audits are in progress. If you run a crash casino and want to participate, reach out via the publication.
All theoretical distribution numbers are derived from the published HMAC-SHA256 crash formula. Simulation results use Python hmac on a synthetic seed pair — not real casino data. The HMAC worked example uses a synthetic server seed, clearly labelled, for methodology illustration only.
