For today's NFT Code Review, we decided to go with an on-chain project. “on-chain” refers to all of the token data being on the Ethereum blockchain and not hosted somewhere else on the internet.
This project was one of the first to open my eyes to the possibilities of NFTs. Let's take a look at @lootproject.
For those of you unfamiliar with Loot, here is their description:
"Loot is randomized adventurer gear generated and stored on chain. Stats, images, and other functionality are intentionally omitted for others to interpret. Feel free to use Loot in any way you want."
Loot is completely on-chain. The simplicity of it is beautiful.
Below you can see all of the different pieces of adventure gear. Here are the examples for `necklaces` and `rings`. There are many other types just like this.
These are the functions that get the specific adventure gear for a certain type. You can see "HEAD", "RING", "CHEST", etc. They all call `pluck`. We'll get to what `pluck` does soon.
First, let's take a look at `random`. This function helps drive the rarities on-chain.
It's not truly a random function because that's impossible to do on-chain, but it's as close as you can get.
It uses a string, the contract's ABI, and keccak256 to spit out an integer.
Now to `pluck`. There is a lot to unpack here.
First, it gets a random integer using the provided `keyPrefix` and `tokenId`. For example, "RING" and 777.
Next, using the integer and the `sourceArray`, it gets the item to use for the adventure gear.
If you recall, there are five ring options.
"Gold Ring", "Silver Ring", "Bronze Ring", "Platinum Ring", "Titanium Ring".
They can be accessed by a specific integer.
"Gold Ring" is 0
"Silver Ring" is 1
"Bronze Ring" is 2
"Platinum Ring" is 3
"Titanium Ring" is 4
So if the randomly generated integer for the token is 3, the "Platinum Ring" will be picked.
Next, a `greatness` is calculated. This is what drives the rarities. `greatness` can be anything from 0 to 20.
If `greatness` is greater than 14 a suffix is added.
If `greatness` is greater than or equal to 19 a name will be prefixed.
If `greatness` is 20, "+1" is added.
Now to `tokenURI`.
This is how the metadata is retrieved on-chain. This builds an SVG image using all of the adventure gear. You can see here all the pieces of text being tied together.
On line 1564 you can see the final metadata for the token. The "name", the "description", and the "image". I was surprised to find that the "attributes" were not set here. The image and the final metadata are both Base64 encoded.
This is what OpenSea and other marketplaces use to display the image and properties for an NFT.
Below are `claim` and `ownerClaim`. It was unique to see a `tokenId` parameter. Usually, the NFT contract keeps a count of which tokens have been minted and then increments the count after each mint.
It was a free mint of 7777 tokens for the public.
The owner then was able to mint tokens from 7778 to 8000.
Finally, it looks like the owner created their own `toString` function that takes an integer and turns it into a string. There is an openzepplin implementation of this, so I wonder why it was created 🤔.
If you liked this breakdown of the @lootproject. contract code please pass this along and follow us on Twitter @BurnableLabs.
What NFT project should we do next? Let us know in the comments!
If you want to keep reading NFT Code Reviews, here is one we did on the @BoredApeYC contract code. There were some eye-opening surprises in there…
This was a Twitter thread originally posted here.
