BC.Game Limbo

About BC.Game Limbo

BC.Game Limbo is a multiplier-based provably-fair Original game in the same family as BC.Game Crash. The mechanic is structurally simple: the player nominates a target multiplier before the round, the operator's algorithm produces a realised multiplier for that round, and the bet pays out if (and only if) the realised multiplier meets or exceeds the target.

The operator declares a return-to-player (RTP) of 99% (1% house edge) — the same headline figure as BC.Game Crash and Stake Crash. Maximum payout per round is reported at up to 1,000,000× target. Each round result ships with a verification hash so that the outcome is independently checkable.

Because the round outcome is a single sampled multiplier rather than a real-time rising curve, Limbo is operationally simpler than crash but mathematically equivalent for the purposes of our audit: the sampled multiplier is the random variable, and its distribution is what Column B tests against.

Why this game matters

We are extending coverage to BC.Game Limbo because:

1. Crash-family inclusion. Limbo's randomness is sampled from the same theoretical distribution family as Crash (1/U-style with house-edge truncation). Our methodology §1.2 applies without modification — same chi-square, K-S, Anderson-Darling tests, same null hypothesis shape.
2. Same operator, separate audit. BC.Game runs Crash and Limbo on related but distinct provably-fair surfaces. Auditing Limbo independently lets us cross-check whether the operator's per-game implementations agree with their per-game claims, rather than collapsing them into one operator-wide assertion.
3. Cleaner Column C surface. Limbo's outcome derivation is single-step (one HMAC, one numeric transform) and easier to fully reproduce in our notebooks than crash, which makes Limbo a useful first verified target for our hash-chain reproduction tooling.

What we are watching for

• Column A (RTP): observed RTP against the declared 99%. Same minimum sample threshold (5,000 rounds for the inconclusive boundary) as our other targets.
• Column B (Distribution): goodness-of-fit against the operator's documented derivation. A natural Limbo expectation is a 1/U-shaped distribution with a 1% house-edge truncation, but the exact derivation is operator-defined and we test against what BC.Game documents, not against a category default.
• Column C (Provably-fair): verification of the operator's per-round hash for every round in our verified window. We re-derive the realised multiplier from the revealed server seed, the observed client seed, and the round nonce, and compare against the published outcome.
• Cross-game consistency: when both BC.Game Crash and BC.Game Limbo are under audit in the same window, we look at whether the operator's Column A drift signals correlate across games. Independent drift is normal sampling noise; correlated drift would warrant a methodology note.

Public data sources we are using

• Source 1 (Official): BC.Game's per-round Limbo verification interface and documented derivation.
• Source 3 (Self-operated proxy): Clash Watchdog AI proxy account placing minimum-stake target bets purely for observation. Target multipliers are kept in a fixed test schedule so that observed wins/losses are not informative about our internal expectations.
• Source 2 (Community): opens in Phase 2.

Cross-validation rules are defined in Three Data Sources and our methodology §2.

Audit status

A first Tier 1 (Provisional) audit is in preparation, scheduled to run in parallel with BC.Game Crash so the cross-game consistency check (above) can be exercised on first publication. If you have observed something unusual on BC.Game Limbo, tell us.