In the realm of blockchain development, iterative is occupying an intersectional space between mutability and immutability. These concepts are not unique to web3; they are actually deeply rooted in 90s era open-source cultures. This project is in many ways a nod to the past and a bridge to the future, embodying the spirit of continuous improvement and adaptability.

At its core, Iterative aims to be a reference project, demonstrating how complex blockchain applications can be constructed with an emphasis on creative coding, and intentional community building. We want access for all.

In this 4th and relatively short development-focused article, I am going to hash out the hows and whys of Moon’s work on solidity side of our project, based on his breakdown of how he’s approached the contracts, and why it’s significant. Him and I share a decades old ethos of ethical hacking, as well as a deep rooter love for open source and free software, and our processes tend to be an extension of our backgrounds in that world.

Part 4 - Solidity

Approach

To start, Moon emphasizes that the project pieces are built with a TypeScript-first approach, to leverage its checks to ensure code quality, as well as reducing potential bugs. Autogenerated code is employed in some instances to minimize manual processing, which contributes to streamlining the development process.

The Solidity contracts themselves - the literal backbone of the project - are built on the robust foundation of OpenZeppelin. This choice not only ensures checked and battle-tested standards compliance, but also makes it possible to explore future enhancements. I’d like to re-iterate here that Iterative very much about mutability, on a few different levels.

Mutability is a crazy concept with blockchain projects. Granted it’s me that’s ultimately deciding which traits are mutable, and which are not, there is a lot of common sense along the way contributing to the decision making. Moon is not one to say no to things, which can leave my ambitions unchecked. But we have a pretty good synergy where limitations are observed, and more often than not, his feedback motivates me to slow my roll and pull back on some features.

Related to this, there is the question of what our intentions are beyond the NFTs themselves, dynamic/upgradeable as they may be. To quote Moon, everything is documented to try to make it as easy to pick up as possible for others. Yes that’s right, we are encouraging you to take this thing and turn it into another thing!

As open source wingnuts, documentation truly is a priority for us, making the project accessible and understandable for developers who wish to learn or contribute, or more importantly, use our code to flesh out their own experimental blockchain projects. I remember so many instances where I have been lost in the dark without documentation on cool projects. Conversely, I remember moments of pure joy (and often, relief) from when I have discovered that a developer somewhere gave a shit and dropped incredibly helpful docs related to their project.

DNA

A distinctive feature of Iterative is the storage of traits that Moon has devised. We are using packed values in a 256-bit uint bitfield. The number of bits allocated are kept small so we can pack as much future expansion into the uint as we can.

Wait, what the fuck does that even mean? For those that are new to this kind of thing, a 256-bit uint bitfield is a data structure that uses 256 bits (equivalent to 32 bytes) to represent a sequence of 256 booleans. Each bit corresponds to a specific flag/value, where in it can be either 0 (false) or 1 (true), or another packed number value. What this allows us to do, is efficiently store and manipulate a larger set of options without deviating from a compact format.

Simpler terms for those that I lost a couple sentences ago: we have a tree of simplified values that we can refer to , that will allow us to control, or query multiple (yes-this-exists) or (no-this-is-not-a-thing)s at once. And the unspoken implication here is that real estate is limited; we need things to be as tiny as possible so we can fit them on-chain.

This approach is a hat tip to efficiency, as well as an intentional tool to allow us future expansions for each token. In fact, the very first field is a version attribute, so that future revisions of the contract can allow for new NFTs with completely different variables. To achieve this, Moon is generating the Solidity code for processing these fields from a template that will make later expansions easier.

Fully On-Chain

The project pushes the boundaries of on-chain capabilities by storing the p5.js scripts directly on the blockchain. Furthermore, the HTML/JavaScript is assembled and constructed dynamically inside of the contract, so literally everything is entirely on-chain. While we are not the first to do this, we are proud to be part of a very niche group of folks who have dedication, and faith in the capabilities and longevity of the EVM.

We would like to note that while we are hitting some API endpoints in some places - which means we are touching off-chain data sources - the NFTs will still function even without them. The endpoints essentially serve to add more cosmetic improvements to the NFTs. We have discussed that it would be possible to move these endpoints onto an Oracle chain, so it is possible that we explore this down the road.

Do What Thou Wilt

The concept of upgradeability is central to Iterative, reflecting the project's commitment to the principles of mutability and immutability. By making the NFTs upgradeable, the project empowers holders to modify and evolve their trippy loops over time. This feature is a nod to the open-source hacker mentality, where the ability to adapt and improve is highly valued, and even coveted. As front-end tooling is developed, holders will have even greater control over their digital assets, further blurring the lines between the creators and the collector.

Big takeaway here: we are reducing our chances of coding ourselves into a corner, while simultaneously breaking the standard expectations of the NFT world when it comes to immutability, scarcity, and rarity. There may be more NFTs. Existing NFTs may have their traits changed by the owners. Some of the iterations may turn into things that don’t even resemble their past selves.

Hell, if you spent money on a thing, and it’s yours now, why wouldn’t you be able to to do whatever you want with it? (Just give us credit for the original state please, hence our usage of the MIT license for this project XD).

It’s yours, do what you will with it.

Iterative is more than just a blockchain project; it's a reflection of the evolving digital landscape, where the past and the future converge. By embracing the concepts of mutability and immutability, the project pays homage to the hacker culture of the 90s while paving the way for the next generation of Web3 innovations.

In future articles we will discuss where we are headed with interoperability, collaborative development with other projects, and the actual lore and world building we have envisioned around the project. These are some lifetime goals we are finally realizing, and are hoping more folks will join our explorations along the way. Let’s start a movement!

Mint is live!

You can mint your own iterations here:

Once you’ve got your iterations, you can navigate to /info/run and check them out there. You can also enter minted token IDs at /info/index to check iterations individually. Fullscreen for max effect (scales with window).

Apps to export gifs of your iterations, view them in different contexts, and more will be added over the upcoming weeks and months, along with the tools to allow you to modify your iterations and write the changes back to the chain. In the meantime, have fun exploring this weird pocket of nostalgia we’ve created, and please do connect with us on Discord.