Crash: hash chains, block hashes and the 99 factor
Why Crash uses a different construction from other Originals: a pre-committed hash chain salted with a public Bitcoin block hash, and where the 1% edge enters.
Disclosure: VerifyRoll is sponsored by Craze, a competitor of the operators whose published RTP appears below. Figures here are computed or taken from what operators publish, dated; nothing is estimated.
How the result is derived
Under the Stake scheme every result starts from HMAC-SHA256(server seed, “clientSeed:nonce:cursor”), read four bytes at a time into floats in [0, 1). Crash consumes one 52-bit value per round (not a seed-pair float). Crash is the exception: it does not use a per-player seed pair at all, as described below.
- Before launch the operator generates a long chain of hashes, each the SHA-256 of the next, and publishes the final one. Rounds are played from the chain backwards, so every game hash was fixed before the first round.
- A public client seed, the hash of a Bitcoin block chosen after the chain was published, salts every round so the operator could not have picked a favourable chain.
- For a round: bytes = HMAC-SHA256(key = game hash, msg = client seed). Read the first 13 hex characters (52 bits) as an integer r, and X = r ÷ 2^52, a value in [0, 1).
- Crash point = max(1, floor(99 ÷ (1 − X)) ÷ 100). The 99, rather than 100, is the house edge.
X = int(hmac[0:13]) / 2^52; point = max(1, floor(99 / (1 − X)) / 100)
Payout rule and where the edge comes from
You set an auto-cashout (or cash out by hand) at x. If the round reaches x you are paid x; otherwise you lose the stake.
P(round reaches x) is 0.99 ÷ x for targets above 1.00×. The expected return at any auto-cashout is 0.99 per unit staked. Values of X below 0.01 are clamped, so no round pays below 1.00×.
Source of the edge. The 99 in the numerator. With 100 the game would return exactly 100% over time; each point of the numerator below 100 is a point of edge.
Worked example
Computed on the server by the same functions the verifier runs, from the example values the verifier's “Load example values” button uses. These are not seeds from a real round.
- game hash
- 000000000000000000d2a0c1b6a9e7a0f2f3a3b1c4d5e6f708192a3b4c5d6e7f
- client seed
- verifyroll
- HMAC-SHA256(game hash, client seed)bc86b72f6c8e1ff6c1480af0f1c0b664e17fcb7583da2f2aa469eabc6616bb01
- X (1): 0.73643060
- hmac = bc86b72f6c8e1ff6c1480af0f1c0b664e17fcb7583da2f2aa469eabc6616bb01
- X = first 52 bits / 2^52 = 0.7364305964261393
- point = max(1, floor(99 / (1 − X)) / 100) = 3.75×
Published RTP by operator
| Stake | Shuffle | BC.Game | Craze |
|---|---|---|---|
| 99% | 99% | 99% | — |
Checked 2026-09-23. “—” means not offered or not published. The figure in your game's info panel wins.
Questions
- Why can't I verify a Crash round with my own seeds?
- Because there are none. Crash is one shared round for everyone, so it is made verifiable by committing to the whole chain of game hashes in advance rather than by a per-player seed pair.
- What do I paste into the verifier?
- The game hash shown for the round and the public client seed (the Bitcoin block hash) from the operator's fairness page. The verifier recomputes the crash point from those two values.
Next
- Chance of reaching a target multiplier
- Verify a Crash bet of your own, or by operator: Stake Crash verifier · Shuffle Crash verifier
- House edge for every game and operator
last reviewed 2026-09-23 · derivation as implemented in @craze/fairness