How provably fair crash works: hash chains and verifying a round

Provably fair crash works by fixing every bust point in advance with a chain of cryptographic hashes, then revealing each hash after its round so anyone can check it. If the revealed hash links to the previous one and the published formula turns it into the bust point you saw, the round wasn't changed after bets were placed.

This guide explains the hash chain, the salt and the formula, then verifies four fictional rounds step by step.

The problem provably fair solves

In a crash game the site generates the result. Without a way to check, you would have to trust that the bust point wasn't picked after seeing where everyone set their auto-cashouts. Provably fair systems remove that need for trust in one specific respect: they let you confirm the result was fixed before the round.

They do not change the odds. The house edge is part of the formula, and a perfectly verifiable game still returns less than you stake on average. Provably fair answers "was this round tampered with?", not "is this a good bet?".

Building block 1: SHA-256

A hash function such as SHA-256 turns any input into a fixed-length fingerprint, 64 hexadecimal characters. Two properties matter here:

• It is easy to compute forwards. Anyone can hash a value and get the same output.
• It is practically impossible to reverse. Given a hash, you can't work out the input, or find another input with the same hash.

So publishing a hash is like sealing a value in an envelope: it commits the site to something it cannot change later, without revealing it yet.

Building block 2: the hash chain

A common crash design pre-computes millions of game hashes:

1. The site picks a secret starting value (the seed).
2. It hashes it, then hashes the result, and so on: h1 = SHA256(seed), h2 = SHA256(h1), h3 = SHA256(h2), millions of times.
3. It publishes the final hash of the chain before any games are played.
4. Games are played backwards through the chain: the first game uses the last hash generated before that, and so on.

Because each game's hash, when hashed once more, gives the previous game's hash, every revealed hash can be checked against the one before it. And since nobody can reverse SHA-256, the site can't produce a future hash on demand. It is locked in by the chain.

Building block 3: the salt and the formula

To stop a site generating many chains and keeping a favourable one, many designs mix in a public salt that wasn't known when the chain was committed, for example the hash of a future block on a public blockchain. The site announces in advance which salt it will use.

Each game result is then computed like this (a typical design; check the site's published version):

1. mac = HMAC_SHA256(key = game hash, message = salt)
2. Take the first 13 hex characters of mac and convert them to a number r (this gives 52 bits).
3. R = r ÷ 2^52, a number between 0 and 1.
4. bust = floor(100 × (1 − edge) ÷ (1 − R)) ÷ 100, with a minimum of 1.00x.

Step 4 is the same formula covered in crash odds math: it produces a 49.5% chance of reaching 2x at a 1% edge, and so on.

Worked example: verifying four fictional rounds

Everything below is fictional and was computed with Python's standard hashlib and hmac libraries. Seed: fictional-example-seed-0001. Salt: fictional-public-salt. Edge: 1%.

The site generated a four-hash chain and plays it backwards, so Round 1 uses the last hash. The full hashes:

• Round 4 hash: f0e79bbcc90b8613ffe99ba1220a7913a7fca01401c4bcff5ffc03a1a5268eed
• Round 3 hash: edfbaa47d69fed9f9873cb30b3ab81af7c2201dded456249c5c14f5ba1b55dc5
• Round 2 hash: 4b514574d02e5bc03c46652fdaf817a72d66e813926f3262de021fa91be247f1
• Round 1 hash: b8fd0ab6bf6269b5b39bd7f0c559148a582d4348d794fa2d738deda555c26d7b

Check 1, the chain links. Hash the Round 2 hash with SHA-256 and you get exactly the Round 1 hash. Hash Round 3's and you get Round 2's. Hash Round 4's and you get Round 3's. Each link confirms the newer reveal belongs to the committed chain.

Check 2, the results. Apply the formula to each hash:

Round 2 in detail: 0.99 ÷ (1 − 0.918012) = 0.99 ÷ 0.081988 = 12.075…, and floor(1207.5…) ÷ 100 = 12.07x. If the game showed anything other than 12.07x for that round, something is wrong.

Checklist: verifying a round yourself

• Find the commitment. The site should publish the terminating hash of its chain (and the salt source) before the games you are checking.
• Get the round's hash from the game history after the round ends.
• Check the link. SHA-256 of this round's hash must equal the previous round's revealed hash.
• Recompute the result using the site's published formula: HMAC with the salt, first 13 hex characters, divide by 2^52, apply the edge formula.
• Compare with the bust point shown in the game.
• Use your own tool. A short script or a third-party calculator, not only the site's verification page.
• Check a sample, not just one round. Spot-check several rounds over time, including ones where you lost.

What provably fair does not cover

• The edge. A verifiable formula with a 5% edge is still a 5% edge.
• Payouts and withdrawals. It says nothing about whether the site pays out.
• Account rules. Caps, disconnect handling and bonus terms sit outside the hash chain.
• The meaning of past rounds. Verifying old results doesn't help predict new ones. The hash chain is designed precisely so that you can't.

Provably fair is a useful honesty check on one thing: that results weren't changed after the fact. It is worth understanding, and worth doing once or twice, but it doesn't make crash a good bet. For how the edge plays out whatever you do, see auto-cashout targets and expected value, and for the basics of a round, how crash games work.