Part of the complete guide: Provably fair: the complete guide
Why "trust me" is not enough
A random number generator hidden inside a company's servers can be honest or dishonest, and from the outside the two look identical. If real money depends on the output, you want evidence, not assurances.
Verifiable randomness gives that evidence. The generator produces a number plus something extra (a proof, a signature or a pre-commitment) that lets anyone confirm the number was produced by the rules.
Method 1: verifiable random functions (VRFs)
A VRF takes an input and a secret key and outputs a random-looking value together with a proof. Anyone with the matching public key can verify that the value really came from that input and key. The key holder cannot choose a different output for the same input.
Chainlink VRF is a widely used service built on this idea. Smart contracts request a random number, and the response is checked on-chain before it is accepted.
Method 2: public randomness beacons
A beacon publishes a fresh random value on a fixed schedule, for everyone. drand is a leading example. Its values are produced jointly by independent organisations, signed, and publicly archived.
Beacons are simple to use: pick the round that matches your time, fetch the value and verify its signature. They do not require a request, which makes them attractive for scheduled draws like a weekly lottery.
Method 3: commit-reveal
In commit-reveal, each participant first commits to a secret by publishing its hash. Later everyone reveals their secrets, and the random value is a combination of them. Because the hashes were published first, nobody can change their secret after seeing the others.
The weakness: the last person to reveal can refuse and withhold, which changes the outcome. Designs need penalties or fallbacks for that.
Comparing the three
| Property | VRF | Public beacon | Commit-reveal |
|---|---|---|---|
| Who produces the value | A key holder or network | A group of independent organisations | The participants themselves |
| Proof of fairness | Cryptographic proof per request | Signed value per round | Hashes published before reveal |
| Needs a request | Yes | No, values are published on a schedule | Needs participant actions |
| Main weakness | Trust in the key holder or network | Needs the network to stay honest and available | Withholding by the last revealer |
| Best fit | Smart contracts | Scheduled draws | Games with many active players |
What verification does and does not tell you
- It shows the number was generated by the stated process and not picked afterward.
- It does not make the game fair in other ways, such as the prize split.
- It does not prove the operator will pay prizes.
- It does not improve your odds of winning.
A simple analogy
Picture a notary who seals a coin toss result in an envelope in front of everyone, signs it, and publishes a photo of the signature. Later, when the envelope is opened, anyone can check the contents against the signed photo. The notary cannot swap the result because the signature would no longer match.
Verifiable randomness is that idea in mathematical form. The "envelope" is a commitment or a signature, and the "photo" is a hash or public key that anyone can use to check.
Why timing matters as much as proof
A proof that a number is genuine is not enough if someone could see it before betting. For a lottery, the ticket list must be closed before the random value exists. If tickets could be bought after the value is public, a buyer would simply buy the winning ticket. Good designs fix the order of events: tickets close, then the random value is produced.
How to evaluate a lottery's claim
- 1What produces the random number, and who controls it?
- 2Can the operator see or choose the number before tickets close?
- 3Is the number published with something you can verify?
- 4Is the rule from number to winners public and deterministic?
- 5Can you reproduce the winners yourself?
Ready?
A weekly draw you can check yourself.
$5 tickets, a public random value, and every result published with the data to recompute it.
Frequently asked questions
Is verifiable randomness the same as provably fair?
Related but not identical. Verifiable randomness proves the random number is genuine. "Provably fair" usually means the whole draw can be checked from published data.
Which method does CryptoDrawz use?
A public beacon: drand. We combine its value with a fingerprint of the closed ticket list.
Can a VRF be wrong?
The proof ensures the output matches the key and input. Trust still rests on the key holder not choosing favourable inputs.
Why not just use a normal random number function?
Because nobody can verify it. A normal generator gives you no evidence that the result was not chosen.