diff --git a/src/content/vrf/v1/security.mdx b/src/content/vrf/v1/security.mdx index 9e283c84fd6..08c17db00f5 100644 --- a/src/content/vrf/v1/security.mdx +++ b/src/content/vrf/v1/security.mdx @@ -12,7 +12,7 @@ Gaining access to high quality randomness onchain requires a solution like Chain - [Use `requestId` to match randomness requests with their fulfillment in order](#use-requestid-to-match-randomness-requests-with-their-fulfillment-in-order) - [Choose a safe block confirmation time, which will vary between blockchains](#choose-a-safe-block-confirmation-time-which-will-vary-between-blockchains) -- [Do not re-request randomness](#do-not-re-request-randomness) +- [Do not allow re-requesting or cancellation of randomness](#do-not-allow-re-requesting-or-cancellation-of-randomness) - [Don't accept bids/bets/inputs after you have made a randomness request](#dont-accept-bidsbetsinputs-after-you-have-made-a-randomness-request) - [`fulfillRandomness` must not revert](#fulfillrandomness-must-not-revert) - [Use `VRFConsumerBase` in your contract, to interact with the VRF service](#use-vrfconsumerbase-in-your-contract-to-interact-with-the-vrf-service) @@ -43,11 +43,9 @@ For further details, take a look at the consensus documentation for the chain yo Understanding the blockchains you build your application on is very important. You should take time to understand [chain reorganization](https://blog.ethereum.org/2015/08/08/chain-reorganisation-depth-expectations/) which will also result in a different VRF output, which could be exploited. -## Do not re-request randomness +## Do not allow re-requesting or cancellation of randomness -Any re-request of randomness is an incorrect use of VRF. 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 onchain and should be avoided for use cases that want to be considered as using VRF correctly. +Any re-request or cancellation of randomness is an incorrect use of VRF. dApps that implement the ability to cancel or re-request randomness for specific commitments must consider the additional attack vectors created by this capability. For example, you must prevent the ability for any party to discard unfavorable randomness. ## Don't accept bids/bets/inputs after you have made a randomness request diff --git a/src/content/vrf/v2/direct-funding/examples/get-a-random-number.mdx b/src/content/vrf/v2/direct-funding/examples/get-a-random-number.mdx index d31adf7f15b..ee5c76feb18 100644 --- a/src/content/vrf/v2/direct-funding/examples/get-a-random-number.mdx +++ b/src/content/vrf/v2/direct-funding/examples/get-a-random-number.mdx @@ -89,8 +89,9 @@ The deployed contract requests random values from Chainlink VRF, receives those 1. Call `getRequestStatus()` and specify the `requestId` to display the random words. -