CODEWITHSUNDEEP
chainlink
Babs
Babs

Reputation: 21

What needs to be upgradable, if anything, so a Chainlink VRF v2 protocol doesn't break during transition to v2.5 or v3?

I'm building a simple protocol that needed to user Chainlink VRF v2. I need to know more about the impact of future Chainlink VRF versions on the project.

Project structure:

  1. User calls one of my contract functions which calls requestRandomWords()

  2. Chainlink VRF calls back my fulfillRandomWords() implemented function

Will this structure change at all in future versions? What does "sunsetting of v2" mean?

Do I just have to make sure my VRF Coordinator address is able to be set to a new address? Any other concerns?

The project doesn't have a proxy-implementation pattern and is mostly immutable, so I'm trying to determine what I need to leave as upgradable.

My expectation is that I just need to have the ability to update the VRF Coordinator address that I'm using, but there may be other things that need to be upgradable so they don't break from v2 to v2.5 and v3 and so on.

Any documentation on changes from v2 to v2.5 would be extremely helpful

Upvotes: 2

Views: 160

Answers (1)

ZeusLawyer
ZeusLawyer

Reputation: 294

Yes V2 is the current version and its fine for your to develop on while you test and iterate on testnets. However note there is a V2.5 coming out soon and that will have a slight change to requestRandomWords() which will take in an extraArgs param.

You can read about that here in the comments to the Coordinate interface API.

If I were you I'd continue using V2 and start preparing a V2.5 version as it should require fairly minimum changes. extraArgs will just support situations in the future where additional params may be needed etc.

Upvotes: 0

Related Questions