Interface for contracts using VRF randomness


Reggie the Random Oracle (not his real job) wants to provide randomness to Vera the verifier in such a way that Vera can be sure he's not making his output up to suit himself. Reggie provides Vera a public key to which he knows the secret key. Each time Vera provides a seed to Reggie, he gives back a value which is computed completely deterministically from the seed and the secret key.

Reggie provides a proof by which Vera can verify that the output was correctly computed once Reggie tells it to her, but without that proof, the output is indistinguishable to her from a uniform random sample from the output space.

The purpose of this contract is to make it easy for unrelated contracts to talk to Vera the verifier about the work Reggie is doing, to provide simple access to a verifiable source of randomness.


Calling contracts must inherit from VRFConsumerInterface, and can initialize VRFConsumerInterface's attributes in their constructor as shown:

contract VRFConsumer { constuctor(, address _vrfCoordinator, address _link) VRFConsumerBase(_vrfCoordinator, _link) public { } }

The oracle will have given you an ID for the VRF keypair they have committed to (let's call it keyHash), and have told you the minimum LINK price for VRF service. Make sure your contract has sufficient LINK, and call requestRandomness(keyHash, fee, seed), where seed is the input you want to generate randomness from.

Once the VRFCoordinator has received and validated the oracle's response to your request, it will call your contract's fulfillRandomness method.

The randomness argument to fulfillRandomness is the actual random value generated from your seed.

The requestId argument is generated from the keyHash and the seed by makeRequestId(keyHash, seed). If your contract could have concurrent requests open, you can use the requestId to track which seed is associated with which randomness. See VRFRequestIDBase.sol for more details.

Colliding requestIds are cryptographically impossible as long as seeds differ. (Which is critical to making unpredictable randomness! See the next section.)


Since the ultimate input to the VRF is mixed with the block hash of the block in which the request is made, user-provided seeds have no impact on its economic security properties. They are only included for API compatability with previous versions of this contract.

Since the block hash of the block which contains the requestRandomness() call is mixed into the input to the VRF last, a sufficiently powerful miner could, in principle, fork the blockchain to evict the block containing the request, forcing the request to be included in a different block with a different hash, and therefore a different input to the VRF. However, such an attack would incur a substantial economic cost. This cost scales with the number of blocks the VRF oracle waits until it calls fulfillRandomness()._


event VrfRandomNumber(uint256 tokenId, uint256 randomNumber, uint256 _vrfTimeSet)


event OpenPortals(uint256[] _tokenIds)


event PortalOpened(uint256 tokenId)


function linkBalance() external view returns (uint256 linkBalance_)


function vrfCoordinator() external view returns (address)
function link() external view returns (address)


function keyHash() external view returns (bytes32)


function openPortals(uint256[] _tokenIds) external


function rawFulfillRandomness(bytes32 _requestId, uint256 _randomNumber) external

fulfillRandomness handles the VRF response. Your contract must implement it.

The VRFCoordinator expects a calling contract to have a method with this signature, and will trigger it once it has verified the proof associated with the randomness (It is triggered via a call to rawFulfillRandomness, below.)





The Id initially returned by requestRandomness



the VRF output


function changeVrf(uint256 _newFee, bytes32 _keyHash, address _vrfCoordinator, address _link) external

Allow the aavegotchi diamond owner to change the vrf details


function removeLinkTokens(address _to, uint256 _value) external