Onchain Atlas

Chainlink VRF Randomness

A cryptographic service that gives a smart contract a random number along with mathematical proof that nobody — including the service itself — could have rigged it.

Also called: verifiable random function · onchain randomness · provably fair randomness

What it is

Chainlink VRF (Verifiable Random Function) is an oracle service that supplies smart contracts with random numbers that come with a cryptographic proof of fairness. Blockchains are deterministic by design — every node must compute the same result — so a contract cannot generate true randomness on its own without exposing itself to manipulation. VRF solves this by having an offchain oracle generate the randomness and publish proof that it was produced honestly and can be independently verified onchain.

How it works

  1. A smart contract (say, an NFT mint or a game) calls the VRF coordinator contract, requesting a random number and paying a fee, usually in the oracle network's token (LINK).
  2. The request includes a seed and identifies which oracle node (or set of nodes) should service it.
  3. Offchain, the oracle computes a random value and a cryptographic proof using a private key, producing output that is unpredictable in advance but verifiable after the fact.
  4. The oracle submits the random number and proof back to the VRF coordinator contract in a callback transaction.
  5. The coordinator contract verifies the proof onchain using the oracle's known public key before accepting the number — if the proof doesn't check out, the value is rejected.
  6. Only after verification does the coordinator call back into the requesting contract with the verified random number, which the contract then uses (selecting a raffle winner, rolling loot stats, assigning traits).
  7. Because the proof is checked onchain, no party — not the requesting contract, not the oracle operator, not miners/validators — can retroactively pick a favorable result.

Why designers use it

  • Removes the ability for a contract deployer, miner/validator, or user to predict or bias an outcome that should be fair (drops, raffles, matchmaking, loot).
  • Produces an onchain, auditable proof of fairness, which is valuable for regulated or trust-sensitive use cases like gaming and gambling.
  • Avoids the classic pitfall of using blockhash or timestamp as a "random" seed, both of which can be manipulated or predicted by whoever controls block production.

Failure modes

  • Latency: randomness isn't instant — there's a request/callback delay, which some applications (real-time games) find awkward or which attackers can exploit if state is exposed between request and fulfillment.
  • Oracle/network dependency: if the VRF service or the underlying oracle network has downtime or a bug, requests stall and dependent contracts get stuck waiting.
  • Fee volatility: the LINK-denominated fee can fluctuate, complicating cost planning for high-volume use (many simultaneous NFT mints).
  • Misuse of the callback: if a contract acts on partial or unverified state before the VRF callback resolves, an attacker can sometimes front-run or reorder around the gap.
  • Centralization risk if a project uses a single oracle node instead of the decentralized VRF service, reintroducing a single point of manipulation.

What to check before using it

  • Is the randomness actually consumed only after the callback resolves, with no way to act on request-but-not-yet-fulfilled state?
  • What happens if the VRF request never gets fulfilled (stuck funds, stuck game state) — is there a timeout or fallback path?
  • Are gas and LINK fee costs budgeted for the expected request volume, especially for mints with unpredictable demand spikes?
  • Is the proof verification actually happening onchain (not just trusted from an offchain report)?
  • For gambling or lottery-adjacent use cases, does the jurisdiction require additional fairness certification beyond a technical VRF proof?

Experiments that used it · 2

Shown oldest first, so you can watch the design evolve.

CMD
A TokenWorks onchain game ('TenCommandements') in which the community collaboratively mutates a live ERC-20 across 10 randomized rounds — each round a paid prompt is picked by Chainlink VRF and patched into the contract — turning token design itself into the game.
2026 too early to judge
Fake World Assets
An onchain, verifiably-random NFT gacha protocol by TokenWorks where depositors back NFTs with ETH and buyers pay a pool-derived price to pull a random position, parodying the Real World Assets (RWA) narrative.
2026 ongoing