Through much iterative development and testing, we arrived at a cooperative procedure between our API and two contracts, which produces CryptoVikings on-demand and in a provably fair way.
When you decide to mint a CryptoViking, your transaction kicks off the NFT mint itself and the sending of a request to Chainlink VRF for a random number. We handle the rest past this point — your transaction is complete.
The number we get back from Chainlink VRF is stored publicly against the token ID for future use and for anyone to see; the API is then prompted that a CryptoViking is ready to be generated and the process begins.
First, the API tells the main contract to use the random number to derive a data structure numerically representing the CryptoViking, called VikingStats. VikingStats contains a series of smaller numbers which we’ll use later to resolve and store some more information about the CryptoViking, and it’s also stored publicly against the token ID.
Next, the API asks the contract to resolve the CryptoViking’s component names and item conditions. CryptoVikings are made up of nine components, of which five items are modified by a condition — so we need the names of each component and the conditions of the items.
For this step, the contract sends the appropriate VikingStats to a second contract, which is responsible for resolving the names and conditions by using the selectors found in the VikingStats to implement a probability distribution for each asset within its set. The result of this resolution is two further data structures — VikingComponents and VikingConditions, which are returned to the main contract and stored publicly against the token ID.
At this stage, the main contract contains a full and public representation of the CryptoViking which can be used as a source of truth for metadata and image construction. Through an event, this representation is sent to the API, where thes...