Provably fair is described everywhere and explained almost nowhere. The actual mechanism is a commitment scheme with three inputs, and understanding it takes about five minutes.
Here is what happens between you pressing bet and a number appearing.
Six Steps From Bet to Number
Each one does a specific job, and removing any of them breaks the guarantee.
-
The casino generates a server seed and publishes its hash. Before you bet anything, it creates a secret value and shows you only a SHA-256 or SHA-512 hash of it. This is the commitment. Because hashes are one-way, the operator cannot later find a different value producing that same hash, so it is locked into whatever it committed to.
-
You supply a client seed. Your browser generates one by default, and you can and should change it. This input is the part that stops the operator from computing results in advance and choosing which to serve, because it cannot predict a value you chose after it committed.
-
A nonce counts your bets. It starts at zero or one and rises by one per round. Without it, a hundred bets on the same seed pair would return the same number a hundred times.
-
The three values combine through a hash function. Two implementation families exist. The simpler joins the values into one string and hashes it with SHA-256. The more common uses HMAC, with the server seed as the key and the client seed, nonce and sometimes a cursor as the message. The cursor is what lets a single round produce more than one number, which games like blackjack need.
-
The digest converts to a game outcome. The hexadecimal output is turned into a number and mapped onto the game's result space, so a dice roll becomes 73.24 and a crash game becomes a multiplier.
-
The server seed is revealed at rotation. Once you rotate, the original seed is published. You hash it yourself to confirm it matches the commitment from step one, then recompute any round from that period and compare against your history.
If your recomputed output matches what the game showed, that round was not altered. If it does not, you have cryptographic proof of tampering.
One Correction Worth Making
This appears in a great deal of coverage and it is wrong.
Provably fair is almost never on-chain. The commitment sits on the operator's server and the verification happens in your browser. No blockchain is involved in the mechanism at any point.
Blockchain settlement is a completely separate design decision. A platform can record settled bets on a public chain, run provably fair games, both, or neither, and the two answer different questions: on-chain recording covers what was paid, while provably fair covers how the outcome was generated.
Conflating them leads people to assume a platform advertising on-chain settlement has verified games, or that a provably fair game leaves a public record. Neither follows.
Crash Games Work Slightly Differently
Worth knowing if you play them, because the structure is not the one described above.
High-pace games frequently use a hash chain: each round's hash is the input for the next, and the sequence runs backwards from a terminating hash published in advance. Bustabit popularised this approach.
The consequence is that an entire cycle of outcomes is determined before the first round of it is played. Any mid-stream tampering breaks the chain's integrity and becomes detectable afterwards, which is the same guarantee arriving by a different route.
Aviator uses SHA-512 with three client seeds instead of one. SHA-256 and SHA-512 offer equal cryptographic strength, differing in output length and the number of inputs, not in strength.
Four Things Verification Does Not Do
Each of these is assumed regularly and none of them holds.
-
It does not improve your odds. Changing your client seed alters which outcomes are generated, not whether they are favourable. The HMAC output is uniformly distributed regardless of what you put in.
-
It does not change the house edge. The edge sits in the paytable and applies identically whether or not you verify a single round.
-
It does not make losing suspicious. Loss alone is not evidence of manipulation, and verification works the same on a round you won and one you lost.
-
It does not protect you unless you use it. The system is available, not automatic, and an unverified round is functionally identical to an unverifiable one.
Judging an Implementation
Since not all of them are equal, a few signals distinguish a real system from a decorative one.
-
You can see and edit your client seed, not just accept a generated one
-
A nonce or bet index appears in your history, so individual rounds are addressable
-
Documentation or sample code explains the formula, and a verification tool is linked
-
Support answers a manual verification question with seeds, hashes and a formula
Where those are missing, the label is doing work the implementation is not, and understanding the mechanism is what lets you tell the difference.
On most crypto casinos, the tooling belongs to the studio and not the operator, since platforms licensing their catalogues inherit whatever each provider built.
Dexsport works this way across its arcade section, so the fairness interface for each title comes from whoever developed it. Its own contribution is separate: settlement written to a public on-chain desk, which is the other question entirely.
Confirm what is legal where you live, keep stakes within a set budget, and play only if you are of legal age, since KYC or AML checks may apply. Responsible gambling sits outside all of this, since a cryptographically verified game with a 4% house edge still costs 4% of everything staked through it.
Disclaimer: The information here is provided for general purposes only and is not legal, tax, investment, or financial advice. Provably fair implementations vary by studio and platform, so consult the specific game's documentation before relying on any verification process. Betting carries risk, and rules vary by country, so check the law where you live. Please gamble responsibly, within your means, and only if you are of legal age.
