Hash chains explained: how crash-style games commit to every round

A hash chain lets a game commit to every future round in advance: the operator picks one secret, hashes it over and over to build a long chain, publishes the final hash, then plays the chain backwards. Each round reveals a hash, and anyone can confirm that hashing it once gives the hash of the round that came before. Crash-style games often use this design because there's no per-player client seed: everyone in a round sees the same result.

This guide builds a small chain, verifies it, shows how one hash becomes a multiplier, and explains what the design does and doesn't guarantee. All values are computed in Python from a made-up starting secret.

Why per-player seeds don't fit crash games

In dice or case games, each player has their own server seed, client seed and nonce, as covered in server seed, client seed and nonce. A crash round is shared: hundreds of people watch one multiplier climb until it stops. There's one result per round, for everyone, so the commitment has to cover rounds rather than individual bets.

Building a chain

Start with a secret, hash it, hash the result, and keep going. Here's a five-link chain built from an example secret:

secret = "a3f1c9e2b7d4058e6f2a1c3b9e8d7f60"

h0 = sha256(secret) = d699d17e98e07810bfac7f92373968b7bf4660a1c99e56279feae81e01c1067d
h1 = sha256(h0)     = d5849088353f5f448c543e9d57658866b7c65919a23d47574fc9a66c1440d0ea
h2 = sha256(h1)     = 95444eff57c9d6fbe0e1273a84a573f011d98e8a07f0706860f36899f490cf00
h3 = sha256(h2)     = e394c6679a387c56127c947d0a86463ba23ff6c55a50e80424dd4168e8f93b14
h4 = sha256(h3)     = 654e77345bc769d4b18fadd77a70367ddfd2ee5f31cb56a92e5ca75b1ae941d1

Each step hashes the previous hash written as 64 lowercase hex characters (the text, not the raw bytes). Real systems build chains of millions of links; the logic is the same.

Playing it backwards

The operator publishes the last hash, h4, before any round is played. That's the commitment. Then rounds use the chain from the end towards the start:

The direction matters. Once round 1 reveals h3, you can confirm it links to the commitment, but you can't compute h2 from h3, because that would mean reversing SHA-256. So every revealed hash is checkable and the next one stays unpredictable.

It also means the operator can't change any future round without breaking the chain. Swap h2 for anything else and sha256(h2) no longer equals the h3 that was already revealed.

What a broken link looks like

Change only the last character of h3 from 4 to 5 and hash it:

sha256("e394c6679a387c56127c947d0a86463ba23ff6c55a50e80424dd4168e8f93b15")
= 4de48c76a719a75a2d2fa4f826bde7de55a327dd87b5b4e52489702094fa22cc   ✗ ≠ h4

One character off and the link fails visibly. That's the property the whole scheme rests on.

From hash to multiplier

The chain proves which hash belongs to each round. A separate formula turns that hash into a crash point. Formulas vary between games; here is one illustrative version so the steps are concrete:

1. Take the first 13 hex characters (52 bits) as an integer v.
2. If v is divisible by 33, the round crashes at 1.00x immediately.
3. Otherwise, crash point = floor((100 × 2⁵² − v) ÷ (2⁵² − v)) ÷ 100.

Applied to our chain (2⁵² = 4,503,599,627,370,496):

The commitment row is shown only to illustrate the formula; it's never played. Round 1 in detail: (100 × 2⁵² − v) ÷ (2⁵² − v) = 450,359,962,737,049,600 − 4,003,649,973,494,663, divided by 499,949,653,875,833, which is 892.79…; floor to 892, divide by 100, and the crash point is 8.92x.

Where the house edge hides

That "divisible by 33" rule is the edge. About 1 round in 33 (roughly 3.03%) crashes at 1.00x, before anyone can cash out. Under this illustrative formula the chance of a round reaching at least a target t is about 96.97% ÷ t:

Multiply any chance by its target and you get about 0.97, meaning you get back roughly 97% of what you stake on average, whatever target you pick. The chain is perfectly verifiable and the game still costs players about 3% per round in expectation. Verification confirms the round; it doesn't remove the edge.

The weakness: who picked the chain?

A pure hash chain has one gap. The operator generated the whole chain before publishing the commitment, so in principle they could generate many chains and keep one they liked. Good designs close the gap by mixing in a value nobody controlled when the chain was fixed: for example, combining each hash with a public value announced afterwards (such as a specified future blockchain block hash) using HMAC. If the game you're checking doesn't explain how it handles this, treat that as a question worth asking. Our red-flags checklist covers it.

Verification checklist for chain-based games

• Save the published commitment hash, with the date, before playing.
• For any round, hash its revealed value and confirm it equals the previous round's hash.
• Confirm the formula is documented and reproduce a few crash points.
• Check whether an external value was mixed in, and verify that step too.
• Compare the formula's built-in edge with what the game advertises.

You can check single dice-style rolls on our verifier; for chains, the short Python above is enough. Either way, a verified round is a fair draw, not a fair bet — the edge is built into the formula.