The problem Onchain-Experiments_V1 solves

Most traditional generative art platforms and art NFT's that exist today are cool, but in my opinion have one major problem. The actual metadata and images that define the entire asset are not stored on chain. A lot of times the tokenURI returned from the smart contract is just an ipfs or arweave hash (best case) and sometimes even a url to a server in the cloud somewhere ran by the team behind the project (worst case). The latter is obviously a major problem if you value permanence and decentralization. In the worst of cases, the team could technically change the metadata and art, shutdown the server, or stop paying whoever is hosting the server. Thats not all, assuming the tokenURI works and you're able to get the metadata, a lot of times the image itself is also stored on ipfs/arweave/server! That is two opportunities for something to break. As I write this, the top 10 art projects on base ranked by opensea are stored like this:

• Arweave: 3
• IPFS: 5
• centralized server: 2

For generative art in particular, the two previous problems still apply but theres another factor, the code that generates the art/image. This introduces yet another dependency that could potentially break one day. The code needs to be stored and ran somewhere offchain. Some art platforms will tell you that "the code is stored onchain". That usually means the javascript code is stored as a string in the smart contract. This is a step in the right direction, but for me, this just feels clunky and is not going to cut it. I wanted to build my own version of what I believe a platform could look like that doesn't have any of these 'problems'.

Introducing Onchain-Experiments_V1

O-E_V1 is a platform for artists to share and mint their work. It is permissioned, but open to anyone! At a high level, it is a single ERC721 smart contract on Base. Each edition that is deployed has its own ArtGenerator contract that the artist creates that is in charge of generating the images and attributes.

Challenges I ran into

Luckily, I didn't run into any serious bugs (that I know of). Although I do struggle with certain things when I build projects. I'll describe some below, and how I tried to overcome them.

One example of this is knowing when to stop adding features and making things more complicated than they need to be. There are so many different ways to build something like this. To narrow it down, I often try to conscientiously make my projects and code that I write as simple and minimal as I can, without compromising on security and function. In this case, I deliberately chose to leave the main ERC721 contract very streamlined and opinionated and the code hopefully very readable. The art generator contracts are then left up to the artist to make as complex or simple as they want.

Frontends are also always a challenge for me. They often take me longer than the smart contracts. This time, similar to the contracts, I tried to keep it as simple (yet functional) as I could. I opted to use a classless CSS package, which along with semantic html, give a nice over all clean look. Then, I used minimal inline styles where I needed to. I also used Next.js which helps a lot with organization, and it let's me build the frame portion in the same project. In a future rewrite or in the V2, I think I might try running an indexer. This would help keep the frontend up to date and reduce the need for and solve issues with 3rd party NFT APIs.

In general, building something completely solo has its challenges as well. Making every single design decision is tough sometimes, and I occasionally experience 'analysis paralysis'. I feel that having people to brainstorm with and bounce ideas off of would result in a better finished product.

Luckily, this is V1. I've already learned a ton by building this, and I expect to learn a lot more as I see it exist in the wild. I hope to receive feedback from collectors and artists, meet like minded builders, then take what I've learn and start building V2.