how are the layers going on chain?

All images are being converted to strings using base64 encoding. We are using the SSTORE2 library to store all of the base64 strings. Since each image string can span multiple contracts for storage, we use a “linked list” of sorts with the addresses to each chunk.

What is the deployment cost?

This depends on gas prices when we deploy, however, we are estimating anywhere between 50-100 ETH. Gas prices have been a bit volatile recently.

Will the contracts be immutable?

Yes, after a certain point. We will have to leave some things open initially to ensure smooth deployment. We have included a lock function in the contract so that when we are ready, everything gets locked and is truly immutable.

Are the contracts upgradeable?

NOPE! We are using standard ERC721 contracts. There are a few functions that allow us to change and update things while we deploy, however, all contracts will have a lock function to make them immutable when all is settled.

Are the contracts connected?

Yes! Phase 2 contract will look at phase 1 owners for the airdrop (this only happens once, and then never looks at contract 1 again). The phase 3 contract will always look at phase 2 contract to retrieve trait layers any time mfer metadata is requested (via tokenURI).

Will there be any contract features in addition to the ERC721 features?

No, keeping token functionality pretty standard (ERC721, ERC721Metadata) with the exception of the ownerOf function so that all on chain tokens reflect owners from the original mfer contract.

How are the images optimized, compressed, altered before being put on Ethereum?

Here is the general workflow:

• Original images (112 total traits - 103 from the og collections, 9 additional traits)
• Trim all transparent space around images
• This decreases file size, however, now we have to keep track of position coordinates when we bring pieces back together
• Compress all trimmed images
• We use an online compression tool that reduces file size with various techniques (reduced color depth, dithering, etc.)
• Convert compressed images to Base64 strings
• This is the final step before adding images on chain

What did we reduce the file size of the images to?

We trimmed all the transparent space around traits and used online compression tools to minimize file size.

How does the shadow token generate its image?

Whenever onchain mfer metadata is called (tokenURI), the onchain mfer contract gets each trait from the layer contract and assembles the images on an svg. The svg has a resolution of 1000x1000 like the original mfer art.

What is a shadow/soul-bound/non-transferrable token?

What we call a shadow token or soul bound token is essentially a token (onchain token) that always shows the owner as the OG mfer token owner. So if I look at the on chain collection and ask the chain for the owner, our contract will take the request, look at the original OG contract and provide back that owner.

Does the onchain mfer token appear in the owner's wallet that owns the OG mfer token automatically once the contracts are deployed onchain?

Unfortunately, no. If you were to look up the owner of an onchain token, it would show the OG token owner (mirror). For the onchain token to appear in the OG token holders wallet, they need to make a tiny transaction that essentially updates all the marketplace information (it emits the transfer event notifying everyone who the owner is).

Does moving/buying/selling the mfer cost more gas with the shadow token?

It won't! So the contracts are only connected one way. Onchain contract looks at the OG mfer contract but OG mfer contract doesn't look at the onchain contract. So if you buy or sell an OG, all costs remain unchanged/unaffected.