Three tools that show the game's fairness on verifiable math: recompute a round's outcome, build your own set of rounds, and calculate where the distance leads. Everything is computed right in the browser — nothing is sent anywhere.
The word 'fair' in gambling usually requires trust: you trust that the casino didn't tweak the result. Provably fair removes trust from the equation — fairness can be rechecked cryptographically. Let's break down how it works, and then try it right away on the tools below.
A round's outcome in JetX is determined by three ingredients. Server seed — a secret number on the server side; it's 'sealed' by publishing a hash before your bet. Client seed — a string you set. Nonce — the round number. Their combination is run through a one-way hash function (HMAC-SHA256) and turned into a specific crash multiplier.
The key point: the hash of the server seed is published before the round, but the server seed itself is revealed only after. So the casino can't choose the result after the fact (the hash wouldn't match), and you can't predict it in advance (you can't pull the number out of the hash). After the round you take the revealed server seed, repeat the calculation — and check it. That's exactly what the verifier below does.
Enter the seeds and nonce — the browser will recompute the multiplier with the same algorithm as the server. No data is sent anywhere.
1import hashlib, hmac
2
3def crash_point(server_seed, client_seed, nonce):
4 msg = f"{client_seed}:{nonce}".encode()
5 h = hmac.new(server_seed.encode(), msg, hashlib.sha256)
6 n = int(h.hexdigest()[:13], 16) # first 52 bits
7 if n % 33 == 0:
8 return 1.00 # instant crash
9 return round((2**52 / (2**52 - n)) * 0.97, 2)
Set a seed and look at the distribution of 60 rounds. Change the seed — the order is always new, and there's no pattern by which the next one can be guessed.
Plug in your parameters and see for yourself: over the distance the expectation is determined only by RTP, not by the chosen multiplier or 'strategy.'
Provably fair solves exactly one task: it proves that an individual round is not tweaked and that its outcome was predetermined randomly before your bet. This is a strong guarantee of the mechanic's fairness — and it's precisely this that offline 'predictors' and 'signals' can't provide.
But it's just as important what provably fair does not prove. It doesn't make the game profitable: the casino's edge is built into the distribution of outcomes itself, and a fair RNG doesn't cancel it. Verifiability is about transparency, not profit. If someone cites a 'fair RNG' as an argument that 'you can win,' that's a bait-and-switch of concepts.
Provably fair is a way to make sure the casino didn't tweak the result, without taking its word for it. Before a round the server commits a secret number (server seed) by publishing its hash. The round's outcome is computed from this number, your client seed, and the round number (nonce). After the round the server reveals the server seed — and you can recompute the multiplier yourself and check the hash. If it matches, the result was predetermined before your bet and wasn't changed.
No. Provably fair proves only the impartiality and verifiability of each round — that the result is random and not tweaked. It says nothing about profitability: the casino's mathematical edge (about 3%) is built into the distribution of outcomes and doesn't go anywhere. A fair RNG and a negative expectation for the player coexist perfectly well.
No. Before the round you see only the hash of the server seed, and the hash function is one-way — you can't recover the number itself from it. The server seed is revealed only after the round, so provably fair lets you verify the outcome after the fact, but not predict it in advance. It's precisely on the impossibility of prediction that all 'predictors' stumble.
No. All three tools on this page compute right in your browser, in JavaScript: neither the seeds nor the results are sent anywhere. You can turn off the internet and confirm that the verifier keeps working — the calculation is completely local.
It repeats the same algorithm as the server: it takes HMAC-SHA256 of the string 'client_seed:nonce' with the key server_seed, converts the first 52 bits of the result into a number, and by a simple formula gets the crash multiplier (and in some rounds — an instant crash ×1.00). The same calculation is shown in the Python code block — the results match to the hundredth.