The first thing that comes to mind when reading the title is, why bother?

The honest answer is that it seemed like a fun challenge and it was. In the end, I came up with a unique data storage method that saved me more than 9 Eth in transaction costs by reducing the total data by ~90%.

Before we jump into the how, let's explore what Baby Pepes are and why it was a challenge to put the whole collection on-chain at a reasonable cost.

Also, fair warning, things are gonna get pretty geeky.

What are Baby Pepes?

Baby Pepes are a generative NFT collection of 20k animated pixel art pieces, inspired by the infamous Pepe created by Matt Furie. We wanted to build a derivative to celebrate the randomness of Pepe meme culture and inject a little fun back into NFTs. You can view the collection on Opensea:

🐸 https://opensea.io/collection/babypepes

Why is it a challenge to put them on-chain?

Each token is constructed of four animated layers:

• Background (yep, even the background)
• Body
• Hat
• Face

Each layer has a trait and for each trait, there are multiple possible GIFs that could be used; the background layer has 6 possible animated traits, the body layer has 93, the hat layer has 99 and the face layer has 67. Making a total of 235 GIFs.

For Baby Pepes to be fully on-chain and work with zero centralized dependencies, I would need to store all those GIFs on-chain.

So, just do that, right?

Sadly, storing data on-chain is really expensive, like stupid expensive.

Every day NFT flippers and collectors are complaining about gas prices and they, for the most part, are initiating cheap transfers. We would be writing large blocks of data to the blockchain.

To give you some idea of just how much data, below is what the above orange animated background looks like in data form (base64 encoded):

And that is just one of 6 backgrounds. We would also need to write all the other animated layers to the blockchain.

In that form, all that data writing would easily cost more than 10 Eth and that’s if gas is 15–17 gwei.

The next problem we face is storing token trait information for all 20k pieces. Each Baby Pepe has four traits that are described with a trait id. Think of it as the genetics describing what each Baby Pepe looks like:

It looks simple enough, get the trait ids and string them together to form the longer number. And honestly, it is that simple. The problem arises when you have 20k of them and all that data needs to be stored on-chain.

Finally, all the data needs to be structured in a way to help reduce the size and cost.

To recap, the issues are:

1. Writing data on-chain is expensive
2. GIFs are large data structures
3. The gene pool is a lot of data
4. Finalizing data, optimizing and structuring for retrieval

Let's explore solving those issues

Problem 1: Writing data on-chain is expensive

There is nothing I can do to change the cost of writing data to the blockchain short of joining the Ethereum team and somehow creating a cheaper method. And that aint gunna happen cos I suck at Go, Im not that good at Solidity and Vitalik is an uber GOAT.

That leaves me with two options:

1. Use a cheaper method of writing data on-chain
2. Write as little as possible to save on costs

Finding a Cheap way to write data on-chain

Writing directly to storage for the amount of data I need to write is not only prohibitively expensive, but it also adds an additional layer of complexity in terms of utilizing it. Luckily SSTORE2 can be utilized to efficiently read and write data as byte code contracts, which solves half my problem as explained with the following nerdery;

Reading with SSTORE2

source: https://github.com/0xsequence/sstore2

Reading data is a lot cheaper compared to native SLOAD operations (native solidity storage).

Writing with SSTORE2

source: https://github.com/0xsequence/sstore2

Writing data is also cheaper than native SSTORE operations (native solidity storage), but gains become apparent after higher data sizes.

So SSTORE2 seems like a great fit. However, I would ideally like to be able to read my data bundle as a single block of data and not have to pick at byte contracts — cos I'm lazy.

How to read and use my data bundles

For large data sets like mine, I will have to break the data into 24kb chunks and write each separate chunk as a byte contract, and when I want to use the data I need to pull all the data from all the chunks and concatenate it back into a single data set.

That all sounds horribly complicated. However, whilst I was experimenting with on-chain storage for the creation of CryptoCoasters I was inspired by dhof’s rose:

dom on Twitter: "ROSESprocedurally generated in 3d + served fully on-chainsupply 1024 (32 reserved)NOT CURRENTLY MINTABLE. minting - like rendering - is modular & upgradable. will share details once determinedbrowse the first 32 https://t.co/cEmisHnJ3dtechnical details coming shortly pic.twitter.com/x83melUxAJ / Twitter"

ROSESprocedurally generated in 3d + served fully on-chainsupply 1024 (32 reserved)NOT CURRENTLY MINTABLE. minting - like rendering - is modular & upgradable. will share details once determinedbrowse the first 32 https://t.co/cEmisHnJ3dtechnical details coming shortly pic.twitter.com/x83melUxAJ

It helped me to fully understand how to utilize SSTORE2 for writing and retrieving large amounts of data on the blockchain. After a lot of experimenting, I came up with this code to concatenate data chunks into their original form:

That code has since been used in EthFS (source: https://github.com/holic/ethfs/blob/main/packages/contracts/src/File.sol) and Scripty of which I am a co-author. Both libraries aid in the writing and reading of large data sets.

For this project, I opted to use Scripty storage. Mainly because we just finished creating version 2 and I wanted to demonstrate just one of its many uses:

GitHub - intartnft/scripty.sol: A gas-efficient HTML builder that can combine multiple JS and a data storage solution that allows on-chain composable generative art.

Ok, so all that geeky stuff solves my issues with how to write data and utilize it on-chain. Thats great! Now to figure out how to reduce the amount of data I needed to write.

Problem 2: Handling GIFs on-chain

The section header is a little misleading, but it does illustrate what I was thinking I would have to do. In reality, I decided that GIFs were just too cumbersome to put on-chain for this particular project. I needed to find a new way to build my animated tokens.

Bastardizing GIFs

HAHA, ok this title is more on the money.

I have an extensive background in building and optimizing websites for performance and SEO, as well as a background in game development. Both of which make use of sprite sheets.

In gaming, character sprite sheets are used to render animations by displaying each separate frame in sequence. The sprite sheet simply houses the images. GIFs hold the same information but also a lot of additional data like the duration of each frame and a bunch of other stuff we don’t really care about.

This means if I could find a way to use sprite sheets instead of GIFs I could reduce the amount of data I have to store — that’s a huge win. The only problem was figuring out a nice method.

At this point, my goals were:

1. Find a way to display the final tokens that could be displayed via the “image” attribute in the metadata. This is crucial because I want the token to be animated in the Opensea previews as well as the larger views.
2. Use sprite sheets
3. Reduce data to be stored

Displaying as an image

After a lot of playing around, I converted a few traits into sprite sheets and threw them into SVGs. You can see an early example here (https://codepen.io/xtremetom/pen/MWzZjWj):

That early example doesn't work on a lot of browsers or mobile. It took a lot of trial and error to perfect the structure for cross-browser and device displays, which resulted in this (https://codepen.io/xtremetom/pen/poQqEvy):

The way it works is pretty simple. The token is made of four sprite sheets all layered on top of each other like this on the z-axis:

The viewer can only see a small area (red) and everything outside of that viewing area is hidden:

Each frame is presented for a fixed period of time and then the whole sprite sheet is shifted to the left so the next frame of each layer comes into view.

Once the cycle is complete, after 24 frames over 2.4 seconds, the sprite sheets return to their starting position and the cycle repeats. This creates the animation loop cycle.

This was a great step in the right direction, but I felt the sprite sheets, although they were considerably smaller in data size, were still too big as you can see in this comparison between the GIF and the sprite sheet.

After a little playing around I was able to find a nice way to optimize the sprite sheets using https://pngquant.org/ and this was the final result:

For those that aren't keeping track, that's a 10000000% reduction in data size — almost, it is actually ~98%, which is insane :P

With that adjustment, I created a simple Python script to iterate over all the GIFs and convert them into optimized sprite sheets.

Problem 3: The gene pool is a lot of data

Sadly, there is not much I can do to reduce the size of this data structure. Each Baby Pepe has four traits and I simply need to store that information for 20k tokens.

If each genome is 4 bytes long, that means I can store four numbers up to 255. I know the highest trait Id I currently have is 98, so 4 bytes is perfect and leaves potential room for growth.

All I have to do is cram all the genomes together into one very long data set and boom, we have the final gene pool. Additionally, because we know each genome is 4 bytes long it's very easy to extract data for a specific token Id. We simply slice the gene pool using the (token Id -1) x 4 as the offset.

Perfect. At this point, I solved my first three issues and had a way to display the animations and methods for reducing the size of the image data. Next, I had to figure out what other data was needed and how I should structure it and minimize it.

Problem 4: Finalizing data, optimizing and structuring for retrieval

Ok, time to get geeky again — time to introduce Professor Pepe:

Some of you may already see a big issue with my approach.

How exactly are you storing the sprite sheets on-chain in a way that allows you to retrieve a specific trait?

For anyone wondering why this is an issue, let's break down the problem.

Imagine I am trying to save two separate sprite sheets on-chain. We already know we aren't saving the actual image as you might when you drag and drop something with an upload system on a website. Instead, we have to manage all the data ourselves. For the sake of this explanation we are going base64 encode the sprite sheets. The result for the two images will look something like this:

It doesn't look so bad when separated like this, but I will be packing the data together and adding on a lot more data, and that ends up looking like this:

It starts to become very hard to distinguish image data and that is the problem. In order to use the image data I need to be able to extract data for a single image from a dataset of roughly 300 images.

Structure data for slicing

Slicing specific data from the huge data set is the obvious solution. However, I don't want to handle the massive data set for every trait for every layer. That would waste gas and I need to be mindful of gas consumption. The solution I landed on was to group trait data into layers. That way I could slice all the body data into one variable and handle that to extract the required body sprite sheet. Structurally it looks like this:

Ok, that all looks great, but I bet some of you are wondering how I actually pinpoint the data I need and extract it.

I know the length of data representing each sprite sheet. I can use that to calculate and store the index of the last byte of data for each. As long as I store that information in the same order as the trait Ids, I don't have to store anything else and I can use that to slice up a layer of data to extract any trait data I need.

Wow, that's a mouth full and certainly hard to visualize, so hopefully this example helps:

The same can also be done when packing the layer bundles into the final collection bundle:

Now that I have the data extraction method sorted, I just need to make sure there is no more data I need to pack in. I probably should have thought of this first but I pretty much made all this up as I went.

Adding in Trait Names

Turns out, I also need to pack in the trait names as the metadata for Baby Pepes includes the names for the traits. I could store that data in its own data section at the end of my big trait data set, but then I would also have to store more data to handle that data.

That just feels too messy and inefficient.

Instead, I opted to create a Trait Bundle. The Trait Bundles consist of the sprite sheet data, the name of the trait, and finally the length of the name. It looks like this:

This structure allows me to store minimal information and still easily unpack the data with these steps:

1. Extract this Trait Bundle from the Layer Bundle as previously explained
2. Extract the count
3. Use the count to extract the name
4. Extract the sprite sheet data

Perfect, well nearly. There is still excessive data being stored due to the data format. We can optimize this data by at least 33%.

Optimizing Bundles

Anyone familiar with sending data over sockets and Redis probably already knows the key optimization Im about to share.

I can save about 33% in data size by storing all the data as bytes. By using base64 encoded sprite sheets Im adding roughly 33% to the data size — not good!

So, we keep the images as bytes. In fact, we store everything as bytes.

The count becomes a single byte, easily capable of storing the length of any trait name up to 255 characters long. The name can be up to 255 bytes long. The image data is as long as it needs to be.

But wait we can still do better and we are about to get into a whole new level of geekiness.

PNG Structure Manipulation

PNG images, like the ones I'm converting the animated GIFs into, have a defined structure. They have to, otherwise, the internet would fall apart and all your fav memes would catch fire.

If you can be bothered to take a look, there is a nice Wikipedia page that describes the PNG structure among other things:

PNG - Wikipedia

But for the lazy, let me explain how I used this structure to save on data storage.

Simple PNGs like the ones I'm handling have the same basic structure. They all share the same PNG signature and most of the data in the image header. This repetition of data means I can trim off the first 24 bytes from every image. I store those 24 bytes directly in the contract and every time I use a sprite sheet, I simply bolt it back on:

That little trick saved me an additional 6,360 bytes — don't laugh, it all adds up :)

Next, I have to figure out how to handle the custom data of 1/1s.

Adding 1 of 1s to the data bundle

We can't move all the Baby Pepes on-chain and forget about our awesome 1/1s, like Pepechu and Sexy Pepe:

However, these tokens pose a new problem. They aren't made up of multiple layers and traits. Each 1/1 is a single GIF and has no trait ids to build from.

Luckily the solution was pretty straightforward. I created a data bundle, especially for the 1/1s. Think of them as having a single trait, that's exactly how I treat them. All the 1/1s bundles create their own special layer bundle. I simply use it as per all the other bundles.

Quick and easy now that we have a data handling model all planned out.

Awesome, that was the final issue that needed solving. We now have a data model and plans for retrieving any data we need — it's Solidity time!

The Solidity Contracts

By now, I'm sure most of you that are interested in on-chain NFT contracts have studied enough to know how they generally work, so I'm not going to pad this already long article out any anymore. Plus my code is heavily commented.

OnchainRenderer.sol:
https://www.contractreader.io/contract/mainnet/0xc4fca7eb2087568829e4b493adda247a11f0c966

BundleManager.sol:
https://www.contractreader.io/contract/mainnet/0x75d71b583de37f2be7b271a79954055656620e7a

However, we do we still need to get the data on-chain.

To achieve this, I created a ton of Python scripts to build the bundle structure as described above. To make life easier for me, I made sure to save all the final data in hex format. I wanted to retain some readability for testing and playing with the data.

The final outcome was two files

1. gene_pool.txt (80,000 bytes)
2. collection_bundle.txt (201,423 bytes)

Next, I had to create a nice way to get all the data bundles on-chain. Luckily 0xthedude and I had just completed Scripty V2, which comes with a nice facility to store massive data bundles on-chain.

I jumped into Hardhat (I know, I know, Foundry FTW) and threw together this simple script to chop up my final files and store the data via the Scripty storage script:

Just like that Baby Pepes move on-chain — easy O.o
The final cost for all the transactions was ~1.075 Eth

You can find the collection on Opensea:
https://opensea.io/collection/babypepes

Join us on Twitter (X):
https://twitter.com/baby_pepes

Check out our website:
https://www.babypepes.com/

How I put an NFT collection of 20k animated GIFs on-chain and saved 9 Eth on gas was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Below is a list of just a few simple ways you can save gas in solidity contracts. The full list is seemingly endless, but all boils down to finding the most efficient way to perform an action with the minimum number of operations.

Table of contents

1. State data vs bytecode data
2. The power of do-while vs for loops
3. i++ vs ++i
4. Ignore safe maths — unchecked{}
5. Sticking to preferred data types
6. Calldata vs memory
7. Use memory to cache read variables
8. Efficient variable management
9. Save gas on the first write
10. Calling struct data

1. State data vs bytecode data

By storing _b as a constant it is stored as immutable data in the contract’s bytecode. The same goes for our magic number 1000. _a on the other hand is stored in the contract’s state and requires a SLOAD operation to read it .

2. The power of do-while vs for loops

Loops are pretty standard in almost every coding language and that familiarity can make us complacent.

The standard for loop will check the condition before executing the statement. A do while will execute the statement at least once before and then check the conditions, allowing for gas savings.

Word of warning: Only use a do-while when you are certain the code should execute at least once and remember to handle your conditions to prevent an infinite loop and gas out.

For information on how do-while loops differ from while loops, check out this article:

Difference between while and do-while: Explained with Examples

3. i++ vs ++i

I know, I know, its a little crazy looking but the numbers dont lie — but why is it cheaper?

i++ increments the value of i by storing the original value in memory, incrementing it, then storing the resulting value into temporary memory and returning the original value. Upon that return the new value of i is updated. All in all it takes 4 operations.

++i increments the value of i and returns that value, which takes 2 operations.

4. Ignore safe maths — unchecked{}

From Solidity docs:

https://docs.soliditylang.org/en/v0.8.0/control-structures.html#checked-or-unchecked-arithmetic

Prior to Solidity 0.8.0, arithmetic operations would always wrap in case of under- or overflow leading to widespread use of libraries that introduce additional checks.

Since Solidity 0.8.0, all arithmetic operations revert on over- and underflow by default, thus making the use of these libraries unnecessary.

To obtain the previous behaviour, an unchecked block can be used:

Which means you can save gas by employing the unchecked block to avoid unnecessary checks on your ++i.

In the example code above it is safe to do this because we know ++i will not overflow 2²⁵⁶, both of our loops will stop processing when i == 200

5. Sticking to preferred data types

EVM (Ethereum Virtual Machine) is driven by 256 bit (32 bytes) variables. This means that in our loop above, the uint16 variable is converted to a uint256 before it is used, this conversion costs gas.

As you can see, we save gas by using uint256 for the variable i.

6. Calldata vs memory

From Solidity docs:

https://docs.soliditylang.org/en/v0.5.11/types.html?highlight=memory#data-location

Calldata is only valid for parameters of external contract functions and is required for this type of parameter. Calldata is a non-modifiable, non-persistent area where function arguments are stored, and behaves mostly like memory.

Its is suggested to try and use calldata where possible. It avoids unnecessary copies, hence the lower gas price and ensures the data is immutable.

Worth noting that since solidity 0.6.9 usage of memory and calldata is not limited by the visibility of the function.

For more details about the differences between storage, memory and calldata checkout this article:

Solidity — Storage vs Memory vs Calldata

7. Use memory to cache read variables

Accessing a cold storage variable (first read) costs 2100 gas and 100 gas there after — warm storage access

You can save gas by caching the storage variable and reading the cached data instead of the storage data. This also works when reading data from a storage array.

In the above example we are storing _arr in memory of SaveGas2 > loop(). All reads are then called from our new arr.

This is a great gas saving method as long as the storage array is not too big. The data has to be copied to memory, so big arrays will be inefficient.

8. Efficient variable management

If you plan on reusing a variable like solution and you know it will not inherit value from the previous loop, you can save gas by defining the variable outside of the loop — compare loops in SaveGas and SaveGas2.

Additionally, if you know there is no risk of overflow you can save more gas by nesting your solution calculation within the unchecked block.

9. Save gas on the first write

Changing a storage value to non-zero from a zero value will cost 20000 gas and all non-zero nth writes will cost 5000 gas. We can save the first user to call the function some gas by defining a non-zero value for _data.

10. Calling struct data

EVM stores data sequentially, trying to pack everything into 256 bit slots (32 bytes). In the example above, the struct data is arranged so x and y will occupy a single 256 bit memory slot and z will occupy its own slot — nice and tidy.

When it comes to reading our values we can save gas by minimizing how many memory slots we have to read and or cache.

SaveGas > getUserZ() is storing the relevant MyData struct in memory — making a copy of both memory slots and then reading the relevant data.

SaveGas2 > getUserZ() is reading data from the single memory slot containing z.

Where to find me

I can normally be found in the Cool Cats discord channel
https://discord.gg/WhBAAHnSz4

Or on Twitter
https://twitter.com/xtremetom

JavaScript is not available.

New to trading? Try crypto trading bots or copy trading

10 Simple Ways to Save Gas with Solidity was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Chances are you have interacted with a smart contract and thought — geez that was expensive. I know I have.

The culprit is usually the number of writes to storage or just simply bad logic. I cant help too much with bad logic, that usually comes with experience and trial and error. I can help by showing you a cool way to potentially reduce how many writes to storage your contract might need.

What is data packing?

We are used to seeing a unit256 as type definition for a variable:

uint256 number = 1

However, that uint256 is simply a data type that houses 256 bits. Clearly our little 1 is not using up all 256 bits, so how do we use up the other bits?

Uint256 is not the only available uint, if you know a variable will not exceed certain values you can start using smaller types. If you know a value wont exceed 2⁶⁴ you could use a uint64 and this it where things get interesting.

256 / 64 = 4

If uint64 uses 64 bits, that means you can pack 4 uint64s into a single unit256.

Gwei is a Solidity constant:
https://docs.soliditylang.org/en/v0.8.15/units-and-global-variables.html

That function outputs the following number:

25108406941546723056364004793593481054836439088298861789185000000000000

If we feed that number into this function, it will output our original gwei:

Pretty cool right?
With data packing we can store multiple variables of smaller value types in a bigger value type.

Lets look at what is actually happening.

How does data packing work?

Packing the data

Lines 2–5: Defining our data as uint64. I use gwei cos I’m lazy and wanted some big values without typing a lot. Its safe to use these values as I know they do not exceed 2⁶⁴.

Line 7: packed is already defined as a unit256 in the returns of the function. Here we are setting the value to eth1k. This occupies the first (right to left) bits in the unit256.

192 bits | eth1k (64 bits)
// packed = 1000000000000

Line 8: We use the bit wise OR assignment operator (|=) to performs the bitwise OR operation on the binary representation of the operands and assign the result to the packed.

In our case we are casting eth2kto uint256 and shifting it left (<<) by 64 bits because we know the first 64 bits are occupied by eth1k. Which will result in packed looking like this:

128 bits | eth2k (64 bits) | eth1k (64 bits)
// packed = 36893488147419103233000000000000

Line 9: Again we use the OR operator, and shift eth3kleft by 128 bits. We know eth1k occupies the first 64 bits and eth2k occupies the second 64 bits. Resulting in packed looking like this:

64 bits | eth3k (64 bits) | eth2k (64 bits) | eth1k (64 bits)
// packed = 1020847100762815390427017310442723737601000000000000

Line 10: Same as line 9 but shifting eth4kinto the last available 64 bits:

eth4k (64 bits) | eth3k (64 bits) | eth2k (64 bits) | eth1k (64 bits)
// packed = 25108406941546723056364004793593481054836439088298861789185000000000000

Unpacking the data

Line 2: We know that eth1k occupies the first 64 bits, simply casting packed (uint256) to uint64 isolates those bits and gives us eth1k.

Line 3: eth2k sits in the next 64 bits. We can use the same trick as we did with eth1k, we just have to move eth1kout of the way. We can do this by shifting packed to the right (>>) by 64 bits:

64 bits | eth4k (64 bits) | eth3k (64 bits) | eth2k (64 bits)
// eth1k has been pushed off the end :)

Line 4: eth3k sits 128 bits to the left, so if we shift packed 128 bits to the right (>>) we can use the trick from line 2:

128 bits | eth4k (64 bits) | eth3k (64 bits)
// eth2k + eth1k have been pushed off the end

Line 5: eth4k is 192 bits to the left of packed, repeat the same trick from line 4 and we have our data:

192 bits | eth4k (64 bits)
// eth3k + eth2k + eth1k have all been pushed off the end

How does data packing save gas?

Amazing, we can pack and unpack data, but why bother?

Writing to storage less saves gas and in the above example you can see writing the packed data to the mapping instead of the four separate variables saves a massive 66,470 units of gas. This is because we are doing a single write instead of four separate writes.

Structs or data packing?

Data packing really shines when you use it in place of structs, like this:

wow, that is so much more code

Yes, there is more code. You have to pack to store the data and unpack to use the data. However, if the data being packed is updated and stored regularly the gas saving really add up and your users will thank you for looking out for their wallets.

Packing addresses: Ethereum addresses are 20 bytes long. In order to pack them in a unit256 we need to cast them to a unit160 — see line 37

Unpacking addresses: To get an address from a unit160 you simply use the address cast on your uint160 address — see line 49

Nested packed data: Yep, you can nest packed data. Above we have taken an array of 6 uint16s and packed it into a unit96. We can then pack that into our uint256 — see lines 29–38.

Unpacking nested packed data: First you need to obtain your nested packed uint and then unpack as you would any other data — see lines 52–59.

Cool, what else can I do?

Anywhere you have data you can employ data packing and its not restricted to uint data types.

One really nice use case is storing data in the id of an NFT. This would allow you to serve up deterministic data without having to write to storage.

More, I need more information

Bit manipulation is fun and this is just the tip of the iceberg. If you would like to dive deeper I highly suggest checking these articles out:

• Solidity Tutorial : all about Bytes
• Bitwise Operations and Bit Manipulation in Solidity, Ethereum

Where to find me

I can normally be found in the Cool Cats discord channel
https://discord.gg/WhBAAHnSz4

Or on Twitter
https://twitter.com/xtremetom

https://twitter.com/coolcatsnft

Save Gas with Data Packing was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you have used Cooltopia, you will know that you only need to authorize your account once via a signed message. After that, you will no longer see any wallet popups asking for permissions. You don't have to pay for any transactions and the whole system runs on Polygon, while you are connected to Ethereum.

It all feels a little counterintuitive and confusing, but the end result is a system that allows users to freely interact with Cooltopia without interruptions or worries about spending too much on transactions.

So how did we achieve this?

Ethereum and Polygon

In designing Cooltopia we wanted to make it really simple for new NFT/crypto users to interact without the need to buy MATIC and swap chains on Metamask. Explaining how to fund a wallet with Eth is hard enough and for first-time users, it's scary.

Luckily Polygon is EVM-compatible.

Among other things, this means we can write Solidity code designed for Ethereum and it will also run on Polygon. This opens a lot of doors

Shared Addresses

Your address on Ethereum is also your address on Polygon. Of course, the tokens held on Ethereum are not mirrored on Polygon.

Think of your address as a house and that house exists in two somewhat parallel universes. Same street and town address and both houses start empty. As you buy furniture in the Ethereum universe it gets added to your Ethereum house, but not your Polygon house and vice versa.

Shared Signatures

The beauty of having a shared address and EVM compatibility is that you can sign a data packet on Ethereum and pass that signature to Polygon and it is still valid.

When you authorize on Cooltopia you are connected to Ethereum and sign the following data:

Note: Always take note of anything you sign with your wallet. Signing unexpected data could result in a wallet hack. For this reason, we make all our signature requests human-readable and not hashed data

Once the data is signed by you, the signature is passed to our Polygon contracts where we run a few security checks to ensure the data is unique and actually signed by you.

We never store any signatures :)

There are a few points to note here:

• msgHash: We rebuild the expected message to ensure the signature matches
• _isValidSignature(): The msgHash is checked against your address and the signature to verify that you have requested this connection

If you would like to learn more about signature verifications have a look here:

Verifying Solidity Signatures

Let’s look at why we require you to connect in this way.

Access Control

Access Control is exactly as its name suggests. A system to control who has access to certain features and functions. You can think of it as a system to grant users things like moderator and admin permissions.

Access Control - OpenZeppelin Docs

Cooltopia Roles

Our contracts use three main roles:

• ADMIN_ROLE: Used to make changes to game settings for the purposes of balancing and maintenance
• CONTRACT_ROLE: Refers to contracts within our system. Sometimes they need to fire off functions within other system contracts and this role allows for that
• GAME_ROLE: Used for requests coming directly from users playing the game

Possibly a little confusing without an example so let's look at how the ItemFactory plugs into the system and what happens when a user buys a Pet Chest.

Connecting Contracts

Below is an ItemFactory.sol contract that connects to the SystemChecker.sol contract via the HSystemChecker.sol

Notice that ItemFactory.sol line #17 passes systemCheckerAddress as a parameter to HSystemChecker which it extends.

Looking at HSystemChecker.sol line #14 you can see we have connected to SystemChecker via an interface.

Note HSystemChecker.sol does not extend SystemChecker.sol. This is because we need to access the data that exists within the contract and not just the structure.

After all this connecting, ItemFactory can use the modifiers onlyRole and isUser . With access to these modifiers and the ability to access the data stored in SystemChecker.sol, we are now ready to use the roles that were detailed above and let users buy Pet Chest.

Buying a Pet Chest

Before we follow the flow of buying a chest, a quick recap.

User State:

• Connected to Ethereum
• Authorized on Cooltopia
• Sat on the shop with MILK and ready to buy

Contract State:

• ItemFactory.sol extends HSystemChecker.sol
• HSystemChecker.sol has access to SystemChecker.sol
• ItemFactory.sol can access SystemChecker.sol data via modifiers

Time to buy

A user requests to buy a Pet Chest by interacting with the web UI. The request is passed to our system which in turn fires off the transaction on Polygon (did I mention we pay for all the gas? :))

The transaction hits the buyBox() function and the onlyRole(GAME_ROLE) checks that the transaction call originated from the Cool Cats’ system.

From there the function starts to run and then we hit the _mint() function. If you examine that function you will notice that it fires off the modifier isUser which checks that the user minting the Pet Chest is an authorized user.

If an unauthorized user tried to buy a Pet Chest, it would revert. Otherwise, all is well and the user mints a Pet Chest.

…

Wait, what about the burning of MILK?

Avoiding Popups

This is where the power of the Cooltopia authorization comes into play. When you authorized you hopefully took the time to read the notification:

You can think of authorizing as logging into a traditional game.

While you are logged into the game and playing, the game doesn't keep asking you to give permission for the action you just asked it to perform. Instead, it does as you requested (given that you have all the appropriate requirements — gold, items, etc). Thereby helping you to stay immersed.

Nice and streamlined for the user, but how do we achieve this?

Note: Cooltopia can only update Cooltopia related tokens. Granting authorization does not allow access to any other tokens in your wallet

When a user buys a Pet Chest the function treasury.burn() is called from within buyBox() on the ItemFactory.sol contract. As you can see on line #28 in the above code snippet, burn() uses the modifier onlyRole(CONTRACT_ROLE) .

When we deployed ItemFactory.sol we granted it the CONTRACT_ROLE which allows it to call treasury.burn() . If you were to call burn() from an address that didn't have the CONTRACT_ROLE , your transaction would revert.

treasury.burn() calls _milkChild.gameBurn() and this is where the users' MILK is burned.

gameBurn() can only be called by a contract with the TREASURY_ROLE . Given to the Treasury.sol contract upon deployment.

gameBurn() is where the anti-popup magic happens.

Remember that logged-in users have already agreed that Cooltopia can update their tokens as part of the gaming experience. With this permission, we transact on the users' behalf — simple yet powerful.

This prevents the user from being shown a permissions popup every time a token needs to be interacted with.

Token Ownership

Every token that a user earns in Cooltopia, goes straight into their wallets and if a user wishes to deauthorize (log out) of the game, they can:

In doing so, Cooltopia will have no ability to update their tokens any longer and the user still retains everything, free to sell and trade on the open market in places like Opensea.

Extending the System

Not only does this system allow for a nice user experience, it also makes contract upgrading extremely easy (with some caveats).

Contracts that produce tokens or store time-sensitive info can not be upgraded without the migration, things like the ItemFactory and MilkChild.

However, all other contracts can easily be decoupled from the system by revoking their CONTRACT_ROLE and ties to dependants. An upgraded contract can then be slotted in.

Community Contracts

The simple use of roles allows anyone to create a contract for Cooltopia and as long as it passes security and balancing audits (internal and public), it can be bolted on and ready to use.

Important Notes

The demo code snippets are taken from the live contracts and those are linked below each snippet.

I haven't explained all the features, there are a number of security features and structures that I won't detail.

As with all my dev blogs, use the code at your own risk.

Resources

• Cool Cats - Cool Hub
• ERC 1155 - OpenZeppelin Docs
• ERC 20 - OpenZeppelin Docs
• ERC 721 - OpenZeppelin Docs

Where to find me

I can normally be found in the Cool Cats discord channel
https://discord.gg/WhBAAHnSz4

Or on Twitter
https://twitter.com/xtremetom

https://twitter.com/coolcatsnft

Hopefully, you know that it is impossible to generate a random number purely on-chain. You need to use services like chainlink, but let's be completely honest, pseudo-random is usually good enough for most needs.

However, sometimes you need multiple random numbers and things start to get expensive in terms of gas.

Bit Shifting

Bit manipulation is really fun, or I have been diving way too deep into some very obscure articles. Either way, it's extremely useful and can be used to save you gas.

What is bit shifting?

This subject and other byte manipulation techniques have been covered by people that are far smarter and more experienced than me:

Bitwise Operations and Bit Manipulation in Solidity, Ethereum

How do we use bit shifting with RNG?

Ok, imagine you need to generate 10 random numbers for attributes on your RPG NFT. You could create something like this:

The problem is you have to call it ten times.

There is a nice solution:

Just like that we only need to create a single randomHash and then use bit manipulation to create the 10 required random numbers.

Its worth noting that bit shifting doesn't mean you can shift forever, you will run out of bits. If you have a uint256 variable and you are shifting >> 16, you can only shift 16 times, cos 16 x 16 = 256.

I personally find it easier if there is some visual explanation of concepts and thought others might find a visual of bit shifting helpful.

And here is what happens if you shift beyond the available data. uint256 >> 16, 20 times:

Random Number with Tracking

Sometimes you need to pick a random number from an existing list while tracking the numbers you have already picked.

In javascript this kind of task is trivial, but in solidity, you really have to put some thought into the methodology to save on gas.

Random TokenId from Fixed Population

Imagine you have an NFT project with 10k tokens and you want to mint them out in random order. Most methods require a lot of looping and storing of data, which can get expensive and run the risk of gassing out.

Magical Arrays

I have no idea what the proper name for this method is, so I just call it Magical Arrays :)

MAX_POPULATION: is the population count of the NFT we are creating.

ids: Is an empty array equal in length to MAX_POPULATION. If MAX_POPULATION is 5 then our array will look like this:

[0,0,0,0,0]

When pickId() is called a randomIndex is generated between 0 and the length of the array. This is important because we will be reducing the length of the array and ergo the range of possible randomIndex.

The next few lines of code are where the magic stuff starts to happen. I'll try to explain it as best I can.

First Pass

Imagine our array [0, 0, 0, 0, 0], it is 5 elements long but every element is 0. Feels a little useless right? Cool thing is, this is extremely helpful.

Imagine our randomIndex value is 2. We check index 2 in the array and we can see the value is 0 so we set our return value of id to the index we just checked, 2.

[0, 0, 0, 0, 0]
[2] = 0
id = 2

Now that we have an id value we need to edit our array to reflect what just happened and to ensure we don't lose any ids. Sounds like a lot to expect from an array.

If we don't edit the array a randomIndex value of 2 would result in the exact same return value and we don't want two NFTs with the tokenId of 2. To solve this problem we check to see if the last element in the array is equal to 0

if(ids[ids.length-1] == 0)

If it is, we replace the value at ids[randomIndex] with the index value of the last array element. That looks like this

randomIndex = 2
[0, 0, 4, 0, 0]

Finally, we need to shrink the array by popping off the last element. This results in our array now looking like this.

[0, 0, 4, 0]

Second Pass

When we pick our next id the randomIndex value again comes out as 2. Feels like this could be a problem, right — nope we got this covered.

First, we check if the value in the array at index 2 is equal to 0. We can see that it is equal to 4

[0, 0, 4, 0]

In the first pass, our index value was equal to 0 and so we returned the randomIndex value of 2. This time we have a value of 4, so we return the 4.

Just like the first pass, we need to edit the array to reflect what just happened. Resulting in our array now looking like this:

[0, 0, 3]

Third Pass

Wouldnt you know it, randomIndex rolled another 2.

This time the value at index 2 is a 3, so we will return 3 and edit the array to reflect the event.

This time things are a little different, the last value in the array is not equal to 0 and so we have to do things a little differently and the resulting array ends up being

[0, 0]

Magic Array

I know this can be a little tricky to get your head around and the first time I played with it I was mapping arrays out on paper just to make sure I fully understood the concept.

Christmas Teaser

The magic array code sample above can be optimized, can you see how?

Where to find me

I can normally be found in the Cool Cats discord channel
https://discord.gg/WhBAAHnSz4

Or on Twitter
https://twitter.com/xtremetom

https://twitter.com/coolcatsnft

Last Word

I feel silly saying this, but I have had so many messages I feel it might save you and me some time.

I work full time on Cool Cats I am swamped with work, so sadly I have to decline every job offer.

But I am always willing to help out by sharing resources and advice where I can.

New to trading? Try crypto trading bots or copy trading

Solidity — Random Numbers was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Processing everything on-chain is great, but not always practical and sometimes you might want to do something a little tricky in order to save users gas.

Sadly, simply passing the desired data to a contract is not secure and without security measures, people will certainly abuse your contract.

There is a nice solution to this issue.

Solidity signatures and signing data

You can bundle desired data into a hash and sign it with the desired wallet.

Below you can see me running a very simple signing on hardhat where I am treating the signer[0] as my backend.

On line #45 you can see I am connecting to the sigTest contract as userWallet and firing off the isDataValid function. Passing in the timestamp and signature. Let's jump over to the contract to see what happens next.

Looking at isDataValid() we can see that the first thing we do is build the hash in the contract, using the same data as we used on the client. The resulting msgHash should be equal to the messageHash on the client. If there is any discrepancy in the data, the hashes won't match and the signature test will fail.

Still looking at isDataValid() you can see that it fires off a require and calls isValidSignature(). Here we have to first sign the hash. It might seem arbitrary to pack in \x19Ethereum Signed Message:\n32, have a good Google to understand the importance of it — its very interesting from a security point of view.

With the data signed we can utilize the ECDSA library to recover an address bashed on the has and signature.

If the recovered address matches the systemAddress, all is well and we consider that a success, else, fail.

I won't go into how the ECDSA library works as I believe it's important for developers to learn how to read other contracts and Google around to fill in knowledge gaps, plus I don't wanna ruin the fun :)

openzeppelin-contracts/ECDSA.sol at master · OpenZeppelin/openzeppelin-contracts

Important Notes

The code I have provided is in no way production-ready. It was written extremely fast and with no testing.

Tracking nonces is a nice feature you should look into adding to this code. It helps avoid replay attacks.

References

• https://solidity-by-example.org/signature/
• https://blog.ricmoo.com/verifying-messages-in-solidity-50a94f82b2ca
• https://yos.io/2018/11/16/ethereum-signatures/

New to trading? Try crypto trading bots or copy trading

Verifying Solidity Signatures was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

The first air dropper I created was a semi-auto dropper that required a fair amount of manual data entry. Not ideal, prone to human error and slow. At the time it made sense due to time constraints. For the TIME collaboration drop I wanted to create an air dropper that would be capable of firing off hundreds of tokens in seconds.

Before we dive into the code, I need to say that this article is not going to give you 100% of the Cool Cats’ air dropper source code. It will however cover the theory and point you in the right direction to start work on your own dropper. I do this for two reasons

• I believe an engaged developer that understands every line of their code is more capable of fixing any issues or making changes to fit new scenarios
• Cool Cats needs to have some hidden secrets.

As you read this article and code, please keep in mind that I am pretty new to solidity development and the solutions I come up with might not be the most efficient. Always take the time to do your code due diligence.

Air dropper theory

The idea behind the contract was to essentially act as a wallet. It needed to be capable of:

• receiving tokens
• sending held tokens to addresses
• resetting

Receiving tokens

This might seem like an intuitive action — just send tokens to the contract, right? Nope. I tried that and all transactions failed.

After some head scratching and Googling, it hit me. The contract needs to explicitly have token holding capabilities defined:

As I intended to send ERC1155 tokens to the contract it needed to know how to hold them.

Recognising tokens

The contract is able to receive and hold tokens, awesome, but it needs to do stuff with those tokens, like transfer them.

I had no idea how to do this until I found this code, for an ERC20 token as below:

The key part of this code for me was this line:

Of course, I need to define the token that is being moved around. Duh!

With that epiphany, I created the following function that uses a contract address to define the token and stores the tokenId for later use.

Dropping to addresses

This was the easy part. I simply send 100 addresses and the contract sends tokens to those addresses.

However, I have to stress again that the provided code is not 100% complete. There are situations in which this function will fail. Always make sure to run a full battery of unit tests and account for all edge cases.

Where to find me

I can normally be found in the Cool Cats discord channel
https://discord.gg/WhBAAHnSz4

Or on Twitter
https://twitter.com/xtremetom

https://twitter.com/coolcatsnft

Last Word

I feel silly saying this, but I have had so many messages I feel it might save you and me some time.

I have a full-time job IRL and coupled with Cool Cats I am swamped with work, so sadly I have to decline every job offer.

But I am always willing to help out by sharing resources and advice where I can.

Let me preface this article by saying, I speak to many NFTs owners and prospective owners. Nothing in this article is directed at any single person or NFT project. It is mostly a reflection of my personal experiences.

The Cool Cats team didn't expect things to grow as big or as fast as they did. It was a huge shock and in the first few days, I don't think any of us got much sleep. I hope this article helps another team to prepare for a similar situation.

The NFT plan…

I see a number of NFTs starting as a quaint idea. Cool Cats, for example, we wanted to create a family-friendly NFT that featured some cool and cute cats. Clon wanted to share his art with the world and Lynq and I wanted to learn more about NFTs, widen our code knowledge base, and perhaps draw more attention to Faticorns.

Building the actual NFT and all the separate pieces was more challenging than I first anticipated. I wrote about that here:

https://medium.com/coinmonks/what-i-learned-from-building-cool-cats-nft-4057f279d400

However, as difficult as writing the code and learning solidity (I'm not done, still lots to learn) was, nothing could have prepared us for what came next.

The NFT reality…

Marketing is hard

One of the hardest parts of running an NFT is getting eyes on it in the early days. Sure you can pay for ads and influencers to promote you but ask the wrong influencer and a percentage of the community will instantly hate you.

Try the slow and steady approach. By dropping progress reports as you go, you run the risk of never building up hype, and come launch day, everyone is numb to your awesome graphics and mechanics.

Do nothing till you are a week from launch and then blast Twitter. I have seen this work but it is very risky. Your hype train may never leave the station and on drop day, no one turns up.

To be completely honest, the landscape of NFT Twitter is changing so rapidly. A marketing mechanic that worked 1 month ago, might not work anymore.

I can only suggest that you take some time to research your favorite projects and the methods they used to gain traction.

Launch day

Stress, insane amounts of stress.

You will be surrounded by hundreds of people scrutinizing every decision you make.

If something goes wrong, you will be flooded with angry messages and your DMs will start pinging faster than you can respond.

If everything goes well, you will still be flooded with angry messages. Inevitably a number of people will not be able to buy due to gas or limited stock. As the NFT owner, you will be held responsible for everything.

Post-launch: Hours 1 to 12

Your new community should be happy with their new shiny NFTs, hopefully, most of them are. However, now new demands/questions start:

• when will you be listed on rarity.tools?
• where is your sales bot?
• why don't you have a Twitter bot yet?
• why doesn't the discord have channel x / y / z?
• why haven't you retweeted that celebrity x / y/ z has just bought your token?
• do you have a legal team I can talk to?
• what license does your IP fall under?
• can I sell t-shirts with my NFT on them?
• …

Post-launch: Day 1–3

Hopefully, you have managed to get some sleep, but I doubt it. You are probably running on fumes. Luckily your community has been sleeping well and they have filled your DMs with endless questions, rage-filled messages, and hopefully a message or two of support.

The messages of support I received really helped me to stay positive and motivated.

Laying the community foundations

Once you have made it through the first few days, the whales and flippers have likely taken their profits and your holder base is starting to grow. Now is the time to really focus on what kind of community you want to nurture.

The choices you make now are the foundations for how the whole NFT space will view your project and will heavily influence the type of people that buy into your NFT — choose wisely.

Managing your new community

I cant prepare you for what you will experience, but I can offer some tips based on my experiences.

I have run a number of companies. Nothing huge, mostly small consumer-facing businesses. Being small, I inevitably had to be very hands-on and a lot of my job would entail dealing with upset and angry customers. In doing so I learned a few golden rules that have served Cool Cats very well:

1. Always be honest: If you lie and the community finds out, they will tear you apart.
2. Explain your actions and reasoning as soon as possible: The sooner you can inform your community about changes and the reasons behind those, the better.
3. Always be thorough and think things through: If you can show that you have fully considered all points of view during your decision-making, that will help people feel heard.
4. Never ignore a problem: Most anger stems from people feeling that their desires are not being met or addressed.
5. Plan ahead: A reactionary response by nature will be ill-prepared and could cause more damage than good.
6. Plan for the best and worse case: Things won't always go as planned and the NFT space has a mind of its own. It is important to have plans and backups for when things go wrong
7. Involve the community as much as possible: If you have a tough choice to make, involve the community. They might surprise you and offer up a solution you never considered.
8. Stay calm: If the community can see you losing your cool, some bad actors will try to bait you. Take a step away from the situation (computer), take a few deep breathes, and re-enter calm and collect.

Parting thought

Next time you are in the discord of a brand new project, spare some time to support the team. They are only human and I'm sure it will be greatly appreciated. It certainly helped me and the whole Cool Cats team.

Where to find me

I can normally be found in the Cool Cats discord channel
https://discord.gg/WhBAAHnSz4

Or on Twitter
https://twitter.com/xtremetom

https://twitter.com/coolcatsnft

Last Word

I feel silly saying this, but I have had so many messages I feel it might save you and me some time.

I have a full-time job IRL and coupled with Cool Cats I am swamped with work, so sadly I have to decline every job offer.

But I am always willing to help out by sharing resources and advice where I can.

Cool Cats launched a little over five weeks ago, although it feels like much longer. In that time I have spotted a few projects using the Cool Cats contract as a base for their NFT. As such, I feel that I should outline contract improvements that I would make.

Trimming the fat

In reviewing my own code, I spotted a silly mistake.

using Strings for uint256;

My code never uses Strings. In a previous version of my code, I used Strings to concatenate a tokenURI output, but my deployed contract doesn't do this.

This could safely be removed.

Add IPFS provenance?

A number of people have pointed out that Cool Cats doesn't include a provenance hash, and why didn't I add one?

The honest answer is — I forgot.

I should have added a variable to hold the final image directory hash. This would have been extremely simple to do. It would also give people peace of mind that we won't be changing the images. We never would, but people like the security.

Owner only buying capability during a pause

I have seen a number of new projects that required a minting pause during their drop.

During the pause, they needed to be able to mint some of their own tokens. The Cool Cats contract does not allow for this and this was by design.

I didn't want people to think that the owner could sneak in a few purchases during a pause. However, having witnessed a few projects falling fowl due to this limitation, I would now add that functionality.

Send vs Transfer when withdrawing

The current withdrawal function works but is not optimal. Rather than having to use a require coupled with send, I could have simply used transfer.

• .send() returns a boolean result for success/failure.
• .transfer() reverts on failure

There are other considerations when decided which function to use and under certain situations, one may pose a security risk — always do your own research

Last words

You will notice that I have not included a gist of the updated contract. Sorry, but you really should be putting some brainpower into creating your own contract or at least fully understand the code you are using.

The Cool Cats contract is very simple, but even a simple contract can carry too much fat, mistakes, and unoptimized functions.

Never assume a contract from an existing project is bulletproof or perfect.

Do your own due diligence, you own it to your potential holders/investors

Where to find us:

My Twitter: https://twitter.com/xtremetom

Cool Cats Team: https://twitter.com/coolcatsnft

Cool Cats Discord: discord.gg/coolcatsnft

Setting up your first crypto wallet is hard, it's confusing, and almost every tutorial is over complicated and full of jargon.

It doesn't have to be. This is where Paper Cats comes in.

Friendly NFT/Crypto onboarding

We are creating a series of comic-book-style tutorials that use simple language and graphics to help anyone understand and use NFTs with confidence.

In our minds we are designing the whole thing so you can share the tutorials with a regular internet user (some basic tech knowledge is required) and they will be able to:

• Create a new Metamask wallet
• Add funds to their wallet
• Understand the do’s and dont’s of wallet safety
• Navigate OpenSea safely
• Understand NFT drops and Gas
• Understand NFT rarity and traits
• Buy/Trade NFTs safely
• Learn how to spot scams
• and more…

Paper Cats token

The easiest way for us to teach people about NFT drops and gas is with a live NFT. Obviously, this comes with many complications: wild price fluctuations, gas wars, potential minting errors, gas outs, and many many more.

The solution is pretty simple.

We are creating a new NFT with the following features:

• Very cheap — aiming for <$10 per token
• Infinite supply
• Trait 1: background color
• Tiered Trait 2: heart color

Anti-Whales and Pro-noob

The infinite supply means that anyone wanting a Paper Cat can buy one directly from the contract at any time.

Background Color

The background color is picked at random and is designed to teach users about randomness and how that can affect rarity.

Heart Color

The heart color is based on the roll of a 100 sided virtual dice. There are 7 heart colors available.

This allows us to teach holders about tiers and will potentially result in some tokens being priced higher than others on the secondary market.

NFT Developers

Paper Cats will also be completely open-source and has been coded with simplicity in mind. Someone following the tutorial should be able to fully understand the process and produce their own functioning NFT.

Every step of the process has been documented and every bit of the code is explained.

To ensure we are creating tutorials that are easy to follow and offer real value to new NFT developers, we thought it would be best for a developer with very little NFT knowledge to be your guide. As such we tasked Adam, one of the Cool Cats team members to work with Tom to write a series of tutorials from his perspective.

It should be noted that Adam does have coding experience and has worked on many javascript and typescript projects.

When will Paper Cats be ready?

We have a few more weeks worth of work to do. Luckily the NFT community on Twitter has been super supportive and a whole army of people have offered to help. Nevertheless, it takes time to create simple tutorials for a complex topic.

We will make announcements and drop tweets as we hit key milestones.

Where to find us

I can normally be found in the Cool Cats discord channel
https://discord.gg/WhBAAHnSz4

Or on Twitter
https://twitter.com/xtremetom

https://twitter.com/Grampa_Bacon

https://twitter.com/coolcatsnft

Last Word

I feel silly saying this, but I have had so many messages I feel it might save you and me some time.

I have a full-time job IRL and coupled with Cool Cats I am swamped with work, so sadly I have to decline every job offer.

But I am always willing to help out by sharing resources and advice where I can.