Crash fairness

​

What happens on-chain during a Crash round?

1. Commit: before betting opens, the backend generates a random 32-byte secret and publishes its SHA-256 hash on-chain (the start_new_round instruction). This is the commitment: from this moment, only that exact secret can ever settle the round. The commitment is public in the transaction’s CrashRoundPrepared event.
2. Betting: players place their bets. The secret stays hidden; the commitment guarantees it cannot be swapped.
3. Round start / entropy capture: when the round begins (the start_game instruction), the program reads the most recent slot hash from Solana’s SlotHashes sysvar and stores it in the round. The app calls this value the round’s block hash. The crash point is now fully determined (it is a pure function of the stored slot hash and the committed secret), but nobody who doesn’t know the secret can compute it yet. The value is public in the CrashGameStarted event.
4. The round plays out: the multiplier climbs and players cash out.
5. Reveal: the backend submits the secret (the crash instruction). The program verifies on-chain that sha256(secret) equals the commitment (a mismatch makes the transaction fail), then computes the crash point itself and finalizes the round. The CrashRoundFinalized event publishes the secret, the slot hash and the final crash point.

​

What is the exact crash point formula?

inputs
  blockhash   32 bytes   the Solana slot hash stored at round start
  secret      32 bytes   the operator secret revealed at the end (committed as sha256(secret))
  edge_bps    integer    house edge in basis points (see Fees and limits; 100 = 1%)

derivation
  hash  = sha256( blockhash ‖ secret )        // 64-byte input: blockhash first, then the secret
  X     = u32_be( hash[0..4] )                // first 4 bytes of the hash, big-endian unsigned 32-bit
  X'    = min( X, 2^32 − 1000 )               // safety cap: the denominator below is never below 1000

  crash_bps = max( 10000, floor( (10000 − edge_bps) × 2^32 / (2^32 − X') ) )

result
  crash multiplier = crash_bps / 10000        // e.g. 30100 → 3.0100x

• The concatenation order is blockhash first, then secret.
• X is read big-endian from the first 4 bytes of the SHA-256 output.
• Divisions are floor (integer) divisions.
• The max(10000, …) floor means the multiplier is never below 1.00x, and the cap on X prevents astronomically small denominators.

​

Worked example

denominator = 2^32 − 2882343476 = 1412623820
crash_bps   = floor( 9900 × 2^32 / 1412623820 ) = 30100
crash       = 3.0100x

​

What the distribution looks like

P(crash ≥ m) ≈ (1 − edge) / m

​

What is guaranteed, and what is not

• After the commitment is on-chain, the operator cannot change the round’s secret: the reveal transaction fails on any secret whose hash does not match.
• Once the round has started (slot hash stored), the crash point is fixed. Cashing out early, late, or in large numbers changes nothing: the outcome was determined before the multiplier started climbing.
• The crash point is computed by the program, not reported by the backend. A wrong value cannot be written on-chain.
• Everything needed to verify (commitment, slot hash, secret, final crash point) is published in on-chain events, permanently.

• Start timing. The operator knows the secret before the round starts, and its backend decides when to submit the round-start transaction. Since recent slot hashes are public, it could in principle precompute the would-be multiplier for candidate slots and time the start to influence which slot hash is captured. The scheme does not prevent this; it makes it observable: round-start timing is public, and any systematic bias would show up in the statistics of published crash points, which anyone can recompute in bulk.
• Cancels. After the round starts, the operator knows the outcome before players do, and it could cancel an unfavourable round instead of revealing. Two hard limits apply: a cancel refunds every stake in full (the program has no confiscation path), and every cancel emits a public event; cancel frequency is the on-chain tell. Cancelling exists as a recovery path for a lost secret (for example a backend crash between commit and reveal) and is expected to be essentially never used.

​

How do you verify a Crash round?