BLONKS

An experiment

I started working on BLONKS because I was driven to make owner-responsive NFTs, and I had a lot to learn. I had a little experience with SVGs, and also some experience with smart contracts, but I didn’t know what I didn’t know, so I decided to find out. I thought there were two challenges ahead of me, but actualy, there were like 5.

SVGs

I’ve used illustrator a bunch and I knew they could export SVGs, so I drew some shapes into a very BLONKY head, gave it a bunch of bling, and saved it as blonkhead.svg. Then I opened the svg in a text editor to see how all the thigns worked. Then I looked up the tags and found svg documentation online. I built a generative JavaScript program that would ‘randomly’ assemble the svg strings, and tweaked the outputs and occurence chances until I thought they were (pinched fingers) just right. I made them family friendly, and I decided that making them CC0 would be a great fit. Ok, half done (I thought).

Smart Contract

I knew that I wanted the smart contract to allow dynamic outputs, so the art would change as it moved across accounts, so instead of using 1 piece of data for entropy, I knew I needed 2: one from the mint, one from the owner. While researching how to do this, I learned I could incorporate a third: the block gas at mint amount. I only needed a tiny amount of entropy from the block gas, so I tacked it onto the mint entropy and then only needed to pass two entropy values to the resutling token.

I built out all the functions of the contract except for the art generating function, used a simple placeholder for it instead, and ran some deployment tests. Once I fixed my errors and cleaned up the code, I thought I was in great shape and mostly done… I mean, how hard could it be to convert my js script to solidity?

It’s Hard to Convert JS to Solidity*

*Unless you write the JS in what I call ‘psuedo-solidity’, which is inefficient JS but more easily converted to Solidity - and which I didn’t know anything about when I started this.

When I FINALLY got it all into solidity, it was a massive contract and WAY too big to deploy on main net due to contract size limitations.

Who knew there were size limitations and why wasn’t I informed!?!?

In researching solutions, I learned about multi-contracts and libraries. I decided to break the main art-generating contract into three parts:

1. Traits based on the token entropy are handled in one contract, which returns both an array of values and a string of those values in JSON to pass on to the main contract.
2. Locations (or coordinates) needed to create he SVG shapes, all calculated from the traits array.
3. SVG assembler takes the traits and locations, and entropy values to finally put all the pieces together.

After testing and finding errors, I tried putting it all together in the main contract annnnnnddddd it was still too big. The coordination of all these subcontracts was too much, so I had to make a new contract to do that.

URI Contract

I moved all token URI related functions into a new contract, called it from the main token contract, and then this URI contract would assemble the art, return traits, etc. Main contract handled all ‘crypto’ stuff, then calls URI contract for all ‘art’ stuff (which calls the other 3 contracts to make the art and traits).

I realized that I could make all these contracts upgradable, which, as an experimenter, suited me quite well. I wasn’t exactly sure how I’d change the URI contract in the future, but I had the inkling that I would…somehow. I decided then that I’d create the project with ‘No Roadmap’ announced loud and clear. I knew there was a road ahead for the project, but that the path wasn’t clear yet to me. “I’ll figure it out later.” -Matto

I had 4 contracts to deploy and set up, manually (I didn’t know hardhat yet), and so bug testing was a massive chore that took forever. When the contracts finally compiled and was whithin size limitations - AND WORKED - I was elated and relieved. BLONKS, the system, was born.