𝗧𝗵𝗲 𝗩𝗥𝗙 𝗰𝗮𝗹𝗹𝗯𝗮𝗰𝗸 𝗶𝘀 𝘁𝗵𝗲 𝗼𝗻𝗲 𝗳𝘂𝗻𝗰𝘁𝗶𝗼𝗻 𝗶𝗻 𝘆𝗼𝘂𝗿 𝗴𝗮𝗺𝗲 𝘁𝗵𝗮𝘁 𝘆𝗼𝘂 𝗻𝗲𝘃𝗲𝗿 𝗴𝗲𝘁 𝘁𝗼 𝗰𝗮𝗹𝗹 𝘆𝗼𝘂𝗿𝘀𝗲𝗹𝗳. In a @WinkLink_Oracle VRF consumer, fulfillRandomWords is called for you. The chain goes like this: the node returns the random values and proof, VRFCoordinatorV2 verifies the proof, then VRFV2Wrapper calls your contract. The base contract even guards the entry point, so rawFulfillRandomWords reverts unless the caller is the wrapper. That changes how you should write the callback. These are the rules I follow: ➜ 𝗟𝗼𝗼𝗸 𝘂𝗽 𝘁𝗵𝗲 𝗿𝗲𝗾𝘂𝗲𝘀𝘁 𝗳𝗶𝗿𝘀𝘁, like the docs sample does by requiring that the stored request was paid ➜ 𝗦𝘁𝗼𝗿𝗲, 𝗱𝗼𝗻'𝘁 𝘀𝗽𝗿𝗮𝘄𝗹: save the random words and mark the request fulfilled ➜ 𝗦𝘁𝗮𝘆 𝗶𝗻𝘀𝗶𝗱𝗲 𝗰𝗮𝗹𝗹𝗯𝗮𝗰𝗸𝗚𝗮𝘀𝗟𝗶𝗺𝗶𝘁, which the sample says to test and adjust for your network, request size and callback logic ➜ 𝗗𝗼 𝗵𝗲𝗮𝘃𝘆 𝘄𝗼𝗿𝗸 𝗹𝗮𝘁𝗲𝗿, in a separate transaction that reads the stored result That last one is my preference, not a doc rule. A callback that tries to mint, pay out and update a leaderboard all at once is the one most likely to run out of gas. A lean callback that just records the result has very little room to fail. The full sample consumer is in the VRF docs here: https://t.co/IHzHvC4fNU 𝗥𝗲𝗰𝗼𝗿𝗱 𝘁𝗵𝗲 𝗱𝗶𝗰𝗲. Play the move afterwards. @justinsuntron @WinkLink_Oracle #TronEcoStar