Direct Funding Method

This guide explains how to generate random numbers using the direct funding method. This method doesn't require a subscription and is optimal for one-off requests for randomness. This method also works best for applications where your end-users must pay the fees for VRF because the cost of the request is determined at request time.

Unlike the subscription method, the direct funding method does not require you to create subscriptions and pre-fund them. Instead, you must directly fund consuming contracts with native tokens or LINK before they request randomness. Because the consuming contract directly pays for the request, the cost is calculated during the request and not during the callback when the randomness is fulfilled. Learn how to estimate costs.

Request and receive data

Requests to Chainlink VRF v2.5 follow the request and receive data cycle similarly to VRF V2. This end-to-end diagram shows each step in the lifecycle of a VRF direct funding request:

Two types of accounts exist in the Ethereum ecosystem, and both are used in VRF:

• EOA (Externally Owned Account): An externally owned account that has a private key and can control a smart contract. Transactions can be initiated only by EOAs.
• Smart contract: A smart contract that does not have a private key and executes what it has been designed for as a decentralized application.

The Chainlink VRF v2.5 solution uses both offchain and onchain components:

• VRF v2.5 Wrapper (onchain component): A wrapper for the VRF Coordinator that provides an interface for consuming contracts.
• VRF v2.5 Coordinator (onchain component): A contract designed to interact with the VRF service. It emits an event when a request for randomness is made, and then verifies the random number and proof of how it was generated by the VRF service.
• VRF service (offchain component): Listens for requests by subscribing to the VRF Coordinator event logs and calculates a random number based on the block hash and nonce. The VRF service then sends a transaction to the VRFCoordinator including the random number and a proof of how it was generated.

Set up your contract and request

Set up your consuming contract:

1. Your contract must inherit VRFV2PlusWrapperConsumerBase.

2. Your contract must implement the fulfillRandomWords function, which is the callback VRF function. Here, you add logic to handle the random values after they are returned to your contract.

3. Submit your VRF request by calling the requestRandomness function in the VRFV2PlusWrapperConsumerBase contract. Include the following parameters in your request:

   • requestConfirmations: The number of block confirmations the VRF service will wait to respond. The minimum and maximum confirmations for your network can be found here.
   • callbackGasLimit: The maximum amount of gas to pay for completing the callback VRF function.
   • numWords: The number of random numbers to request. You can find the maximum number of random values per request for your network in the Supported networks page.
   • extraArgs: A parameter for additional arguments related to new VRF features, such as enabling payment in native tokens.

How VRF processes your request

After you submit your request, it is processed using the Request & Receive Data cycle:

1. The consuming contract calls the VRFV2PlusWrapper calculateRequestPrice function to estimate the total transaction cost to fulfill randomness. Learn how to estimate transaction costs.

2. The consuming contract calls the LinkToken transferAndCall function to pay the wrapper with the calculated request price. This method sends LINK tokens and executes the VRFV2PlusWrapper onTokenTransfer logic.

3. The VRFV2PlusWrapper's onTokenTransfer logic triggers the VRF 2.5 Coordinator requestRandomWords function to request randomness.

4. The VRF coordinator emits an event.

5. The VRF service picks up the event and waits for the specified number of block confirmations to respond back to the VRF coordinator with the random values and a proof (requestConfirmations).

6. The VRF coordinator verifies the proof onchain, then it calls back the wrapper contract's fulfillRandomWords function.

7. Finally, the VRF Wrapper calls back your consuming contract.

Limits

You can see the configuration for each network on the Supported networks page. You can also view the full configuration for each VRF v2.5 Wrapper contract directly in Etherscan. As an example, view the Ethereum Mainnet VRF v2.5 Wrapper contract configuration by calling getConfig function.

• Each wrapper has a maxNumWords parameter that limits the maximum number of random values you can receive in each request.
• The maximum allowed callbackGasLimit value for your requests is defined in the Coordinator contract supported networks page. Because the VRF v2.5 Wrapper adds an overhead, your callbackGasLimit must not exceed maxGasLimit - wrapperGasOverhead. Learn more about estimating costs.