On-Chain Randomness: Chainlink VRF and Alternatives

Generating random numbers on a blockchain is fundamentally difficult — blockchains are deterministic by design. Every validator runs the same computation and gets the same result. This creates challenges for any application that needs unpredictability.

Why Naive Randomness Is Dangerous

block.timestamp: manipulable by validators by up to ~12 seconds. block.prevrandao (formerly difficulty): manipulable by validators who can choose to skip a block if the randomness doesn't favor them. Keccak256(block.timestamp, block.number, msg.sender): all these inputs are known to miners/validators before they produce the block. Any 'random' function derived from predictable block properties can be front-run or manipulated.

Chainlink VRF (Verifiable Random Function)

Chainlink VRF provides cryptographically verifiable randomness that cannot be manipulated by the requesting contract, the oracle, or any block producer. The VRF generates a random value and a proof that the value was correctly derived from a secret key. The contract can verify the proof on-chain, ensuring the randomness is unmanipulated.

How it works: your contract calls requestRandomWords(), VRF Coordinator emits a request event, Chainlink node generates the random value + proof off-chain, Chainlink node calls fulfillRandomWords() on your contract with the result, your contract processes the random value. The delay (1–3 blocks) is the main UX tradeoff.

Subscription Model

Fund a VRF subscription with LINK tokens. Your contract is added as a consumer of the subscription. Each randomness request consumes LINK from the subscription. For NFT mints with thousands of requests, subscription funding must be planned carefully. Cost: approximately 0.25 LINK per request on mainnet, much cheaper on L2s.

When to Use VRF

NFT trait assignment (randomize token IDs relative to traits). Lottery contract winner selection. Gaming (loot drops, critical hit chances, game world generation). Any on-chain game mechanic where manipulation would give an unfair advantage. VRF is required whenever the outcome has material value to any participant.

Alternatives for Lower-Stakes Use Cases

Commit-reveal schemes: participants commit to a value (hash), all reveal simultaneously, XOR of all reveals is the randomness. Manipulation-resistant if participants can't predict each other's values. Best for cases where all participants are known and must act in good faith. RANDAO (Ethereum's on-chain randomness from the beacon chain): reasonably secure for applications where manipulating the outcome would cost more than the benefit. Suitable for applications where the value is low enough that bribing validators isn't economically rational.