Security Considerations


Using Pythia VRF solution brings high quality randomness into your applications, but in order or achieve high security and true fairness you should keep some security conciderations in your mind.
In this article you can find some of the top security considerations you should review in your project.

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

To interact with Pythia VRF service, your contract need to inherit from VRFConsumer. It includes checks to ensure the randomness is fulfilled by VRFCoordinator. It is important to verify randomness before consuming it in your contract. This verification happend in rawFulfillRandomness function which implemented in VRFConsumer. To ensure validity of randomness, avoid override rawFulfillRandomness function in your contract.

fulfillRandomWords must not revert

Make sure your contract logic in fulfillRandomWords() does not revert. Fulfilling randomness is an one time action and the VRF service will not attempt to call it a second time, Therefore reverting transaction in the implementation will result to lost randomness. Consider simply storing the randomness and taking more complex actions in separate contract calls made by you or your users.

Use requestId to match randomness

Blockchain miners/validators can control the order in which your requests appear on-chain, therefore the order of fulfilled randoms may differ from the order of your request.

If your contract could make multiple VRF requests in simultaneously, you must use requestId to match randomness requests and do not rely on requests order.

For instance, if you submit randomness requests A, B, and C in rapid succession, there's no guarantee that the corresponding fulfillments will follow the same order of A, B, and C. The fulfillments of randomness could equally arrive at your contract in sequences like C, B, A, or in any other arrangement.

Don't accept inputs after the randomness request

When 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. Any user-supplied input could be done before requesting randomness from VRF service.

Accpting input after the randomness request may cause violating security properties by an attacker that can rewrite the chain.