Let us introduce our smart contract to you. The goal of this article is to give a high-level overview in a logical order and with references to other articles for those who want to dig deeper. We want everybody to have a good understanding of what we are building and why. This is just the first article so we ask the seasoned NFT collectors to be patient, we have to establish a common base. And as the last warning, this article will be a little bit technical but we will try to make it as simple as possible to be easier to read for people with less knowledge of the field.
Token Standard
Cowlony is an ERC721 NFT collection which will be released on the Ethereum chain. In short, this standard defines the basic requirements and mechanisms of managing unique tokens between addresses. The technical definitions of these requirements are in the IERC721 interface, our contract needs to implement this to be compliant with the standard.
There are many options to achieve this, we chose to use the ERC721A solution. The Azuki project created this implementation and open-sourced it to the community. It has also been actively developed, tested, and maintained since then. The main feature of this implementation is that multiple NFTs can be minted at nearly the same price as just one. The main idea behind this reduction is minting the tokens at once and only setting the ownership information of the first token rather than doing it separately and using multiple writes. The previously linked Azuki article provides a great explanation of the special minting and management process along with several further cost reduction features.
Metadata association
Now we have a contract which can manage the tokens of the cowlony collection on the blockchain. The next task is providing meaningful information about the metadata, the traits and the images of the cows, which are associated with specific ids. The most ideal solution would be to store this on-chain in the tokens, this way the association is guaranteed and the owner could have full control over it. Unfortunately, the size of data associated with one token in our collection is large enough to generate an enormous amount of gas fee to store it on-chain.
The second best option is to use IPFS (Interplanetary File System), which is a distributed file storage solution. After a file is uploaded, a unique hash is generated for it, which is used as the path to access it. This also ensures that the metadata for the tokens can’t be changed without notice. We can also upload the tokens’ metadata ordered in one folder to IPFS which results in that the metadata paths will be the same except for the token ids at their end. Since the id is already stored, we additionally only have to store a base URL in our contract to create the association between the tokens and their metadata.
Collection integrity
At this point we have a strong base, we have the tokens and also the metadata to support them. The next thing we have to talk about is the minting process. We believe the fair way of distributing our cows to the community is by blind minting. We are revealing the metadata after the sale so before minting a token its parameters will be unknown. This method helps to reduce unnecessary rivalry and keep up the excitement. We also want to ensure that there will be no manipulation in the metadata after the mint and before the reveal.
To do this we are using the provenance hash value, which we will set on the contract before the mint. The generation process is the following: we create the sha256 hashes of the images, then concatenate them in the order of the tokens and lastly get the sha256 hash of the concatenated value. After the entire collection is revealed with the described mechanism, anyone can validate the previously defined provenance value in our contract. (There is a great example of the process at the Bored Ape Yacht Club’s site: https://boredapeyachtclub.com/#/provenance) This way we can guarantee the integrity of our metadata without revealing it before the mint.
What’s next
We talked about the ERC721 standard, the metadata storage, association with the tokens and its protection so far. We are far from being done with the introduction of the cowlony contract, but we are finishing part 1 here. To give a sneak peek into the upcoming articles, you can expect topics about OpenSea listing fees and mechanisms to avoid them, our allowlist implementation and why it matters and much more. One more thing, as we wrote in the project description cowlony will support a contract level staking which will be published as its own story.
Stay tuned,
cowlony
