Provably fair, explained for operators
How commit-reveal actually works, what it proves and what it does not, and why the operators who understand it end up with fewer support tickets than the ones who just put a badge on the page.
Provable fairness is a small cryptographic idea wearing a large marketing coat. The idea takes five minutes to understand, and understanding it is worth the time because it changes how you handle disputes.
The mechanism
Before a round begins, the server picks a random seed and publishes its hash.
The player supplies — or accepts a generated — client seed. When the round
runs, the outcome is derived deterministically from (server_seed, client_seed, nonce). After settlement, the server reveals the original seed.
Anyone can now verify two things: that the revealed seed hashes to the value committed before the bet, and that running the published derivation on those three inputs produces exactly the outcome that was paid.
That is it. No blockchain, no oracle, no third-party auditor in the loop.
What it actually proves
It proves the server could not have chosen the outcome after seeing the bet. The commitment is made first and is cryptographically binding, so the only way to change the result is to reveal a seed that does not match the published hash — which any verifier catches instantly.
That single property is what disputes are usually about. "The game waited until I bet big and then rigged it" is the accusation. Commit-reveal makes the accusation checkable rather than a matter of trust.
What it does not prove
Three things, and being honest about them is what separates a real implementation from a badge.
It does not prove the RTP. The derivation function determines the payout distribution, and provable fairness says nothing about whether that distribution is generous. A game can be perfectly provably fair and pay 80%. Verification confirms the outcome follows the published rules; the rules themselves are a separate, published fact. Ours are configurable per game and per currency, and the value in force is part of the round record.
It does not prove the server seed was random. A server could generate seeds from a predictable sequence, commit them honestly, and still be exploitable — by itself or by anyone who works out the pattern. This is why the client seed matters: mixing in a value the server did not choose means a predictable server seed alone is not enough to steer a specific player's outcome.
It does not stop a player losing. Every support agent learns this. A player who lost eleven times in a row will not be comforted by mathematics, but the conversation is much shorter when the answer is a URL where they can check the round themselves.
Where operators get value from it
The support one is concrete. Complaints about rigged outcomes stop being arguments and become verifications. You paste the round ID, the player recomputes, and the ticket closes. Teams that surface a verification link directly in the round history — rather than burying it in a help article — close these fastest.
The second is regulatory. When someone asks how outcomes are generated, you can hand over a mechanism instead of a vendor assurance. The seeds and the derivation are published; the auditor can recompute any historical round from your own logs without asking us for anything.
What to look for in an implementation
Ask three questions of any provider claiming provable fairness.
When is the hash published — before the bet is accepted, or with the result? Only the first is a commitment. If the hash arrives alongside the outcome, it proves nothing.
Can the player change their client seed, and does changing it reset the nonce? If the client seed is fixed by the server, the player is trusting the server's randomness completely.
Is the derivation function documented well enough to reimplement? If verifying requires the provider's own tool, you are still trusting the provider — you have just moved where.
All three of ours answer the way they should, which is the only reason the claim is worth making.