Funding Chainlink VRF Dynamically

user_11513258 0
Viewed 540

I am trying to wrap my head around how Chainlink VRF integrates into Solidity contracts, such as in this randomly generated NFT tutorial: https://blog.chain.link/random-numbers-nft-erc721/

My question is around the actual funding of the oracle. In the Chainlink VRF documents, this warning is displayed: "Requesting randomness will fail unless your deployed contract has enough LINK to pay for it. Learn how to Acquire testnet LINK and Fund your contract." An example is given of how to fund the VRF contract with metamask and Remix.

However, I'm not really sure how this would work on a large scale. If you have an NFT "factory" that becomes very popular with potentially many requests per day/hour/minute, are you just expected to front run the funding of this VRF contract to avoid the aforementioned warning (seems like the costs would be non-trivial / hard to predict)?

Alternatively, if you wanted your NFT consumer to fund it, would you have to build in some logic that converts Ether to Link and then sends it to the oracle contract? (or make them go buy Link token?)

I could be looking at this the wrong way, but the scalability just doesn't seem well described in the documentation and only looked at from a testing / test network standpoint. Thank you.

chainlink solidity
2 Answers

You can:

  1. Move the costs directly to the caller

    Require LINK payment, or some other form of payment that will cover the costs of oracle request

  2. Request the oracle data in a smaller frequency (if your use case allows it)

    Are you receiving some price info from an oracle? Is it sufficient to update the price info once a day instead of once an hour?

  3. Change your contract logic to not require (that much) oracle data

    Does your factory really need off-chain random number generation? Wouldn't be sufficient to generate "random" number from the blockhash, difficulty, etc.?

user_16931920

My suggestion is, maybe a little awkward, but for the sake of decentralization, could work.

  • You charge your Contract1 with a sufficient link to get started

  • Charge every minter the equivalent link transaction cost in eth (+ the % that covers the costs of the trade to link and transfer between contracts)

  • As they mint, it is incorporated into the price and the eth is sent to Contract2.

  • In Contract2 simply exists a public callable function to initiate a swap for the link via routerV2 or a similar contract.

  • By placing a call to this function and contract, you can then just let any minter activate the swap contract function

  • The eth in Contract2 will be sent back to Contract1 as a link.

  • You could have a counter go and then call Contract2 every time the link fund is low and refill it automatically.

  • If you build it into the mint, then the inter will cover the fees.

user_173542160
Related