Part of the complete guide: Provably fair: the complete guide
The problem it solves
Blockchains are built so that every node reaches the same result from the same inputs. That makes real randomness awkward. A contract that uses the next block hash or a timestamp as "random" can be manipulated by whoever produces the block or by a user who simulates outcomes. For a lottery, where real money depends on the draw, that is not good enough. A VRF brings randomness in from outside the chain, with a proof the chain can check.
How a request works
- 1A smart contract, say a lottery, requests random values from the VRF service.
- 2The service generates one or more random values and a cryptographic proof of how they were determined.
- 3The proof is published and verified on-chain before the requesting contract can use the values.
- 4Because verification happens in the contract's own environment, no single party, including node operators, developers, users or block builders, can tamper with the result without the proof failing.
This matches Chainlink's own description of VRF: random values with a cryptographic proof that is verified on-chain before an application uses them.
How apps pay for it
Applications pay for each request, using LINK or the chain's native token. Chainlink describes two models: a subscription, where a funded account covers many consuming contracts, and direct funding, where each request is paid at the time it is made. Costs and options change, so read the current documentation when planning a project.
VRF versus a public beacon like drand
CryptoDrawz uses drand today. A future on-chain version might use either, depending on how the contract is designed.
| Feature | Chainlink VRF | drand beacon |
|---|---|---|
| Delivery | On request, to a smart contract | Published on a fixed schedule for anyone |
| Proof | Verified on-chain by the consuming contract | Signed values anyone can check against the network's public key |
| Who produces it | A decentralised oracle network | A group of independent organisations |
| Cost | Paid per request | Free to read |
| Best fit | Smart contracts that need randomness on demand | Scheduled draws, off-chain and on-chain consumers |
What VRF does not guarantee
- That ticket sales closed before the request. A contract must make sure nobody can buy after the request is made.
- That the contract's logic is correct, that payouts are right or that funds are safe.
- That the owner cannot pause, upgrade or drain the contract.
- That the game is legal or that the odds are good for you.
- That randomness will always arrive. Contracts need a safe fallback, such as a refund after a timeout.
How to check a lottery that says it uses Chainlink VRF
- 1Find the contract and confirm it calls the VRF coordinator, in the verified source code.
- 2Check on a block explorer that past draws show a request and a fulfilment transaction.
- 3Confirm sales are closed before the request.
- 4Check who can change the contract and whether a refund path exists if randomness fails.
Example: a lottery asking for a random number
A lottery contract has 1,000 tickets and closes sales at a set time. It then asks the VRF service for one random number. When the service answers, it sends the number and a proof. The VRF coordinator contract checks the proof on-chain. Only if it passes does the lottery contract receive the number. The lottery then takes the number modulo 1,000, which gives a ticket position from 0 to 999, and pays that ticket. If the proof fails, the number is rejected, and no prize is paid on a forged result. The key ordering: sales closed before the request, so nobody could buy a ticket knowing the outcome.
Alternatives to VRF
- Public randomness beacons such as drand, which publish values on a schedule.
- Commit-reveal schemes among participants.
- Block-hash based randomness, which is weak and generally not safe for valuable draws.
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
What does VRF stand for?
Verifiable random function: a function that outputs a random-looking value together with a proof it was computed correctly.
Is Chainlink VRF truly random?
It is designed to be unpredictable and verifiable. The guarantee is that results cannot be tampered with by any single party.
Is VRF better than drand?
They solve similar problems differently. VRF is on demand for contracts. drand is a public schedule anyone can read.
Does using VRF make a lottery safe?
No. It secures the random number. You still need to check custody, code and rules.
Who pays for VRF?
The application that requests randomness, in LINK or a native token.
Does VRF work on layer 2s?
Chainlink supports many networks, including layer 2s. Check current coverage.
Can a VRF result be predicted?
Not before it is produced, by design.