0

I'm writing an ERC-721 contract to launch a collection of paintings and I'm considering a few semi-generative variations to make the total supply about 1,000 tokens with multiple rarities.

I'd like to use a reveal step so that collectors will only know what random token and rarity they get after the collection has sold out or some time has passed but I'm slightly confused about the use of a provenance hash and the randomness mechanism.

The short version question is: What's the recommended way to allow users to mint random tokens, reveal metadata, and offer full transparency in 2022?

And here's the long version.

Of course I want to offer transparency so I learned all I could about the provenance hash and I'm considering generating the hash with the actual metadata (hashing the full JSON files including the IPFS CID for images instead of just the images, is that somehow better or just unnecessary?) before the sale starts but only pointing to placeholder images at first and then uploading the final metadata and images and setting the baseURI on reveal time.

But I'm not sure about the random part. I've read about the BAYC approach with a startingIndex (which apparently the contract doesn't use correctly) coming from the block number of the last token minted but I'm not sure if that's still a good approach in 2022. As it looks like BAYC is not a great example of this approach I'd appreciate it if you could point me to a contract doing it the right way.

I initially thought about randomizing the token ID on mint with a Chainlink VRF call but with many tokens that would be too expensive.

Another option I considered was just making one call to Chainlink VRF on reveal and then expanding that number using the random number with keccak256 and them modulo operator to shuffle the token IDs and run a loop over all the tokens calling _setTokenURI to point each token to a JSON metadata file on IPFS. For this to work fine I suppose I shouldn't put these files in just one IPFS directory so each CID would be different and unrelated to the token ID but I worry that this solution may be too expensive because of the loop and calls to _setTokenURI.

For reference here are a couple of URLs I've already explored.

Random-order minting of ERC721 tokens

https://forum.openzeppelin.com/t/are-nft-projects-doing-starting-index-randomization-and-provenance-wrong-or-is-it-just-me/14147/7

1 Answer 1

0

I have documented this extensively at https://blog.phor.net/2022/02/04/Randomization-strategies-for-NFT-drops.html

And here is one approach that is implemented, permissively licensed and has just sold out on its drop https://github.com/LightArtists/light-smart-contracts

In general you want to understand the different sources of randomness (blockhashes on chain, oracles off chain) and design in the necessary tradeoffs between speed/randomness/and fairness.

1
  • I've read your article before but I'll reread it. Thank you for sharing that repository too.
    – Mentakatz
    Aug 8, 2022 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.