Every EVM chain is deterministic by design: every node must compute the same result from the same inputs, or consensus breaks. That property is exactly what makes randomness hard. A smart contract cannot call a random function, and the values developers reach for first, block hashes and timestamps, are influenced by the very block producers a fair application needs to defend against.
Chainlink VRF (Verifiable Random Function) is the most widely used answer to this problem. It delivers random values to smart contracts together with a cryptographic proof, and the proof is verified on chain before your contract ever sees the number. This article explains the actual mechanism, what changed in v2 and v2.5, how to integrate it correctly, and where its trade-offs sit against the alternatives.
Why On-Chain Randomness Is Hard
Before evaluating Chainlink VRF, it helps to understand why the naive approaches fail. Each of the common patterns breaks in a specific, exploitable way.
Block hashes and timestamps
Using blockhash or block.timestamp as a randomness source hands influence to whoever produces the block. A validator who stands to win a lottery can compute the outcome before publishing and simply discard blocks that make them lose. The attack costs only the forfeited block reward, so any prize worth more than that is unsafe. On top of that, anyone can read pending state, so a contract that derives randomness from on-chain values is predictable to searchers before the transaction lands.
Commit-reveal schemes
Commit-reveal fixes prediction: participants commit to hidden values, then reveal them, and the results are combined. The weakness is the last revealer. The final participant sees every other input before choosing whether to reveal, so they can abort whenever the outcome is unfavorable. Penalty bonds reduce the incentive but cannot remove it when the prize exceeds the bond, and the scheme adds a multi-transaction ceremony to every draw.
RANDAO
Ethereum's consensus layer mixes validator contributions into a shared randomness value, exposed to contracts as block.prevrandao. It is adequate for low-stakes uses, but a block proposer can still bias it by choosing to skip a slot, which gives one bit of influence per proposal. For applications where a single biased draw is expensive, that residual bias matters.
Centralized random APIs
Pulling numbers from an off-chain service reintroduces a trusted party. Users cannot verify that the operator did not re-roll until a favorable outcome appeared, and the service becomes a single point of failure and censorship. For gaming and financial applications, unverifiable randomness is a liability regardless of how honest the operator actually is.
| Approach | Predictable? | Biasable? | Main failure mode |
|---|---|---|---|
| Block hash / timestamp | Yes, before inclusion | Yes, by the block producer | Producer discards unfavorable blocks |
| Commit-reveal | No | Yes, by the last revealer | Selective abort when losing |
| RANDAO (prevrandao) | No | Slightly, by proposers | One bit of bias per skipped slot |
| Centralized API | No | Yes, by the operator | Unverifiable re-rolls, single point of failure |
| Chainlink VRF | No | No, proof rejects tampering | Node can withhold a response, not alter it |
What Is Chainlink VRF?
A verifiable random function is a cryptographic primitive: a keyed function that maps an input seed to an output that is indistinguishable from random, together with a proof that the output was computed correctly from that seed and that key. Anyone holding the public key can check the proof. Critically, the function is deterministic. For a given key and seed there is exactly one valid output, so the party running it cannot re-roll until it likes the result. Any tampering produces a proof that fails verification.
Chainlink VRF packages this primitive as an oracle service. Each VRF node operator registers a public key on chain. When a contract requests randomness, the node computes the VRF output over an elliptic-curve construction using its private key and a seed tied to the specific request, then submits the result and proof back on chain. The coordinator contract verifies the proof against the registered public key before delivering the value to the consumer. The security therefore does not rest on trusting the node: an honest-looking but manipulated value simply cannot pass on-chain verification. The full protocol and supported networks are documented in the official Chainlink VRF documentation.
How Chainlink VRF Works, Step by Step
1. The consumer contract requests random words
Your contract calls the VRF coordinator's request function with a handful of parameters: the key hash identifying which oracle key (and gas price lane) to use, a subscription or payment reference, the number of block confirmations to wait, a callback gas limit, and how many 256-bit random words you want. The coordinator logs the request as an event and assigns it a unique request ID.
2. The node waits for confirmations
The VRF node observing the coordinator does not respond immediately. It waits the number of confirmations you specified so that the block containing your request is unlikely to be reorganized away. This matters because the seed incorporates the blockhash of the request block: without the wait, a block producer could attempt to re-roll the seed by reorging the chain. More confirmations mean stronger protection and higher latency; the right setting depends on the value at stake.
3. The node computes the output and proof
The node derives the seed from the request parameters and the request block's hash, then evaluates the VRF with its private key. Because the computation is deterministic, the node has no discretion over the value. Its only possible misbehavior is not responding at all, which is visible on chain and slashable reputationally, rather than responding with a doctored number, which is cryptographically impossible without failing verification.
4. The coordinator verifies the proof on chain
The node submits a fulfillment transaction containing the random value and the proof. The coordinator contract runs the verification math against the node's registered public key. If the proof is invalid in any way, the transaction reverts and nothing reaches your contract. This on-chain check is the core trust guarantee: correctness is enforced by the EVM, not by the operator's honesty.
5. Your callback receives the random words
On successful verification, the coordinator calls your contract's fulfillRandomWords function with the request ID and the random values. From one 256-bit word you can derive as many additional values as you need by hashing the word with an index, so most applications request a single word and expand it locally rather than paying for several.
What Changed in VRF v2 and v2.5
The current versions refine the economics and ergonomics rather than the cryptography.
- Subscriptions. v2 introduced a subscription account: you fund one balance and attach multiple consumer contracts to it, instead of pre-loading each contract with LINK per request. Fulfillment costs draw down the subscription, which makes budgeting and monitoring far simpler for teams running several contracts.
- Direct funding. For low-volume or one-off use, a direct funding mode lets a contract pay per request without maintaining a subscription.
- Multiple words per request. A single request can return several random words, amortizing the verification overhead when an application genuinely needs independent values.
- Configurable confirmations and callback gas. Both are per-request parameters, so a high-stakes draw can wait longer while a cosmetic feature responds quickly.
- Native token payment. v2.5 added the option to pay fees in the chain's native token rather than LINK, removing a token-management step for teams that prefer it, and reworked request parameters to make future upgrades non-breaking.
New integrations should target v2.5. Older v1 and v2 integrations continue to work on some networks but the migration path is straightforward and documented.
What You Need to Integrate Chainlink VRF
The original requirement is modest: a contract on a supported network and a funded way to pay for requests. In practice, a production integration involves the following.
A supported network
VRF is live on the major EVM networks, including Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, and Avalanche. Check the current directory in the official documentation before committing to a chain, since coordinator addresses, key hashes, and fee configurations differ per network.
A consumer contract
Your Solidity contract inherits the VRF consumer base contract, stores the coordinator address and key hash, issues requests, and implements the fulfillRandomWords callback. The request-and-callback pattern means randomness arrives in a second transaction, so your application needs an explicit pending state between the two.
Funding
Requests are paid in LINK or, on v2.5, optionally in the native token. The cost of a fulfillment scales with the gas price at fulfillment time plus a service premium, so subscriptions should be monitored and topped up with alerting rather than by hand.
Callback discipline
The callback is where integrations most often go wrong. Three rules keep it safe:
- Never revert in the callback. A reverting callback burns the request; the coordinator will not retry. Validate inputs at request time, not fulfillment time.
- Keep the callback cheap. Store the random word and finish, then run heavy logic (minting, payouts, sorting) in a separate transaction. If the callback exceeds the gas limit you set at request time, fulfillment fails.
- Bind results to requests. Key all state by request ID so concurrent requests cannot cross-contaminate, and never let a user trigger a new request that could overwrite a pending one they dislike.
Where Chainlink VRF Is Used
NFT trait assignment and reveals
Collections use VRF to assign rarity traits or to select the offset for a batch reveal. Because the proof is public, the project can demonstrate after the fact that rare items were not steered to insiders, which is a claim no off-chain script can make credibly.
On-chain gaming
Loot drops, critical hits, matchmaking, and procedural content all need randomness that neither the player nor the studio can predict. The request-and-callback latency suits turn-based and asynchronous mechanics; real-time per-frame randomness stays client-side, with VRF anchoring the outcomes that carry economic value.
Lotteries, raffles, and prize draws
This is the canonical case: a visible prize pool and a strong incentive to cheat. VRF gives every participant the ability to verify the draw independently, and the confirmation delay protects against reorg-based re-rolls on the seed.
Fair selection in governance and operations
DAOs use VRF to select committee members, auditors, or grant reviewers at random, and protocols use it to randomize ordering where deterministic ordering would invite manipulation. Any process that currently relies on someone running a script and posting a screenshot is a candidate.
Trade-Offs to Weigh
Chainlink VRF is the strongest general-purpose option, but it is not free of costs.
- Latency. Randomness arrives after block confirmations plus a fulfillment transaction, typically tens of seconds to minutes depending on the chain and settings. Applications needing instant results must design around a pending state.
- Cost per request. On-chain proof verification consumes meaningful gas, and the premium is paid per request. Batch designs, single-word requests expanded by hashing, and drawing once per round rather than once per user keep costs proportionate.
- Liveness, not integrity, is the residual risk. A node cannot forge a value, but it can fail to respond. Choosing established node operators and monitoring unfulfilled requests covers the practical exposure.
How Webisoft Helps You Build with Chainlink VRF
Webisoft is a Montreal-based software and blockchain engineering firm that designs and ships smart contract systems end to end. For randomness-dependent products, that means selecting the right VRF version and network, structuring the request lifecycle and pending states, writing callback logic that cannot strand user funds, and setting up subscription monitoring so fulfillments never stall in production. If you are building a game, an NFT collection, or a protocol feature that has to prove its fairness, contact Webisoft to review your architecture before you deploy it.
Chainlink VRF is an oracle service that delivers random numbers to smart contracts along with a cryptographic proof. The proof is checked on chain before your contract receives the value, so neither the oracle nor anyone else can substitute a manipulated number.
EVM execution is deterministic: every node must reach the same result, so there is no native source of randomness. On-chain values like block hashes and timestamps are influenced by block producers, who can discard unfavorable blocks when the stakes justify it.
No. The VRF is deterministic for a given key and seed, so there is exactly one valid output, and the on-chain proof verification rejects anything else. The only misbehavior available to a node is not responding at all, which is visible on chain and does not corrupt any result.
The node waits the number of block confirmations you configure, then submits a fulfillment transaction, so results typically arrive in tens of seconds to a few minutes depending on the network. Applications should hold an explicit pending state between request and callback.
v2 introduced subscriptions, multiple random words per request, and configurable confirmations and callback gas. v2.5 added the option to pay in the chain's native token instead of LINK and restructured request parameters so future upgrades are non-breaking. New projects should build on v2.5.
Reverting inside the callback (which burns the request), putting heavy logic in the callback so it exceeds the gas limit, and failing to key state by request ID so concurrent requests interfere. Validate at request time, store the word cheaply, and process results in a separate transaction.
