On-Chain Randomness Versus Server-Seed Provably Fair

The server-seed scheme, in one paragraph

The operator generates a server seed and publishes its hash before you play. Your client seed and an incrementing nonce are combined with the server seed via HMAC-SHA256, and the hash is mapped to an outcome by a published rule. When the server seed is later revealed, you can recompute every result in the series and confirm each one. The commitment — the published hash — is what makes the scheme work: the operator cannot choose a seed after seeing your bet, because the hash was already out.

What remains trusted

Three things. That the server seed was generated honestly rather than selected from a set the operator had pre-computed in its favour — the commitment fixes the seed, it does not prove how the seed was chosen. That the revealed seed is the committed one, which you can check by hashing it, and should. And that the mapping rule and the payout table are as described, which is a separate question entirely. The scheme is a cryptographic commitment, not an independence proof, and it works only for players who actually verify.

On-chain randomness: the stronger claim

A verifiable random function takes a seed and a private key and produces two outputs: a random value and a proof. Anyone holding the corresponding public key can check that the value was correctly derived from that seed — and crucially, the holder of the private key cannot produce a different valid value for the same seed. The output is therefore both unpredictable before the fact and verifiable after it, by anyone, without trusting either the casino or the randomness provider's good behaviour.

In a gambling contract the sequence runs: your bet is recorded on chain, the contract requests randomness, an oracle network returns a value with its proof, the contract verifies the proof on chain and settles. Every step is a public transaction. Nobody has to reveal a seed later, because nothing was hidden — and unlike the server-seed scheme, verification does not depend on you choosing to perform it.

What remains trusted here

Less, but not nothing. The oracle network can withhold a response, which is a liveness problem rather than a fairness one — the question then becomes whether the contract has a refund timeout, and a contract without one can leave a bet unresolved. The contract's own mapping from the random value to a game outcome and a payout is ordinary code and can be wrong or hostile, which is why reading the contract is still necessary. And the operator chooses when to request randomness, so the request-and-settle logic deserves a look.

Why naive on-chain randomness is worse than either

Some contracts generate randomness from chain data available to them: a block hash, a timestamp, a block number, or a combination hashed together. This is cheap and it is broken in a specific way — validators and block producers have influence over those values, and a bet whose outcome depends on the block it lands in can be manipulated by whoever decides what goes in the block. On a chain with a public transaction queue there is a second problem: an observer can see your bet before it is included and act on it.

A gambling contract whose randomness comes from a block hash is not provably fair in any useful sense, regardless of what the marketing says. It is the easiest thing to spot when reading the code, and it is the one finding that should end the evaluation.

The practical comparison

• Who can verify. Server seed: you, for your own bets, after the reveal. VRF: anyone, for any bet, immediately and permanently.
• What it rules out. Server seed: post-hoc alteration of your result. VRF: prediction and manipulation by anyone, including the operator.
• Cost and speed. Server seed: free and instant, which is why hosted casinos use it and can run thousands of bets a minute. VRF: a fee and a delay per request, which is why on-chain games feel slower and why some batch requests.
• Dependence on your diligence. Server seed: total — an unverified scheme protects nobody. VRF: none.
• Residual trust. Server seed: seed generation, honest reveal, payout table. VRF: oracle liveness, contract logic, payout table.
• What neither addresses. The house edge. Both mechanisms are about the draw. The multiplier table, the payout schedule and the edge built into them are a separate design decision that no fairness proof touches.

What to actually check, for each kind

At a hosted casino: verify once per site. Rotate the seed, hash the revealed server seed and confirm it matches the commitment you were shown, then recompute two or three outcomes with the published formula. Set your own client seed. If the game never reveals its server seed, the scheme has the shape of provable fairness without the substance.

At an on-chain casino: find the randomness source in the contract. If it is a VRF, confirm the request-and-fulfil transactions appear on chain for real bets, and find the timeout that refunds an unfulfilled request. If it is a block hash or a timestamp, stop there. Either way, read what the contract does with the number after it arrives, because that is where the edge lives.

Gambling is for adults and a verified random number is still a losing proposition in expectation. Fairness guarantees describe the draw, never the odds. If play has stopped being a choice, the free services listed on our responsible gambling page are independent of any operator.