Soo... This is long overdue – but i finally found the time to start the Checks contract deep dive i've promised a while ago.
First step: An overview of everything the contract does, wrapped in a "How to interact with Etherscan" tutorial.
↓
17
59
274
Replies
There is one main contract ("Checks"), and a handful of supporting libraries ("ChecksArt", "ChecksMetadata", ...).
Everything that can be "done" with Checks, is defined in this main contract.
1
2
21
Think of a contract as a predefined set of interactions that you it exposes.
Some just offer you a way to get some onchain information, others allow you to change the blockchain state the contract manages.
1
1
21
When looking at contracts it makes sense to first of all check out all of these functions we can use to get a high level picture of what is going on.
@etherscan
provides simple views to inspect these:
1
1
23
Let's first of all investigate the "Read" view. As the title implies, this shows all the bits of information we can ask the contract for.
1
1
19
If we scan through all these, we can quickly separate out what is standard ERC-721 stuff (the most common NFT token standard) and what is custom to our contract.
We should do a deep dive on ERC721 and ERC1155 sometime as well, but that's for another day...
1
1
24
Let's go through these read functions one by one.
First up, we have a simple link to the VV Checks Editions contract.
For the Originals mint / migration to work, it has to know where the Editions come from.
1
1
19
Next up, the "getCheck" function allows us to get the data for any Check tokenID that has already been migrated.
The data we get in return looks a bit complicated. The numbers detail whether the token has a gradient or what composite level the check is at.
1
1
20
The "colors" call is a bit easier to understand: Give it a token ID, and in return you get a list of colors. Once in hex code form, and once as checks color IDs.
1
1
19
Similarly easy to read: the "svg" call.
SVG stands for "Scalable Vector Graphic" and yes - the bit of text we get is the underlying data that then renders as our Checks image.
1
1
16
Just like we were able to query the data and art for a check, the next two methods allow us to see the result of a "Composite" (when merging two Checks).
We pass it the tokenID we want to keep and the tokenID we want to burn, and get the data and image for the resulting Check.
1
1
17
By the way - the two functions above are what powers the "Burn preview" interface on the website:
We have the two tokenIDs "keep" and "burn", and render the resulting check data and preview image so you know exactly what you get before burning.
1
1
19
Back to our Etherscan journey: The last two functions give us information about the epoch-based reveal.
Epochs are batches of checks, each 10 minutes long.
In order to ensure a fair migration, original Checks get their DNA from a block in the future (at the end of each epoch).
1
1
18
If you want to dive deeper into how this works,
@_MouseDev
and i have written a couple threads on this already:
What is randomness and how does it affect you as an NFT consumer? A lot more than you might think! In this thread I'll go over the epoch based method I created for checks by
@jackbutcher
, and how randomness works in this context.
👇
65
141
534
1
1
17
Alright... This was all the "Read" functions, which means we're just getting some information from the Ethereum state.
Note: Reading state like this doesn't cost any gas, even if there is a bunch of computation involved.
1
1
17
Next, let's go through the "Write" actions we can take.
Writing, as in "writing to the Ethereum Blockchain" changes state in the contract.
1
1
14
Again, if we separate out the standard ERC-721 functions, we're left with five main actions on the Checks contract:
- Mint (Migrate Editions to onchain Originals) and their reveal
- Composite (Burn/Merge Checks together)
- InItForTheArt (Sacrifice)
- Infinity (Black Check)
1
1
16
Migration:
Owners of "Checks Editions" are given the choice to migrate their tokens over to the "Checks Originals" collection whenever they want – be it now or in ten years...
1
1
16
Before initiating the migration, they have to "Approve" the Checks Originals contract to manage the Edition NFTs. This allows it to hook into the Editions and burn them when minting the onchain Originals.
Approvals are a standard ERC-721 feature, so we won't go into them here.
1
0
16
When migrating, one has to pass the token IDs to migrate as well as the receiving address. Why the latter? So you can easily vault your tokens without having to separately transfer them after the migration.
1
0
18
New mints automatically reveal previous mints, but if no mints are coming in, the "resolveEpochIfNecessary" function reveals the previous batch of new onchain Originals.
1
0
16
Arguably the most important / unique aspect of the originals is the "composite" action.
Here, we pass the IDs of two tokens, and an optional "swap" command. The first token ID is upgraded to a lower check count, the second token is destroyed in the process.
1
0
16
A lesser known command is the "inItForTheArt" action. Here, you're copying the visual art of one token onto another but burning it in the process. So no lower check count.
Hard core commitment to the art of collecting nice token ID + visual pairs.
2
0
26
Lastly, the creation of the Black Check.
Pass 64 token IDs of single checks.
The first one in the list will be upgraded to be the Black Check.
4095 tokens are burned, one evolves to be (imo) the ultimate symbol of blockchain values and responsibilities.
2
0
28
Yo if you read all this, props!
I'd encourage you to poke around the contract functions on Etherscan here:
1
0
27
I'll dive into the actual code in future threads, but if you feel like diving into that there are two beautiful tools to do so:
- DETH by the legends at
@dethcrypto
:
- ContractReader by our one and only
@backseats_eth
:
1
2
32