Chainlink VRF user experience (double gas payments)

Support
1

I’m looking to implement safe randoms into my dapp but I’m a little concerned about the process as far as the user experience goes.

I’m kinda new to dapps so maybe I’m overthinking this - but as far as I understood, the actions requested by the user have to be completed by placing a second call to the app, paying gas a second time, now using the seed returned by chainlink. Is this something that’s generally accepted, or is it worth bothering with alternative solutions?

I know there’s a 200k gas limit on the callback coming from Chainlink, but I don’t think I can optimize some of my random functions to the point where I’m comfortably under that with room to spare. Among other things, they are meant for minting NFTs with structs of data and consecutive seeds being used to generate properties, so it may be more trouble than it’s worth trying to cut it down.

One idea I had was to have the app pre-generate a pool of seeds (say, 100) when the supply gets low, this way the user actions are instantaneous and they only have to confirm gas once. Problem is, I can’t have the odd user pay the gas for requesting those seeds (even if the contract is the one paying the LINK tokens), so I’m not sure how the pool would be filled reliably, and it may require supervision from time to time depending on the shift in user traffic.

Any thoughts or ideas?
Thanks

1 Like
2

Hi @poshdan,

I haven’t played with randomness from Chainlink so can’t give you any guidance on this.

If you need to automate Ethereum operations, such as creating a transaction on a schedule or an event, then you could use OpenZeppelin Defender Autotasks: https://docs.openzeppelin.com/defender/autotasks

3

Unfortunately autotasks aren’t really what I’m looking for, but thanks for the suggestion anyway.

As a followup for anyone wondering about this exact issue, there’s no easy fix, but I was told on the Chainlink discord that the double calls are generally accepted by users (like when approving, and transfering tokens in two separate calls)

For those who are considering caching a number of random tokens (as i suggested in my initial post), be advised that the values could be extracted with enough dedication, even if the state variable is private, so the implementation should be somewhat unpredictable to avoid abuse.

1 Like
4

Hi @poshdan,

Private state variables are easy to read from off chain so definitely wouldn’t store any secrets on chain.