Skip to main content

Crash — Provably Fair

Crash uses a commit→reveal model (the same shape the vfair-games engine uses): the outcome of every round is fixed and committed before betting opens, and the key needed to verify is published at settlement.

The three phases

1. COMMIT — before betting opens

The seed hash is committed to the database the moment the round’s betting window opens. The seed itself stays secret until settlement. Because the seed derives from roundId and a stable pepper, every server instance derives the same seed — there is no room for per-instance discretion.

2. PLAY — the outcome is derived from the committed seed

The crash point is a pure function of committed data. Nothing about gameplay (bet volume, timing, winner count) can influence it.

3. REVEAL — at settlement

The raw seed and pepper are published next to their hash. Anyone can verify:

Where to verify

  • In-app: the Provably Fair popup on every game exposes the verification for the round/bet you’re looking at — same optics as the vfair games’ built-in verify.
  • API: GET /api/crash?action=verify-seeds publishes (seed_hash, seed, pepper) for the 12 most recently settled bet-bearing rounds.

Why the pepper can’t cheat you

The classic fear: “the operator sees my bet and picks a bad seed.” Here that’s impossible by construction:
  1. The seed hash is committed before betting opens — before the operator knows who bets or how much.
  2. The seed is a deterministic function of (pepper, roundId) — the operator cannot “reroll” a round without changing the pepper, which would break every future verification (and any hash comparison against previously published rounds).
  3. After reveal, sha256(seed) === seed_hash is publicly checkable — swapping the seed post-hoc is detectable by anyone.

Odds table (what the formula implies)

The clamp at 100× caps the maximum multiplier; the clamp at 1.00× means ~4% of rounds crash instantly at 1.00 (the house edge rounds themselves). Next: Dice Originals.