A die works because nobody at the table can freeze the air around it, look at the faces, and decide whether this throw counts. A blockchain is the opposite kind of machine. Every validator sees the same data. Every function, given the same inputs, must return the same outputs. If it did not, the nodes would not agree, and there would be no chain.
So you cannot put Math.random() in a contract and call it a day. There is no hidden entropy in the EVM. There is no private rand that stays private after it is used. If the contract could roll a secret die, the secret would still have to become public for the rest of the network to check the roll. At that point it is not a secret.
How onchain games work already said this: a chain cannot sample an honest die from inside itself. This page is the comparison. Naive onchain randomness is a known footgun. Commit-reveal and verifiable random functions exist to close that hole. They are not interchangeable. They do not make a game generous.
Studio RNG
A random-number generator in a game engine is usually a pseudorandom function. You seed it with something (the clock, a hardware source, a studio server) and it spits out a stream that looks noisy.
That is enough when one trusted party runs the match. The console does not need to prove the noise to a hostile network. If the studio cheats the drop table, your recourse is a review, not a proof.
On a public chain the audience is hostile by default. Bots read the mempool. Searchers will insert a transaction if the roll is profitable. Block proposers can see a candidate block and, in some designs, withhold it if the random result is ugly for them.
Studio RNG is a generator on one machine. It is not a proof.
Lab-certified RNG
Some offchain products advertise a hardware generator, a test-lab certificate, a sealed box. That can be a real property of a physical device. It is still a claim about a machine you do not run.
A certificate says a lab looked at a device, once. It does not put the roll on a chain. It does not let you recompute this round. Treat it as an operator promise with stationery, not as provably fair, and not as a VRF.
Naive onchain: blockhash and timestamp
The naive ideas fail in public.
Use block.timestamp. Coarse, and a proposer has slack.
Use blockhash. A proposer who dislikes the hash can skip the block. A contract that reads a future hash can be gamed if anyone can influence inclusion.
Use a private server number, then post it. That is an RNG with a press release. You have reinvented "trust us," which may be fine if you admit it.
None of these is a die. They are public, deterministic, or operator-held.
Commit-reveal
The oldest honest pattern is the one a dealer could run with envelopes.
- A party commits to a secret by publishing its hash.
- Later they reveal the secret.
- Anyone checks that
hash(secret)matches the commitment. - The secret is mixed into the roll.
In a two-player game, both sides can contribute entropy. In a house game, the house commits to a server seed in advance; the player supplies a client seed; a nonce counts the rounds. That is the skeleton of provably fair as it existed on dice sites — usually offchain.
Onchain, commit-reveal has a known wound: the revealer who sees they will lose can refuse to reveal. The contract must punish that, or the game stalls. Timeouts, bonds, and fallback entropy exist because of this sulk.
Commit-reveal also does not, by itself, stop a house from choosing a server seed that is lucky for the house over a long run. What it stops is a house that changes the seed after seeing your bet. Those are different cheats.
VRF: a proof that this output came from that key
A verifiable random function takes a secret key and an input (a seed, a block, a round id) and produces two things: an output, and a proof.
Anyone with the corresponding public key can check that the output is the unique result of that key on that input. The owner of the key cannot publish a different output for the same input without failing the proof. They also cannot skip generating it and pretend they rolled something else, unless they simply refuse to answer — in which case you are back to liveness, not honesty.
That is the property game contracts want from a randomness oracle: given that this key is the source, this roll is not a choice.
It is not the property "this key is a saint." If a single party holds the VRF key, they still choose when to request a roll, and they still chose to be the keyholder. A committee, a threshold scheme, or a well-known public service reduces that. It does not erase it.
VRF is also not "true randomness from the void." It is a deterministic function of key plus input, with a proof. The unpredictability comes from the key remaining secret until after the input is fixed, and from the input not being choosable by the person who would benefit.
Chainlink VRF is one instance of this class, not the class. Other constructions exist. Honest writing names the property (a proof that this output belongs to this key and this input), then names the instance if the contract actually calls it.
Commit-reveal vs VRF: related, not interchangeable
| Ordinary / studio RNG | Lab-certified RNG | Commit-reveal | VRF | |
|---|---|---|---|---|
| Secret at roll time | Yes, on one machine | Yes, in a device | Until reveal | Key stays secret; output becomes public |
| Third party can check this round | Not unless you publish the seed | Certificate is not a replay | Yes, after reveal | Yes, with the proof |
| Main failure | Operator lies or leaks | You never ran the box | Party refuses to reveal; seed grinding | Keyholder unavailability; bad input choice |
| Fits a public chain | Poorly, unless you trust the operator | No | Yes, with penalties | Yes, with a verifier contract |
When a pitch says "onchain RNG," ask which column they mean. Many mean "we called a library named Random." That is a naming accident.
Commit-reveal and VRF are cousins. Both try to stop a last-move swap. They are not the same machine. A reveal can be withheld. A VRF proof can be unavailable. Neither one is a kind game.
What a player can actually check
If the game is fully onchain, you can check:
- That the contract only proceeds when a proof verifies, or when a reveal matches a commit.
- That the input to the VRF was the input the rules promised (this round id, this block, this request id) and not a number the operator typed.
- That the mapping from random bytes to game outcomes is the mapping in the source.
You cannot check, from cryptography alone:
- That the house edge is a fair price. Fairness of price is not a hash.
- That you should be playing. Verification is not advice.
- That an offchain match used the same function. If the die rolled in a datacenter, the VRF on the payout contract may only be decorating the withdrawal.
Hidden information is a cousin, not a twin. A VRF can shuffle a deck. It cannot keep the cards face down on a transparent ledger without more machinery.
The sentence to take with you
A blockchain game cannot "just roll a die" because a die is a private physical event and a chain is a public deterministic replay. RNG is a generator. VRF is a generator plus a proof that this output belongs to this key and this input. Neither one makes the rules gentle. Both can be implemented, ignored, or faked in marketing.
If a title will not tell you which column it is in, it is not a randomness design. It is a slogan. For the slogan that came from casinos rather than from contracts, continue to what-provably-fair-means.
Next: what-provably-fair-means