ctfnote
  • /home/ret2basic.eth
  • Game Hacking
    • βœ…C++
    • Ghidra
    • Cheat Engine
    • Proxy
    • DLL injection
    • Keygen
    • Aimbot
  • Web3 Security Research
    • πŸ‘‘Web3 Security Research Trivia
    • βœ…Solidity
      • βœ…Mastering Ethereum
      • βœ…Storage
      • βœ…Memory
      • βœ…Calldata
      • βœ…ABI
    • βœ…Foundry
      • βœ…Introduction
      • βœ…How to Write Basic Tests
      • βœ…Set Soliditiy Compiler Version
      • βœ…Remappings
      • βœ…Auto Format Code
      • βœ…Console Log
      • βœ…Authentication
      • βœ…Error
      • βœ…Event
      • βœ…Time
      • βœ…Send ETH
      • βœ…Signature
      • βœ…Fork
      • βœ…Mint 1 Million DAI on Mainnet Fork
      • βœ…FFI
      • βœ…Fuzz
      • βœ…Invariant Testing - Part 1
      • Invariant Testing - Part 2
      • Invariant Testing - Part 3
      • Differential Test
    • βœ…Secureum
      • βœ…Epoch 0
        • βœ…Slot 1: Ethereum 101
          • βœ…Notes
          • βœ…Ethereum Whitepaper
          • βœ…Extra Study: What happens when you send 1 DAI
          • βœ…Quiz
        • βœ…Slot 2: Solidity 101
          • βœ…Notes
          • βœ…OpenZeppelin ERC20
          • βœ…OpenZeppelin ERC721
          • βœ…OpenZeppelin Ownable
          • βœ…OpenZeppelin Pausable
          • βœ…OpenZeppelin ReentrancyGuard
          • βœ…Quiz
        • βœ…Slot 3: Solidity 201
          • βœ…Notes
          • βœ…OpenZeppelin SafeERC20
          • βœ…OpenZeppelin ERC-777
          • βœ…OpenZeppelin ERC-1155
          • βœ…OpenZeppelin ERC-3156
          • βœ…OpenZeppelin - Proxy Upgrade Pattern
          • βœ…Quiz
        • βœ…Slot 4: Pitfalls and Best Practices 101
          • βœ…Notes
          • βœ…Intro to Security First Development
          • βœ…Quiz
        • βœ…Slot 5: Pitfalls and Best Practices 201
          • βœ…Notes
          • So you want to use a price oracle
          • The Dangers of Surprising Code
          • βœ…Quiz
        • βœ…Slot 6: Auditing Techniques & Tools 101
          • βœ…Notes
          • βœ…Quiz
        • βœ…Slot 7: Audit Findings 101
          • Notes
          • βœ…Fei Protocol - ConsenSys
          • βœ…Uniswap V3 - Trail of Bits
          • βœ…Chainlink - Sigma Prime
          • βœ…Opyn Gamma - OpenZeppelin
          • βœ…Quiz
        • βœ…Slot 8: Audit Findings 201
          • Notes
          • 1inch Liquidity - Consensus
          • Original Dollar - Trail of Bits
          • Synthetix EtherCollateral - Sigma Prime
          • Holdefi - OpenZeppelin
          • Quiz
      • βœ…Epoch ∞
        • βœ…RACE #4 - ERC20 Implementation
        • βœ…RACE #5 - ERC1155 Implementation
        • βœ…RACE #6 - ERC721 Application
        • βœ…RACE #7 - Bored Ape
        • βœ…RACE #8 - ERC721 Roles
        • βœ…RACE #9 - Proxy
        • βœ…RACE #10 - Test Cases
        • βœ…RACE #11 - Staking
        • βœ…RACE #12 - ERC20 Permit
        • βœ…RACE #13 - ERC20 with Callback
        • βœ…RACE #14 - Lending
        • βœ…RACE #15 - DEX
        • βœ…RACE #16 - Flash Loan
        • βœ…RACE #17
    • DeFi
      • Glossary
        • TWAP vs. VWAP
        • Tranches
      • DeFi MOOC
        • Lecture 2: Introduction to Blockchain Technologies
        • Lecture 5: DEX
        • Lecture 6: Decentralized Lending
        • Lecture 10: Privacy on the Blockchain
        • Lecture 12: Practical Smart Contract Security
        • Lecture 13: DeFi Security
      • Uniswap V2
      • Compound V3
        • βœ…Whitepaper
        • βœ…Interacting with Compound
          • βœ…Supply and Redeem
          • βœ…Borrow and Repay
          • βœ…Liquidation
          • βœ…Long and Short
        • βœ…Interest Model
        • CToken
      • Aave
      • Chainlink
        • βœ…Getting Started
        • βœ…Data Feeds
        • βœ…VRF
      • Optimism
        • Bedrock
      • LayerZero
      • Opensea
        • Seaport
    • EVM
      • βœ…Andreas Antonopoulos - The Ethereum Virtual Machine
      • βœ…Program The Blockchain - Smart Contract Storage
      • βœ…EVM Codes - EVM Playground for Opcodes
      • βœ…Fvictorio - EVM Puzzles
      • βœ…Daltyboy11 - More EVM Puzzles
      • βœ…EVM Through Huff
      • Noxx - EVM Deep Dives
      • βœ…Jordan McKinney - EVM Explained
      • Openzepplin - Deconstructing a Solidity Contract
      • Jeancvllr - EVM Assembly
      • Peter Robinson - Solidity to Bytecode, Memory & Storage
      • Marek Kirejczyk - Ethereum Under The Hood
      • βœ…Official Solidity Docs
      • Dissecting EVM using go-ethereum Eth client implementation - deliriusz.eth
    • Vulnerabilities
      • Rounding Issues
        • Kyberswap
      • Bridges
      • Governance / Voting Escrows
      • Bizzare Bug Classes
        • TIME - ERC2771Context + Multicall calldata manipulation
    • Fancy Topics
      • Vulnerabilities SoK
        • βœ…Demystifying Exploitable Bugs in Smart Contracts
        • Blockchain Hacking Techniques 2022 Top 10 - Todo
      • yAcademy
        • Proxies
          • yAcademy - Proxy Basics
          • yAcademy - Proxies Deep Dive
          • yAcademy - Security Guide to Proxy Vulns
        • defi-fork-bugs
      • Spearbit
        • βœ…Community Workshop: Riley Holterhus
        • Economic Security with fmrmf
        • Numerical Analysis for DeFi Audits: A TWAMM Case Study by Kurt Barry
  • Red Teaming
    • βœ…Enumeration
      • Service Enumeration
        • SMTP (Port 25)
        • Samba (Port 139, 445)
        • SNMP (Port 161,162,10161,10162)
        • rsync (Port 873)
        • NFS (Port 2049)
        • Apache JServ Protocol (Port 8081)
        • NetBIOS
      • Nmap
      • Gobuster / Feroxbuster / FUFF / Wfuzz
      • Drupal
    • βœ…Exploitation
      • Public Exploits
      • PHP Webshells
      • Reverse Shell
      • TTY
      • File Transfer
      • Metasploit
      • Password Spray
    • βœ…Buffer Overflow
      • Step 0: Spiking (Optional)
      • Step 1: Fuzzing
      • Step 2: Finding the Offset
      • Step 3: Overwriting the EIP
      • Step 4: Finding Bad Characters
      • Step 5: Finding the Right Module
      • Step 6: Generating Shellcode and Gaining Root
    • βœ…Privilege Escalation
      • Linux Privilege Escalation
        • Linux Permissions
        • Manual Enumeration
        • Automated Tools
        • Kernel Exploits
        • Passwords and File Permissions
        • SSH Keys
        • Sudo
        • SUID
        • Capabilities
        • Cron Jobs
        • NFS Root Squashing
        • Docker
        • GNU C Library
        • Exim
        • Linux Privilege Escalation Course Capstone
      • Windows Privilege Escalation
        • Manual Enumeration
        • Automated Tools
        • Kernel Exploits
        • Passwords and Port Forwarding
        • WSL
        • Token Impersonation and Potato Attacks
        • Meterpreter getsystem
        • Runas
        • UAC Bypass
        • Registry
        • Executable Files
        • Startup Applications
        • DLL Hijacking
        • Service Permissions (Paths)
        • CVE-2019-1388
        • HiveNightmare
        • Bypass Space Filter
    • βœ…Post Exploitation
      • Linux Post Exploitation
        • Add a User
        • SSH Key
      • Windows Post Exploitation
        • windows-resources
        • Add a User
        • RDP
    • βœ…Pivoting
      • Windows: Chisel
      • Linux: sshuttle
    • Active Directory (AD)
      • Initial Compromise
        • HTA Phishing
        • VBA Macro Phishing
        • LLMNR Poisoning
        • SMB Relay
        • GPP / cPassword
      • Domain Enumeration
        • Manual Enumeration
        • PowerView
        • BloodHound
      • Lateral Movement
        • PsExec
        • WMI
        • Runas
        • Pass the Hash
        • Overpass the Hash
        • Pass the Ticket
      • Kerberos
        • Kerberoast
        • AS-REP Roast
      • MS SQL Server
    • Command & Control (C2)
      • Cobalt Strike
        • Bypassing Defences
          • Artifact Kit
          • Resource Kit
          • AMSI Bypass
          • PowerPick
        • Extending Cobalt Strike
          • Elevate Kit
          • Malleable C2 Profile
      • Metasploit
        • Payloads
        • Post Exploitation
        • Automation
      • C2 Development
    • Malware Development
      • "Hot Dropper"
      • PE Format
        • Overview
      • Process Injection
      • Reflective DLL
      • x86 <=> x64
      • Hooking
      • VeraCry
      • Offensive C#
      • AV Evasion
        • AV Evasion with C# and PowerShell
        • AMSI Bypass
  • Cryptography
    • Hash Functions
    • MAC
    • AES
      • Byte at a Time
      • CBC CCA
      • CBC Bit Flipping
      • CBC Padding Oracle
    • Diffie-Hellman
    • RSA
      • Prime Factors
      • Multiple Ciphertexts
      • Low Public Exponent
      • Low Private Exponent
    • ECC
    • Digital Signature
    • JWT
    • PRNG
    • SSL/TLS
    • Research
      • βœ…Lattice-based Cryptography (Lattice)
      • Elliptic Curve Cryptography (ECC)
      • Oblivious Transfer (OT)
      • Secure Multi-party Computation (MPC)
      • Learning with Error (LWE)
      • Fully Homomorphic Encryption (FHE)
      • Zero Knowledge Proof (ZKP)
      • Oblivious RAM (ORAM)
  • Computer Science
    • Linux
      • Setup
      • curl
      • Hard Link vs. Symlink
      • Man Page
      • /dev/null
    • Python
      • New Features
      • Operators, Expressions, and Data Manipulation
      • Program Structure and Control Flow
      • Objects, Types, and Protocols
      • Functions 101
      • Generators
      • Classes and Object-Oriented Programming
      • Memory Management
      • Concurrency and Parallelism
        • Multithreading and Thread Safety
        • Asynchronization
        • Multiprocessing
        • Global Interpreter Lock (GIL)
      • Built-in Functions and Standard Library
        • import collections
        • import itertools
        • import sys
        • import re
        • import pickle
        • import json
      • Third-party Library
        • from pwn import *
        • import requests
        • from bs4 import BeautifulSoup
        • from scapy.all import *
        • py2exe
    • HTML, CSS, JavaScript, and React
      • HTML
      • CSS
      • JavaScript
        • var vs. let
        • Objects
        • Arrays
        • Functions
        • Modules
        • Asynchronous JavaScript
      • React
    • Data Structures and Algorithms
      • Binary Search
    • The Linux Programming Interface
      • Processes
        • Memory Allocation
        • The Process API
        • Process Creation
        • Process Termination
        • Monitoring Child Processes
        • Program Execution
      • Signals
      • Threads
        • Thread Synchronization
        • Thread Safety and Pre-Thread Storage
      • IPC
        • Pipes and FIFOs
        • Memory Mappings
        • Virtual Memory Operations
      • Sockets
    • Computer Systems
      • Hexadecimal
      • Signedness
      • Registers
      • Instructions
      • Syscall
      • Process Memory
      • Stack Frame
      • Preemptive Multitasking
      • IPC
      • Threads
    • Databases
      • MySQL
        • Basic Syntax
        • Data Types
        • Modifying Tables
        • Duplicating and Deleting
        • SELECT
        • Transaction
      • GraphQL
    • Distributed Systems
      • Introduction
        • What is a Distributed System?
        • Design Goals
        • Scaling Techniques
        • Types of Distributed Systems
      • Architecture
        • System Architectures
        • Example Architectures
      • Communication
        • Foundations
        • Remote Procedure Call
        • Message-oriented Communication
      • Coordination
        • Clock Synchronization
        • Logical Clock
      • Consistency and Replication
        • Introduction
        • Data-centric Consistency
        • Client-centric Consistency
    • Static Analysis
      • Intermediate Representation
      • Data Flow Analysis
      • Interprocedural Analysis
      • Pointer Analysis
      • Static Analysis for Security
      • Datalog-Based Program Analysis
      • Soundness and Soundiness
      • CFL-Reachability and IFDS
  • Web
    • βœ…Prerequisites
      • OWASP Top 10
        • 1. Broken Access Control
        • 2. Cryptographic Failures
        • 3. Injection
        • 4. Insecure Design
        • 5. Security Misconfiguration
        • 6. Vulnerable and Outdated Components
        • 7. Identification and Authentication Failures
        • 8. Software and Data Integrity Failures
        • 9. Security Logging and Monitoring Failures
        • 10. SSRF
      • HTTP
        • HTTP Status Codes
        • HTTP Headers
      • Burp Suite
        • Burp Intruder
        • Burp Extender
        • Burp Collaborator
      • Information Gathering
        • DNS
        • Git
        • Editor
        • Server
      • Bug Bounty Report Writing
    • File Upload
      • Webshell
      • IIS, Nginx, and Apache Vulnerabilities
      • .htaccess (Apache) / web.config (IIS)
      • Alternate Data Stream
      • Code Review: bWAPP Unrestricted File Upload
    • SQL Injection (SQLi)
      • Cheat Sheet
      • UNION Attacks
      • Examining the Database
      • Blind SQL Injection
      • WAF Bypass
      • Out-Of-Band (OOB)
      • Webshell and UDF
      • sqlmap
        • Code Review: Initialization
        • Code Review: tamper
    • Cross-Site Scripting (XSS)
      • Cheat Sheet
      • Reflected XSS
      • Stored XSS
      • DOM-Based XSS
      • XSS Contexts
      • CSP
    • CSRF and SSRF
      • Client-Side Request Forgery (CSRF)
        • XSS vs. CSRF
        • CSRF Tokens and SameSite Cookies
      • Server-Side Request Forgery (SSRF)
        • Attacks
        • Bypassing Restrictions
        • SSRF + Redis
    • XML External Entities (XXE)
    • Insecure Deserialization
      • Python Deserialization
      • PHP Deserialization
      • Java Deserialization
        • Shiro
        • FastJSON
        • WebLogic
    • HTTP Request Smuggling
    • OS Command Injection
      • Whitespace Bypass
      • Blacklist Bypass
      • Blind OS Command Injection
      • Lab 1: HITCON 2015 BabyFirst
      • Lab 2: HITCON 2017 BabyFirst Revenge
      • Lab 3: HITCON 2017 BabyFirst Revenge v2
    • βœ…Directory Traversal
    • HTTP Parameter Pollution
    • Server-Side Template Injection (SSTI)
    • LDAP Injection
    • Redis
      • Authentication
      • RCE
      • Mitigations
  • Pwn
    • Linux Exploitation
      • Protections
      • Shellcoding
        • Calling Convention
        • Null-free
        • Reverse Shell
        • ORW
      • ROP
        • Stack Alignment
        • ret2text
        • ret2syscall
        • ret2libc
        • ret2csu
        • BROP
        • SROP
        • Stack Pivot
      • ptmalloc
        • chunks
        • malloc() and free()
        • bins
        • tcache
      • UAF
      • Race Conditions
        • TOCTTOU
        • Dirty Cow
        • Meltdown
        • Spectre
      • Kernel
      • Appendix: Tools
        • socat
        • LibcSearcher-ng
        • OneGadget
    • Windows Exploitation
      • Classic
      • SEH
      • Egghunting
      • Unicode
      • Shellcoding
      • ROP
      • Appendix: Tools
        • ImmunityDbg
        • Mona.py
    • Fuzzing
      • AFL++
        • Quickstart
        • Instrumentation
        • ASAN
        • Code Coverage
        • Dictionary
        • Parallelization
        • Partial Instrumentation
        • QEMU Mode
        • afl-libprotobuf-mutator
      • WinAFL
      • Fuzzilli
  • Reverse
    • Bytecode
      • Python Bytecode
    • πŸ‘‘Z3 solver
    • angr
      • angr Template
Powered by GitBook
On this page
  • Introduction to Chainlink VRF
  • Two methods to request randomness
  • Security Considerations
  • Use requestId to match randomness requests with their fulfillment in order
  • Choose a safe block confirmation time, which will vary between blockchains
  • Do not re-request randomness
  • Don’t accept bids/bets/inputs after you have made a randomness request
  • fulfillRandomWords must not revert
  • Use VRFConsumerBaseV2 in your contract, to interact with the VRF service
  • Use VRFv2WrapperConsumer.sol in your contract, to interact with the VRF service
  • Best Practices
  • Getting a random number within a range
  • Getting multiple random values
  • Processing simultaneous VRF requests
  • Processing VRF responses through different execution paths

Was this helpful?

  1. Web3 Security Research
  2. DeFi
  3. Chainlink

VRF

PreviousData FeedsNextOptimism

Last updated 1 year ago

Was this helpful?

Introduction to Chainlink VRF

Chainlink VRF (Verifiable Random Function) is a provably fair and verifiable random number generator (RNG) that enables smart contracts to access random values without compromising security or usability. For each request, Chainlink VRF generates one or more random values and cryptographic proof of how those values were determined. The proof is published and verified on-chain before any consuming applications can use it. This process ensures that results cannot be tampered with or manipulated by any single entity including oracle operators, miners, users, or smart contract developers.

Use Chainlink VRF to build reliable smart contracts for any applications that rely on unpredictable outcomes:

  • Building blockchain games and NFTs.

  • Random assignment of duties and resources. For example, randomly assigning judges to cases.

  • Choosing a representative sample for consensus mechanisms.

To learn more about the benefits of Chainlink VRF v2, see our blog post . For help with your specific use case, to connect with one of our Solutions Architects. You can also ask questions about Chainlink VRF on .

Two methods to request randomness

Chainlink VRF v2 offers two methods for requesting randomness:

  • : Create a subscription account and fund its balance with LINK tokens. Users can then connect multiple consuming contracts to the subscription account. When the consuming contracts request randomness, the transaction costs are calculated after the randomness requests are fulfilled and the subscription balance is deducted accordingly. This method allows you to fund requests for multiple consumer contracts from a single subscription.

  • : Consuming contracts directly pay with LINK when they request random values. You must directly fund your consumer contracts and ensure that there are enough LINK tokens to pay for randomness requests.

Security Considerations

This section is the most important thing in Chainlink doc. Make sure you read it multiple times.

Gaining access to high quality randomness on-chain requires a solution like Chainlink’s VRF, but it also requires you to understand some of the ways that miners or validators can potentially manipulate randomness generation. Here are some of the top security considerations you should review in your project.

Use requestId to match randomness requests with their fulfillment in order

My comment Requests without ID could come back in a different order. For example, requests sequence sent out as [A, B, C] might return as [C, A, B]. Use requestId to avoid requests race condition

If your contract could have multiple VRF requests in flight simultaneously, you must ensure that the order in which the VRF fulfillments arrive cannot be used to manipulate your contract’s user-significant behavior.

Blockchain miners/validators can control the order in which your requests appear on-chain, and hence the order in which your contract responds to them.

For example, if you made randomness requests A, B, C in short succession, there is no guarantee that the associated randomness fulfillments will also be in order A, B, C. The randomness fulfillments might just as well arrive at your contract in order C, A, B or any other order.

We recommend using the requestID to match randomness requests with their corresponding fulfillments.

Choose a safe block confirmation time, which will vary between blockchains

My comment Miners/validators can "re-roll the dice" by rewriting the blockchain history to put a randomness request from your contract into a different block. Chhose a safe block confirmation time to avoid this.

In principle, miners/validators of your underlying blockchain could rewrite the chain's history to put a randomness request from your contract into a different block, which would result in a different VRF output. Note that this does not enable a miner to determine the random value in advance. It only enables them to get a fresh random value that might or might not be to their advantage. By way of analogy, they can only re-roll the dice, not predetermine or predict which side it will land on.

You must choose an appropriate confirmation time for the randomness requests you make. Confirmation time is how many blocks the VRF service waits before writing a fulfillment to the chain to make potential rewrite attacks unprofitable in the context of your application and its value-at-risk.

Do not re-request randomness

My comment "Re-request" pattern will give VRF service provider the power to "re-roll the dice" until they got a favorable outcome. Avoid using "re-request" pattern.

Any re-request of randomness is an incorrect use of VRFv2. Doing so would give the VRF service provider the option to withhold a VRF fulfillment if the outcome is not favorable to them and wait for the re-request in the hopes that they get a better outcome, similar to the considerations with block confirmation time.

Re-requesting randomness is easily detectable on-chain and should be avoided for use cases that want to be considered as using VRFv2 correctly.

Don’t accept bids/bets/inputs after you have made a randomness request

My comment User input accepted after sending out randomness requests and before fulfillment could mess up the contract logic. Stop accepting further user actions in this time window.

Consider the example of a contract that mints a random NFT in response to a user’s actions.

The contract should:

  1. Record whatever actions of the user may affect the generated NFT.

  2. Stop accepting further user actions that might affect the generated NFT and issue a randomness request.

  3. On randomness fulfillment, mint the NFT.

Generally speaking, whenever an outcome in your contract depends on some user-supplied inputs and randomness, the contract should not accept any additional user-supplied inputs after it submits the randomness request.

Otherwise, the cryptoeconomic security properties may be violated by an attacker that can rewrite the chain.

fulfillRandomWords must not revert

My comment VRF service will not call a reverted fulfillRandomWords() implementation a second time. This is similar to a DoS scenario. Make sure fulfillRandomWords() never reverts.

Use VRFConsumerBaseV2 in your contract, to interact with the VRF service

My comment Use VRFConsumerBaseV2 for subscription method.

Use VRFv2WrapperConsumer.sol in your contract, to interact with the VRF service

My comment Use VRFv2WrapperConsumer for direct funding method.

Best Practices

Getting a random number within a range

function fulfillRandomWords(
    uint256, /* requestId */
    uint256[] memory randomWords
) internal override {
    // Assuming only one random word was requested.
    s_randomRange = (randomWords[0] % 50) + 1;
}

Getting multiple random values

If you want to get multiple random values from a single VRF request, you can request this directly with the numWords argument:

Processing simultaneous VRF requests

If you want to have multiple VRF requests processing simultaneously, create a mapping between requestId and the response. You might also create a mapping between the requestId and the address of the requester to track which address made each request.

mapping(uint256 => uint256[]) public s_requestIdToRandomWords;
mapping(uint256 => address) public s_requestIdToAddress;
uint256 public s_requestId;

function requestRandomWords() external onlyOwner returns (uint256) {
    uint256 requestId = COORDINATOR.requestRandomWords(
        keyHash,
        s_subscriptionId,
        requestConfirmations,
        callbackGasLimit,
        numWords
  );
    s_requestIdToAddress[requestId] = msg.sender;

    // Store the latest requestId for this example.
    s_requestId = requestId;

    // Return the requestId to the requester.
    return requestId;
}

function fulfillRandomWords(
    uint256 requestId,
    uint256[] memory randomWords
) internal override {
    // You can return the value to the requester,
    // but this example simply stores it.
    s_requestIdToRandomWords[requestId] = randomWords;
}

You could also map the requestId to an index to keep track of the order in which a request was made.

mapping(uint256 => uint256) s_requestIdToRequestIndex;
mapping(uint256 => uint256[]) public s_requestIndexToRandomWords;
uint256 public requestCounter;

function requestRandomWords() external onlyOwner {
    uint256 requestId = COORDINATOR.requestRandomWords(
        keyHash,
        s_subscriptionId,
        requestConfirmations,
        callbackGasLimit,
        numWords
    );
    s_requestIdToRequestIndex[requestId] = requestCounter;
    requestCounter += 1;
}

function fulfillRandomWords(
    uint256 requestId,
    uint256[] memory randomWords
) internal override {
    uint256 requestNumber = s_requestIdToRequestIndex[requestId];
    s_requestIndexToRandomWords[requestNumber] = randomWords;
}

Processing VRF responses through different execution paths

If you want to process VRF responses depending on predetermined conditions, you can create an enum. When requesting for randomness, map each requestId to an enum. This way, you can handle different execution paths in fulfillRandomWords. See the following example:

// SPDX-License-Identifier: MIT
// An example of a consumer contract that relies on a subscription for funding.
// It shows how to setup multiple execution paths for handling a response.
pragma solidity ^0.8.7;

import "@chainlink/contracts/src/v0.8/interfaces/VRFCoordinatorV2Interface.sol";
import "@chainlink/contracts/src/v0.8/VRFConsumerBaseV2.sol";

/**
 * THIS IS AN EXAMPLE CONTRACT THAT USES HARDCODED VALUES FOR CLARITY.
 * THIS IS AN EXAMPLE CONTRACT THAT USES UN-AUDITED CODE.
 * DO NOT USE THIS CODE IN PRODUCTION.
 */

contract VRFv2MultiplePaths is VRFConsumerBaseV2 {
    VRFCoordinatorV2Interface COORDINATOR;

    // Your subscription ID.
    uint64 s_subscriptionId;

    // Sepolia coordinator. For other networks,
    // see https://docs.chain.link/docs/vrf/v2/supported-networks/#configurations
    address vrfCoordinator = 0x8103B0A8A00be2DDC778e6e7eaa21791Cd364625;

    // The gas lane to use, which specifies the maximum gas price to bump to.
    // For a list of available gas lanes on each network,
    // see https://docs.chain.link/docs/vrf/v2/supported-networks/#configurations
    bytes32 keyHash =
        0x474e34a077df58807dbe9c96d3c009b23b3c6d0cce433e59bbf5b34f823bc56c;

    uint32 callbackGasLimit = 100000;

    // The default is 3, but you can set this higher.
    uint16 requestConfirmations = 3;

    // For this example, retrieve 1 random value in one request.
    // Cannot exceed VRFCoordinatorV2.MAX_NUM_WORDS.
    uint32 numWords = 1;

    enum Variable {
        A,
        B,
        C
    }

    uint256 public variableA;
    uint256 public variableB;
    uint256 public variableC;

    mapping(uint256 => Variable) public requests;

    // events
    event FulfilledA(uint256 requestId, uint256 value);
    event FulfilledB(uint256 requestId, uint256 value);
    event FulfilledC(uint256 requestId, uint256 value);

    constructor(uint64 subscriptionId) VRFConsumerBaseV2(vrfCoordinator) {
        COORDINATOR = VRFCoordinatorV2Interface(vrfCoordinator);
        s_subscriptionId = subscriptionId;
    }

    function updateVariable(uint256 input) public {
        uint256 requestId = COORDINATOR.requestRandomWords(
            keyHash,
            s_subscriptionId,
            requestConfirmations,
            callbackGasLimit,
            numWords
        );

        if (input % 2 == 0) {
            requests[requestId] = Variable.A;
        } else if (input % 3 == 0) {
            requests[requestId] = Variable.B;
        } else {
            requests[requestId] = Variable.C;
        }
    }

    function fulfillRandomWords(
        uint256 requestId,
        uint256[] memory randomWords
    ) internal override {
        Variable variable = requests[requestId];
        if (variable == Variable.A) {
            fulfillA(requestId, randomWords[0]);
        } else if (variable == Variable.B) {
            fulfillB(requestId, randomWords[0]);
        } else if (variable == Variable.C) {
            fulfillC(requestId, randomWords[0]);
        }
    }

    function fulfillA(uint256 requestId, uint256 randomWord) private {
        // execution path A
        variableA = randomWord;
        emit FulfilledA(requestId, randomWord);
    }

    function fulfillB(uint256 requestId, uint256 randomWord) private {
        // execution path B
        variableB = randomWord;
        emit FulfilledB(requestId, randomWord);
    }

    function fulfillC(uint256 requestId, uint256 randomWord) private {
        // execution path C
        variableC = randomWord;
        emit FulfilledC(requestId, randomWord);
    }
}

If your fulfillRandomWords() implementation reverts, the VRF service will not attempt to call it a second time. Make sure your contract logic does not revert. Consider simply storing the randomness and taking more complex follow-on actions in separate contract calls made by you, your users, or an .

If you implement the , use VRFConsumerBaseV2. It includes a check to ensure the randomness is fulfilled by VRFCoordinatorV2. For this reason, it is a best practice to inherit from VRFConsumerBaseV2. Similarly, don’t override rawFulfillRandomness.

If you implement the , use VRFv2WrapperConsumer. It includes a check to ensure the randomness is fulfilled by the VRFV2Wrapper. For this reason, it is a best practice to inherit from VRFv2WrapperConsumer. Similarly, don’t override rawFulfillRandomWords.

These are example best practices for using Chainlink VRF. To explore more applications of VRF, refer to our .

If you need to generate a random number within a given range, use to define the limits of your range. Below you can see how to get a random number in a range from 1 to 50.

If you are using the VRF v2 subscription method, see the guide for an example where one request returns multiple random values.

If you are using the VRF v2 direct funding method, see the guide for an example where one request returns multiple random values.

βœ…
Chainlink VRF v2 Is Now Live on Mainnet
contact us
Stack Overflow
Subscription
Direct funding
Use requestId to match randomness requests with their fulfillment in order
Choose a safe block confirmation time, which will vary between blockchains
Do not re-request randomness
Don’t accept bids/bets/inputs after you have made a randomness request
The fulfillRandomWords function must not revert
Use VRFConsumerBaseV2 in your contract to interact with the VRF service
Automation Node
subscription method
direct funding method
blog
modulo
Get a Random Number
Get a Random Number