Provably fair is a system that lets you check a result yourself instead of taking the operator at their word. The site commits to a secret before the round by publishing its hash, mixes in an input it does not control, then reveals the secret afterwards. Anyone can recompute the outcome from those pieces. If the numbers match, the round was not touched.
That is the whole idea. What follows is what it protects you from, exactly how it is implemented here, and how to check a round of your own in about two minutes.
What problem does provably fair actually solve?
Without it, an odds figure is an unverifiable claim. The operator writes the number on the item card, runs the random number generator, and reports the outcome. Every part of that loop is inside one company, and that company profits from the result.
The specific attack worth caring about is not a rigged random number generator. It is choosing the outcome after seeing the bet. If nothing is committed in advance, a server can look at what you staked, what you are aiming at, and how much you have won lately, and only then decide what you unbox. No published odds table prevents that, because the odds table is not what the result came from.
Provably fair closes that door by forcing the result to be fixed before the operator knows anything about your bet.
The one idea behind all of it: commit first, reveal later
SHA-256 is a one-way function. Feed it a string and you get a fixed 64-character result. The same input always gives the same output, and there is no practical way to run it backwards.
So publishing the hash of a secret proves you have already fixed that secret, without telling anyone what it is. Later you reveal the secret, and anyone can hash it and compare. A changed secret produces a completely different hash, and the swap is obvious to everyone.
A real implementation needs three things. Remove any one of them and the guarantee collapses, whatever the marketing page says:
- A commitment published before the round. Otherwise the outcome could have been picked afterwards.
- At least one input the operator does not control. Otherwise the operator can search for a secret that produces the result it prefers, then commit to that one.
- A full reveal afterwards, and enough detail to recompute. A hash you can never check is decoration.
How it works on Upgrader
There are two systems, because there are two kinds of game. Both are on the provably fair page, along with the exact code used to generate every outcome.
Games you play alone: cases, deals, upgrading, mines, keno
Three inputs:
- Server seed — a random string generated by us and stored encrypted. You never see it while it is in use, but you see its SHA-256 hash before you play. That hash is the commitment.
- Client seed — a random string that belongs to you. You can change it to anything you like, at any time.
- Nonce — a counter that increases by one every round, so the same pair of seeds never produces the same result twice.
The outcome comes from hashing the three together and using that hash to seed a random number generator:
outcome = SHA-256(clientSeed : serverSeed : nonce)The client seed is the part that matters most for you. Because you choose it and can change it whenever you want, we cannot work out results in advance for a seed you have not picked yet. The server seed is locked by a hash you were shown before the round. Neither side can move afterwards.
When you rotate your server seed, the old one is revealed to you. From that moment every round you played on it can be recomputed and checked.
Multiplayer rounds: battles, jackpot, coinflip
A battle produces one shared sequence of results for everyone in the lobby, so a personal client seed does not work. The unpredictable input has to come from somewhere outside the site entirely. We use the EOS blockchain.
Before the round starts we generate a random key and salt, and publish two things: the hash SHA-256(key : salt), and an EOS block number that has not been produced yet. When the network eventually produces that block, its block id becomes the third input:
outcome = SHA-256(key : salt : blockHash)The reason this is strong is that the commitment names the block in advance. We cannot know the hash of a block that does not exist, and we cannot go looking for a friendlier one later, because the block number was fixed and published before the round began. EOS is used rather than a better-known chain for a practical reason: it produces blocks about twice a second, so a round resolves in seconds instead of waiting on a ten-minute confirmation.
Crash uses a third arrangement, a pre-generated hash chain consumed backwards, so each round contains the proof of the one before it. Any past crash round can be looked up by ID on the crash tab of the fairness page.
| Solo games | Multiplayer rounds | |
|---|---|---|
| Games | Cases, deals, upgrading, mines, keno | Battles, jackpot, coinflip |
| Committed before | Hash of the server seed | Hash of key and salt, plus a future block number |
| Input we do not control | Your client seed | The EOS block hash |
| Revealed after | Server seed, on rotation | Key and salt, once the block exists |
| Checkable against | The hash you were shown | Any public EOS block explorer |
How a random number becomes an item
This is the step most discussions of provably fair skip, and it is the one that decides whether any of it means anything.
Each roll is a number between 0 and 1. It becomes a ticket:
ticket = floor(roll × 100,000) + 1Every item in a case owns a fixed ticket range inside 1 to 100,000, sized to match its listed odds. Hover an item card and you can see the exact range that item occupies. The ticket lands in one range, and that is what you unbox.
A verifiable roll with hidden ranges would prove nothing at all, because the mapping is where an outcome could quietly be made worse. Published ranges are what turns a verifiable number into a verifiable item. When you are judging any site, this is the question to ask after the seeds.
For battles the arithmetic is public too: total rolls = players × rounds + 1. Rolls are consumed in order, round by round and player by player in the order players joined, and the final roll is the decider used for jackpot mode, coinflip mode and ties. The same commitment covers the whole battle, so no part of it is drawn after the fact. The expected value of a trade is a separate question from whether the draw was honest, and worth understanding on its own.
How to verify a round, step by step
Everything below happens on the provably fair page.
- Note the commitment before you play. Your current server seed hash, client seed and nonce are all shown there. Set your own client seed if you want to; it costs nothing and it is the input that makes pre-computation impossible.
- Play the round. The nonce increases by one.
- Reveal the server seed. Generate a new one. Rotating retires the old seed and reveals it, and the History table then lists the ID, server seed, hashed server seed, client seed and nonce for the seeds you have used.
- Check the commitment first. Hash the revealed server seed with SHA-256 and compare it to the hash you were shown before playing. They must be identical. This is the check that catches a swapped seed, and it is the one people skip.
- Recompute the outcome. The outcome verifier on the page takes a client seed, server seed and nonce and returns the roll. For a battle or coinflip it takes the key, salt and block hash instead.
- Then do it somewhere that is not us. Each game tab carries the exact code sample that produced the result. Copy it into your own environment and run it. For multiplayer rounds, look the block hash up on any public EOS explorer rather than trusting the number on our page.
Step six is the point of the whole exercise. Verifying with the operator’s own tool only proves the operator is internally consistent. Recomputing independently is what makes the guarantee real, and it is why the formulas and the code are published rather than summarised.
What provably fair does not prove
It is worth being blunt, because the term gets used as though it settles every question.
Provably fair proves that a specific draw was not manipulated. It does not prove that the odds are good. A perfectly verifiable draw on a punishing house edge is still a punishing house edge, and the maths of the edge is a separate thing to look at. It says nothing about whether a site pays withdrawals, answers support, or stays solvent. And it does not protect you from your own staking decisions.
Anyone presenting provably fair as a reason to expect to win is misusing it. The correct claim is narrow and still valuable: the result you got is the result the committed inputs produced, and you can confirm that without asking us.
Why every site should be held to this standard
The cryptography involved is over a decade old, free to implement, and simple enough to explain in a page. There is no technical reason for a site handling real money not to have it.
Which makes its absence informative. A site without verifiable outcomes is asking for trust it has not offered any way to check. Use the same five questions on any site, including this one:
- Is something committed and shown to you before the round?
- Does an input come from outside the operator, either from you or from a public chain?
- Are the secrets fully revealed afterwards, with the nonce and seed history kept?
- Are the odds published as ranges you can check, not just a percentage on a card?
- Can you recompute the result outside their website, with published code?
Four out of five is not a pass. Each one removes a different way for a result to be quietly decided for you.
Common questions
Does changing my client seed improve my chances?
No. It changes which outcomes you get, not how likely any of them are. Its purpose is to remove any possibility that results were prepared in advance for the seed you were using.
Is the result decided before I press the button?
For solo games, yes, and deliberately so. Once the server seed is committed and your client seed and nonce are set, the outcome is already determined. That is the guarantee: it cannot be changed in response to your bet without breaking the hash you were shown.
Why EOS instead of Bitcoin?
Block time. EOS produces blocks roughly twice a second, so a round can commit to a future block and resolve moments later. A ten-minute block time would make a battle unplayable.
What if I lose track of my old seeds?
The History table on the fairness page keeps your retired server seeds along with their hashes, client seeds and nonces, so old rounds stay verifiable.
Do I have to trust your verifier?
No, and you should not have to. The code samples on each game tab are the same computation, published so you can run it yourself. Block hashes can be confirmed on any EOS explorer.