BC.Game Crash

About BC.Game Crash

BC.Game Crash is the in-house crash game offered by BC.Game, a crypto-native casino that launched its Originals catalogue in 2017. The operator declares a return-to-player (RTP) of 99% (1% house edge), matching Stake's headline figure on Column A.

Where BC.Game's provably-fair model differs from Stake's is in how the underlying randomness is committed. Rather than committing a single server seed and deriving outcomes via HMAC at play time, BC.Game's crash implementation pre-generates a chain of 10 million crash points up front, hashes that chain via SHA-256, and reveals individual outcomes in reverse order as rounds are played. This is a different commit-ahead surface than Stake's per-seed scheme and we treat it as a distinct Column C verification path.

Why this game matters

BC.Game is a peer-volume reference point to Stake within the crypto-native segment, and its pre-committed reverse-reveal scheme is one of the cleanest examples of commit-ahead in the category. Auditing this scheme under our methodology §4.2 lets us publish a worked-example contrast: same headline RTP, structurally different cryptographic posture. That contrast is one of the things the Three-Column model was designed to surface.

What we are watching for

• Column A (RTP): identical 99% claim to Stake. Tested independently — same statistical pipeline, no shared assumptions across operators.
• Column B (Distribution): truncated geometric expectation under house_edge = 0.01. Same goodness-of-fit suite as the rest of the audit programme.
• Column C (Provably-fair): because outcomes are pre-committed in batches of ~10M, our verification target is commit-chain depth — how far ahead the operator publishes the outermost SHA-256, and whether all intermediate reveals re-hash back to that commitment without gaps. Chain breakage with no plausible innocent explanation triggers Emergency Blacklist review under §6.3.
• Reverse-reveal continuity: because outcomes are revealed in reverse order from a fixed sequence, any "skipped" or duplicated reveals would be detectable as a discontinuity in the back-derived index. We monitor for that signal.

Public data sources we are using

• Source 1 (Official): BC.Game's in-game fairness panel, which exposes the committed top-of-chain hash and per-round reveal data.
• Source 3 (Self-operated proxy): a Clash Watchdog AI proxy account observing rounds at minimum stake. As with all Source 3 collection, the proxy account is rotated and de-correlated to avoid differential treatment.
• Source 2 (Community): opens in Phase 2.

See Three Data Sources for the cross-validation rules and our methodology §2 for the publication thresholds when sources agree or disagree.

Audit status

A first Tier 1 (Provisional) audit is in preparation. The BC.Game pre-commit chain depth check is part of our Phase 1 reference notebook. If you have observed something unusual on BC.Game Crash, tell us.