Blockbongs contract is at the heart of each blockbong. Together with the Ethereum blockchain it makes every blockbong come alive and takes care of every important step in their lifecycle, from minting and smoking to handling transfers and supplying metadata. It conforms to the ERC721 standard as countless other popular projects. Our goal is to deliver your blockbongs to you as comfortably as we can. We’ve implemented ERC721A developed by Azuki to allow minting of multiple blockbongs in a single transaction which among other things significantly reduces the fees when minting multiple NFTs. Read more about it on their webpage.

Before unboxing on April 20th 2022 each blockbong has its attributes hidden and is displayed in a box. All blockbong images, boxed and unboxed, with related metadata are stored using IPFS. We guarantee you the integrity of the final image(s) from the start. You can compute a unique hash value and compare it with the value stored in the MEDIA_HASH variable.

We’ve used SHA256 to compute the hash of each image file stored in the final IPFS directory sorted alphabetically. That makes a total of 21000 images and their appropriate SHA256 hashes. As a last step we computed SHA256 of these hashes (excluding filenames). You can achieve the same result using a command similar to this on your system:

openssl sha256 <(find media/ -type f -exec openssl sha256 \; | LC_ALL=C sort | cut -d" " -f2)

If you just want to quickly verify the hash of a single file or a complete list of files you can also grab these intermediate files containing precomputed media file hashes.

We’ve chosen quite an unusual name for the list of addresses allowed into the pre-sale mint for better price. You might be more used to it being called allowlist or whitelist but since we’re aiming at a specific group we believe it won’t bring too much confusion. The color is of substance (no pun intended).

We’ve looked for (mostly) storage efficient way to implement it and settled for using Merkle trees. This practically allows us to store many addresses at the cost of one. Most minting contract allowlist implementations don’t really offer an easy way for users to compute a proof themselves and send it with the transaction since the whole point is not storing the leaves in the contract. Here comes an easy and cheap solution to the rescue again. Since we were already using IPFS, we decided to publish a list of hashed nodes - addresses and store the CID in a contract. IPFS CID v1 with the right choice of hashing algorithm like SHA3-224 and base16 encoding format can be stored in a single bytes32 variable, albeit after stripping the multibase prefix character f. Anyone can fetch this list, see how many addresses are there and check if their hashed address is included after hashing it with Keccak-256. You could also publish an unhashed list of addresses, but we decided on this solution because it provides at least some level of privacy to people that decide to not use their chance of minting a blockbong in a presale phase.