Provably Fair, Verified Step by Step

What "provably fair" promises — and what it does not

We publish measurements the reader can redo — and "provably fair" is, on paper, the most redoable measurement in online gambling. The term names a precise cryptographic construction, not a trust label. It promises exactly two things. First: the round's result is determined before bets are placed — the operator commits to it in advance, publicly. Second: after the round, the operator reveals the elements that let anyone recompute that result and see that it matches the commitment. If both halves hold, changing a result after seeing the bets becomes impossible without breaking the hash function itself.

What the construction does not promise is just as precise, and it is where commercial language takes its liberties. It says nothing about the payout rate: a round can be perfectly "provable" in a game that returns 90% of stakes, or in one that returns 99%. It says nothing about rounds whose data is not published: the proof covers verifiable rounds, one by one, not the whole history by decree. And it says nothing about everything around the game: not payouts, not licensing, not the operator's solvency. "Provably fair" is a property of a computation, not a general certificate — and the only way to know whether the property holds is to redo the computation. That is what this page does, on a real round, with the numbers in full.

The commitment before the round: the hash that fixes the result

The problem to solve is easy to state: how can an operator fix a result in advance without players being able to read it before betting — and without being able to change it after seeing the bets? Crash games answer with a hash chain. Before the first round, the operator starts from a secret value and applies SHA-256 to it in a loop, millions of times: every link is the hash of the link before it. The operator then publishes the hash of the final link — the anchor, or terminating hash — in a dated public place. The chain is then played in reverse: the last link generated serves the first round, the second-to-last the second round, and so on. Each round's hash is therefore known to the operator from the start — it built the chain — but it is unreadable to players until revealed, because SHA-256 does not run backwards: from a hash, you cannot climb to the next link.

The published anchor acts as the seal. When a round's hash is revealed, anyone can hash it in turn, over and over, and check that the walk ends at the anchor published months or years earlier. If the operator had swapped a single result along the way, that round's hash would no longer lead to the anchor: the chain would be broken, and the break would be visible to everyone. One objection remains: what if the operator generated thousands of chains and kept the most favourable one? That is why the result does not depend on the round's hash alone. Before the first round, the operator announces a salt drawn from a future event nobody can predict: the hash of a Bitcoin block not yet mined, designated by its number. Once the block is mined, its hash — public, written into the blockchain — is combined with every round's hash. Choosing a chain in advance then buys nothing: the salt, unknown at the moment of choice, reshuffles every result.

This construction is not theory: it is the one bustabit published in January 2015 in its first "seeding event" — a chain of 10,000,000 hashes, anchor c1cfa8e2…, announced salt: Bitcoin block 339300. The operator itself explains the particularity of crash games there: a round has a single outcome, shared by all players, so no per-bet nonce is needed as in dice games — the chain and the salt suffice. The construction is still running today: the fourth seeding event, in September 2025, renewed it on a chain of 100,000,000 hashes with a new salt, block 917000. The conversion formulas have been revised between versions; the commitment principle — chain built in advance, anchor published, unpredictable salt announced — has not changed since 2015.

The three pieces of data to demand before verifying anything

A verification exists only if the operator hands over three precise pieces. If one is missing, there is no check to run — there is only a claim.

Per-bet seed systems — common in dice games and some crash variants — package the same three pieces differently: the server seed's hash before the bet, then the revealed server seed, the client seed and the nonce afterwards. The packaging changes; the logic is identical: a cryptographic commitment before, a reveal after, a public formula to pass from one to the other. In both families, the question to ask any game that calls itself "provably fair" fits in one sentence: where are the hash, the salt and the algorithm? The round in the next section shows what those three pieces make possible when all of them are there.

The verification, step by step: our round, replayed

The round replayed here is bustabit #1,135,198, played in March 2015 under the scheme of the first seeding event. Its crash point as published by the game is 1.12x — a short round, a losing one for anyone aiming higher, and that is a good thing: a verification that only worked on handsome rounds would be worthless. The operator itself walked this verification in public at the time, in the Bitcoin forum thread where the scheme had been announced; we redid it from zero, from the primary records: the January 2015 seeding event for the anchor and the salt, the published record of the five consecutive rounds #1,135,194 to #1,135,198 for the hashes and published points, and the public blockchain register for the hash of block 339300.

Step 1 — chain membership. The round's hash is 0f81acc25a875c843f3ee3f9563bfa875be311d7585306e743120a4e68f51f0f. In the 2015 scheme, each link is the SHA-256 of the previous link's hexadecimal representation. So apply SHA-256 to this hash: the result is 1da773ad50c9f5ce2098713e90bfe667c467fb1e1b14d3623113336899cfff4c — exactly the hash of the previous round, #1,135,197. One more turn: c0799484…, round #1,135,196. And so on. After exactly 1,135,198 iterations, the walk lands on c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d: the terminating hash published in January 2015, before round #1,135,198 — and every round before it — was played. The round belongs to the publicly committed chain; its hash cannot have been fabricated after the fact, because fabricating a hash that lands on the anchor in an exact number of iterations would require reversing SHA-256.

Step 2 — the salt. The seeding event had announced Bitcoin block 339300, not yet mined at the time. Its hash, since written into the blockchain and readable in any explorer, is 000000000000000007a9a31ff7f07463d91af6b5454241d5faf282e5e0fe1b3a. We re-read it in the public register (mempool.space) on 30 October 2026: it is exactly the value announced as the salt. Neither the operator nor anyone else knew this value when the chain was built.

Step 3 — recomputing the crash point. The published algorithm combines the two pieces with HMAC-SHA-256, the key being the round's hash and the message the salt: the result is 1cda7a31c271dd9e8b95798aedb9d6adfd83de975f5edd8315de7675b1cdc9ea. Take the first 13 hexadecimal characters — the first 52 bits — giving h = 507,594,856,474,397, a uniform draw between 0 and 2⁵². The published formula converts this draw into a crash point: the floor of (100 × 2⁵² − h) / (2⁵² − h), divided by 100. The computation gives 1.12. Step 4 — the instant-crash rule. The 2015 scheme provides that a round whose hash is divisible by 101 stops at 0.00x: that is the house edge, taken as one round in 101 rather than continuously. Here, the hash modulo 101 is 20: the rule does not fire. Step 5 — the comparison. Recomputed point: 1.12x. Point published by the game: 1.12x. An exact match.

The four neighbouring rounds take the same path, and their intermediate steps are in the downloadable record: #1,135,197 → 8.66x, #1,135,196 → 1.67x, #1,135,195 → 3.89x, #1,135,194 → 6.34x — published and recomputed identically, five out of five. The verifier below redoes these computations in your browser, on these rounds or on values you paste — including, in its "current scheme" mode, recent bustabit rounds, whose chain hashes in binary and whose salt is the hash of block 917000.

What this replay shows holds for any round of any game built this way: the verification needs no account, no permission and no tool supplied by the operator — a hash function and a calculator suffice. Since 2015, bustabit has changed scheme twice (the current chain hashes in binary, the salt is block 917000, the conversion formula is the one in its open-source verifier); what has not changed is the structure of the proof: anchor published before, unpredictable salt announced, recomputation possible after. It is that structure — not the operator's reputation — that makes round #1,135,198 verifiable eleven years on.

What a match proves — and its limits

The match on round #1,135,198 establishes two facts, and only two. First, the recomputed result is the one the chain published in January 2015 already contained: for this round, the crash point was fixed before the bets, in the strong sense — it was mathematically locked inside a sequence of hashes published two months earlier. Second, it was not retouched: any change after the fact would have broken either the chain (step 1) or the recomputation (steps 3 to 5). That is precisely the "provably fair" promise, kept on this round — and it is also the consequence that makes predictors impossible: a result sealed before the round, in a chain nobody can read backwards, can no more be predicted than rigged, as our crash game predictor test page shows.

The limits are of the same order of precision. A match says nothing about the distribution: one round verifying does not prove that the whole set of rounds follows the announced law. Establishing that takes the complete history and a statistical test — the probability that a round reaches at least a multiplier m follows, in the standard crash-game model, P(round ≥ ×m) ≈ (1 − e)/m with e the edge (in our simulation model, e = 2% — a simulation figure, not a measurement of this operator); comparing an observed distribution to that law is a different instrument from recomputing one round. A match also does not cover rounds whose data the operator does not publish: a round with no published hash is a round with no proof, however good its neighbours are. And it says nothing, finally, about what happens outside the computation: deposits, withdrawals, licensing, support. A successful verification answers the question "was this result changed after the bets?" — no. It answers no other.

Fake verifications: checker pages that check nothing

The success of "provably fair" has produced its imitation: pages that reproduce the vocabulary without supplying the pieces. They can be recognised by structural signs, readable with no technical skill at all. First sign: the "verification" page asks for neither the round's hash nor the salt. Yet those are the computation's two inputs — a checker that takes no input checks nothing; it displays. A simple test, within anyone's reach: paste an invented hash, made of random characters. If the page still concludes "round verified", it does not verify false hashes; so it does not verify true ones either. Second sign: the seed is never revealed. Some interfaces show hashes before rounds — the commitment — and then never publish the reveal that would let you open it: a commitment that is never opened commits to nothing. Third sign: the check's outcome is an image, a badge or a screenshot rather than a redoable computation. A proof that cannot be redone off the operator's site, with independent tools, is not a proof: it is an illustration.

The useful contrast is supplied by this page's own example: for round #1,135,198, every piece is public, dated, and also hosted away from the operator's site — the seeding event on a third-party forum, the salt in the blockchain, the verifier's code in a public repository that anyone can read and run at home. An operator who wants to be believed does not need a convincing checker page; it needs to publish three pieces of data. When they are there, its checker page becomes almost unnecessary — ours above, or any hash calculator, does the same work. When they are not there, no page, however polished, can replace them.

When verification is impossible: games that publish nothing

There remains the most common case in today's market: the crash games distributed by the large aggregators and generalist platforms — including the titles we cover daily — publish, for the great majority of them, none of the three pieces. No round hash accessible to the player, no revealed seed, no published conversion algorithm. For these games, the answer to this page's question is blunt: verification is impossible, by anyone, and will remain so until the data is published. That is not a verdict on their results — nothing allows us to say they are skewed, and we do not say it. It is a classification: these games belong to the "unverifiable" category, where trust rests entirely on the operator's licence, reputation and payment history — exactly the situation "provably fair" was invented to move beyond.

The reader can classify any game with three questions, the ones from section 3: does the game publish every round's hash? Does it reveal the seed or salt afterwards? Is the conversion algorithm public? Three yeses: verifiable — run the check, as here. One no, whichever it is: unverifiable — then treat fairness claims as what they are, marketing arguments, and size your exposure accordingly. Between the two there is no intermediate category in which one might "mostly" trust: a cryptographic proof is binary, it can be redone or it does not exist.

Method and data: redo it all yourself

How to read this page: this is an independent analysis, published for information. It recommends neither using nor avoiding any game or operator, and it is not financial advice. Every figure is recomputed from the public records cited below; no operator reviewed or approved this analysis before publication.

Methodology

Replay carried out on 30 October 2026. Primary sources only: the seeding event published by bustabit in January 2015 (chain of 10,000,000 SHA-256 hashes, terminating hash c1cfa8e2…, salt = hash of Bitcoin block 339300 announced before it was mined); the contemporary record of rounds #1,135,194 to #1,135,198 published by the operator in the same forum (hashes, intermediate HMACs, crash points as displayed by the game); the fourth seeding event (September 2025) and the source code of the operator's open verifier for the current scheme; the public Bitcoin blockchain register (mempool.space) for the hashes of blocks 339300 and 917000, re-read on 30 October 2026. Recomputations performed independently by us (Python, standard library): chain steps between the five rounds, each round's HMAC-SHA-256, conversion into a crash point by the published formula, the divisibility-by-101 rule, and the complete walk of the chain from round #1,135,194 back to the terminating hash — reached in exactly 1,135,194 iterations, which fixes the five rounds' numbers. The verifier embedded in this page performs the same computation in JavaScript (SHA-256 and HMAC implemented in the file /assets/pr3/pr3-verifier.js, readable by all); its outputs were checked, value by value, against our recomputations and against the intermediate values published in 2015. No operator data beyond its own publications was used; no round was played for this study.

Complete record of the five rounds: hash, salt, HMAC-SHA-256, intermediate value h, remainder modulo 101, published point, recomputed point, match, and iteration count to the terminating hash, in CSV format. Download the CSV

Free reuse in the press and research, with attribution: "Source: Chicken Road Productions, 'Provably Fair, Verified Step by Step' — replay of bustabit round #1,135,198 from the operator's public records (2026)" — https://chickenroadproductions.com/en/provably-fair-verified-step-by-step/

Available for an interview or a comment on this data: contact the newsroom via the Press page.

References

1. Bustabit, "Bustabit.com Provably Fair Seeding Event", Bitcoin Forum (bitcointalk.org), January 2015 — the seeding event: chain construction, published terminating hash, block 339300 salt, reference code. bitcointalk.org/index.php?topic=922898.0
2. Bustabit (RHavar), detailed verification of five consecutive rounds, thread "bustabit.com — The Social Gambling Game", Bitcoin Forum, March 2015 — hashes of rounds #1,135,194 to #1,135,198, chain steps, HMACs and crash points as published by the game. bitcointalk.org/index.php?topic=709185.2120
3. Bustabit, "bustabit — Fourth seeding event", Bitcoin Forum, 27 September 2025 — return to the classic scheme: chain of 100,000,000 hashes, terminating hash 567a9837…, salt from Bitcoin block 917000. bitcointalk.org/index.php?topic=5560454.0
4. Bustabit, open-source verifier (source code and constants of the successive schemes), GitHub — github.com/bustabit/verifier
5. Public Bitcoin blockchain register, via mempool.space: hash of block 339300 — mempool.space/api/block-height/339300; hash of block 917000 — mempool.space/api/block-height/917000 (re-read on 30 October 2026).
6. NIST, FIPS 180-4, "Secure Hash Standard" (SHA-256), doi:10.6028/NIST.FIPS.180-4; Krawczyk, Bellare & Canetti, RFC 2104, "HMAC: Keyed-Hashing for Message Authentication", 1997 — rfc-editor.org/rfc/rfc2104
7. Chicken Road Productions, "Predictors" for crash games: we replayed their signals over 10,000 rounds, 2026 — the prediction-side consequence of a result sealed before the round.