Hash chains: how crash and roulette seeds are fixed in advance

A hash chain lets a casino fix the seeds of a long run of future crash or roulette rounds by publishing a single 64-character hash before the first one. Each seed revealed afterwards can be traced back to that hash, one SHA-256 calculation at a time, so no round can be changed quietly. Here is how a chain works, where the idea comes from, how to check a link yourself and what a chain can't prove.

One hash that fixes a run of rounds

A chain starts with a random secret. Hash it with SHA-256, hash the result, and keep going for N steps. The last value, called the terminal, is published before the first round; everything else stays secret.

Rounds then use the links in reverse. Round 1 gets the link just below the terminal, round 2 the one below that, and the last round gets the secret itself. Here is a five-link chain made for this article from a made-up secret, each link shown by its first 16 of 64 hex digits:

A real chain has as many links as the rounds it is meant to cover, but the shape is the same. On cs2.casino, Crash, Roulette and Dust2 each have their own chain, with the terminal published before the first round (see the shared rounds section of the provably fair page).

Why the chain runs backwards

Everything rests on SHA-256 being one-way: computing its 256-bit digest is fast, but finding an input that produces a given digest, called a preimage, is not. NIST rates SHA-256's preimage resistance at 256 bits, roughly 2²⁵⁶ guesses by brute force. The record preimage attack, published in 2026, works only on a version cut down to 47 of SHA-256's 64 steps, and its authors call their results theoretical.

Now look at what a revealed seed gives away. Once round 2 is over, its seed is public, and anyone can hash it once to get round 1's seed and again to reach the terminal. Round 3's seed is the value that hashes to round 2's seed, so finding it from round 2's seed means finding a preimage, which SHA-256 makes infeasible.

So at any moment, every seed already used can be checked, every seed still to come stays hidden, and all of them were fixed when the terminal went public. The order is locked as well: each seed must hash to the one before it, so two rounds can't trade seeds. The provably fair explainer covers how a single hash works as a commitment; a chain stretches one commitment across every round it covers.

A password trick from 1981

The idea is older than online casinos. In November 1981, Leslie Lamport, then at SRI International, published "Password Authentication with Insecure Communication" in Communications of the ACM. His problem was eavesdropping: anyone listening on the line between a user and a remote computer could record a password and reuse it.

His answer was a chain. The user picks a secret and applies a one-way function to it 1,000 times, and the system is given only the final value. Each login then sends the value one step further down: the system applies the function once, checks that the result matches the value it holds, and keeps the new password for next time. Someone who records a password can't work out the next, because that means running the function backwards.

He weighed two obvious alternatives and found neither satisfactory: storing all 1,000 check values up front means both sides keeping 1,000 values, and sending the next one at each login fails if a connection drops or an intruder interferes. The chain needs one stored value and still fixes every password in advance. On his publications page, Lamport describes the method as "a cute hack".

Bellcore built its S/KEY system on the scheme (RFC 1760, 1995), and S/KEY evolved into the One-Time Password system, published as RFC 2289 in 1998 and now an Internet Standard. Ronald Rivest and Adi Shamir later built PayWord, a micropayment design, on the same idea: the buyer commits to the end of a chain, then pays a cent at a time by revealing the next link, which the seller checks with one hash. A casino chain works the same way. The terminal is the stored value, each round's seed is the next password, and checking a round is the server's single hash.

Checking a link yourself

You need two values, the terminal and the seed of the round you want to check:

1. Hash the seed once. The result should be the previous round's seed, or the terminal for round 1.
2. To skip the rounds in between, hash round n's seed n times. The result should be the terminal.
3. If either comparison fails, the seed isn't the one the chain committed to.

With the example chain, round 2's seed is 40ff587c085b6ba21ad8f701ef137a98790eb53b5f74bb8f1d82c7c67cd8c94c, and this shell line (Linux) hashes it twice:

• s=40ff587c085b6ba21ad8f701ef137a98790eb53b5f74bb8f1d82c7c67cd8c94c; for i in 1 2; do s=$(printf '%s' "$s" | sha256sum | cut -d' ' -f1); done; echo "$s"

It prints 124a61d50dce9167ac933ad320bc467444d9b25931846fd8938843313d9e72ab, the terminal. Node.js does the same in one line; change the 2 to n for round n:

• node -e "let h = process.argv[1]; for (let i = 0; i < 2; i++) h = require('crypto').createHash('sha256').update(h).digest('hex'); console.log(h)" 40ff587c085b6ba21ad8f701ef137a98790eb53b5f74bb8f1d82c7c67cd8c94c

Two details trip people up. Use printf '%s', not echo, which adds a newline: with it, round 2's seed hashes to f4b74f4d… instead of round 1's seed. And a link can be hashed as its 64 characters of text or as the 32 bytes they stand for, which give unrelated chains: as bytes, round 2's seed gives deacfb46…, matching nothing above. The example hashes text; a check must use the same form as the site, and the step-by-step guide for solo bets covers the tools in more detail.

Long chains are no obstacle. Lamport expected one application of his function to take "a couple of milliseconds". In a test for this article, Node.js on a two-core cloud server ran a million chained SHA-256 hashes in about 0.7 seconds, so tracing a round millions of links back takes seconds. cs2.casino's round pages also recompute each result in your browser; the commands above are for checking without relying on any code the site wrote.

What a chain doesn't prove

A chain proves that every seed was fixed, in order, when the terminal was published. Several things fall outside that.

• That the operator didn't know the results. It made the chain, so it knows every seed, and with seeds alone it would know every result in advance. cs2.casino handles this by combining each seed with a drand beacon from the quicknet network, published only after betting closes: round hash = HMAC-SHA256(seed, drand randomness). The drand article explains why no one, the house included, can know that value early.
• That the terminal was public in time. It only commits the operator if it was published before the rounds it covers, so save a copy when you first see it.
• That the chain lasts. A chain of N links covers N rounds. Lamport's users had to pick a new secret after 1,000 logins, and a casino chain also has to be replaced when it runs out, with the new terminal published before its first round.
• That the game is good value. The house edge sits in the payout rules, not the seeds. In crash it is built into every crash point, as the crash article shows, so bets on perfectly verifiable rounds still return less than their stake on average. Over time the house wins.

Sources

• Password Authentication with Insecure Communication (1981) — Leslie Lamport
• My Writings — Leslie Lamport
• RFC 1760: The S/KEY One-Time Password System — RFC Editor
• RFC 2289: A One-Time Password System — RFC Editor
• PayWord and MicroMint: Two Simple Micropayment Schemes — MIT CSAIL
• FIPS 180-4, Secure Hash Standard (SHS) — NIST CSRC
• Hash Functions — NIST CSRC
• Dual-Syncopation Meet-in-the-Middle Attacks: New Results on SHA-2 and MD5 — IACR ePrint Archive