"Provably fair" gets stamped on a lot of systems that are not, in any rigorous sense. It won’t be an exaggeration to say that the phrase has drifted into marketing, where it tends to mean "trust us, there is cryptography involved."

The actual guarantee is more straightforward, narrower, more useful, and easier to check than the marketing version, and it is worth stapling down exactly before you rely on it or build with it.

These notes cover how verifiable randomness works, the difference between commit-reveal and VRFs, and the places a "provably fair" claim quietly stops applying.

The claim being made

The provably fair means a user can verify that a specific random outcome was not manipulated by the operator and the operator could not have chosen the result after seeing the inputs. It does not mean the outcome is trustless in every sense, and it does not mean the system is fair in the everyday sense of good odds.

It's important to keep this scope in mind because most arguments about fairness are really arguments about two people using the word differently.

Commit-reveal is the baseline

The most common off-chain and oldest pattern is commit-reveal. Here is how it goes:

1. The server generates a secret serverSeed and publishes hash(serverSeed) before play.

2. Client supplies its own clientSeed.

3. Outcome is derived from hash(serverSeed + clientSeed + nonce).

4. After the round, the server reveals serverSeed. Anyone recomputes the hash, checks it against the commitment from step 1, then recomputes the outcome.

It guarantees the server cannot change its seed after seeing the client input without breaking the published hash, and the client cannot bias the outcome because it never sees the server seed in advance. Neither side has to trust the other, which is basically the whole point.

What it does not cover is the part people forget, which is that commit-reveal proves a given round was not tampered with. It says nothing about an operator who selectively stalls rounds, quietly drops sessions that went badly for the house, or controls the entropy feeding serverSeed in the first place. The proof is real, but it is local to the round, and a local proof wrapped in a dishonest system is still a dishonest system.

On-chain VRFs

A verifiable random function produces a random output together with a cryptographic proof that the output was generated correctly from a given input and a private key. Anyone with the public key can verify the proof, which makes sure that nobody can predict or forge the output.

On-chain is pretty similar to what Chainlink VRF does. A contract requests randomness and as a result an oracle returns the value plus a proof, and the contract verifies that proof on-chain before it uses the value. Both the randomness and its verification live somewhere the operator does not control which closes the entropy-source gap that plain commit-reveal leaves wide open.

A lot of web3-era gaming moved towards this direction, which is why the line between a regulated operator and an on-chain protocol has gotten blurry. For example, a licensed and noteworthy online casino in Ireland answers to independent RNG certification under its regulator, and an on-chain protocol leans on a VRF whose proofs anyone can pull up on a block explorer.

Different trust anchors, same question underneath: can someone who does not trust the house still check the result?

In practice, the two are starting to show up together rather than as rivals: certification for the licensing, on-chain proofs for the players who want to verify things themselves.

Where it breaks

The failures are rarely in the cryptography and mostly in the wiring around it.

The classic example could be using block.timestamp or blockhash as a randomness source because both are influenced by whoever produces the block, so anything of value riding on them is exploitable by a motivated validator. Treat block variables as untrusted input, never as entropy.

Reveal timing is the subtler trap i.e., if an outcome becomes computable the instant a seed is revealed, someone watching the mempool can act on it before the state catches up, which is just front-running with extra steps.

A VRF proof guarantees the output was computed correctly, not that the input was any good. Feed it weak entropy and you get a perfectly verifiable bad random number. The proof is honest about the math and silent about the quality.

Most provably fair stacks tend to be hybrids where the provable part covers the dice roll but not the wallet logic, the payout queue, or the matchmaking wrapped around it. This is very important to highlight because that is usually where the actual money leaks.

Here is what to actually check

When someone hands you a "provably fair" claim, the useful move is to ask exactly which rounds, which components, and which trust assumptions the proof covers, and then look hard at everything it does not.

The honest systems can answer that question without flinching, but the marketing ones change the subject because of no solid answers.