The Parent/Child structure enables disparate collection owners to be organized under a shared “umbrella” collection. This is particularly beneficial for collaborative projects, where multiple creators contribute to a single vision, such as a large-scale digital gallery or a themed game environment. In this case, the parent collection represents the shared project, while child collections represent the individual contributors. This flexibility fosters collaboration across creators and simplifies discovery for users.

·       Unified organization of diverse game assets across multiple collections

·       Hierarchical structuring of asset collections (e.g., weapons, armor, characters)

·       Maintainable relationships between different asset types while preserving collection autonomy

·       Simplified asset management across different game modules or expansions

Game developers often need to manage a variety of assets, such as characters, items, and virtual worlds, which may be created by different artists or studios but belong to the same game environment. The Parent/Child relationship allows game assets to be organized under a unified structure, giving players and developers a more coherent and manageable way to navigate these assets. This model also provides flexibility for game studios to segment collections for expansions, updates, or collaborations while keeping them organized under the game’s larger umbrella.

·       Flexible organization of collections under broader umbrella structures

·       Multiple artists can maintain independent collections while associated with larger studios

·       Support for collaborative projects where collections need multiple parent associations

·       Preservation of individual artist autonomy while enabling broader organizational structures

For artists and creators, this model allows the creation of multiple sub-collections within a larger, cohesive body of work. A parent collection could represent an artist's main body of work, while child collections could represent different thematic series or collaborations. Additionally, studios or creative collectives can group the collections of various artists under a parent collection, facilitating collaboration and co-branding without losing individual collection identity.

·       Implemented as two contract-level tezos-storage items: parents & children

·       Maintains a library of Tezos addresses

·       Compatible with existing Tezos standards without impacting existing collections

·       Does not require editing of IPFS stored metadata

·       Does not affect individual tokens

This Parent/Child structure has been implemented as lightweight elements within Tezos storage, using two simple contract-level constructs: parents and children. Each collection is represented as a library of Tezos addresses, allowing it to store relationships with other collections without altering its own metadata or compliance structures.  By integrating this structure into Tezos storage rather than as metadata, the organization model remains compliant with existing Tezos standards and is lightweight. This structure can already be implemented as a custom storage item without affecting the core contract functionality or compliance, making it adaptable.

·       Multi-directional relationships (multiple parents/children allowed)

·       Lightweight implementation that can pseudo-integrate with existing contracts

·       Storing familial relationships is only available to new collections

·       Existing collections can still be set as a Parent and/or Child to a new collection

·       Add/remove family members using familiar operator-style interactions

·       Modifications possible at any time, even for metadata locked on-chain collections

Unlike traditional hierarchical models, this approach allows collections to have multiple parents and multiple children. This flexibility lets collections function as part of several broader structures without duplication, supporting cross-collection collaborations and layered organizational needs. Adding or removing parents and children is as straightforward as adding or removing operators. Collection managers can adjust these relationships at any time, even for fully on-chain collections with locked metadata or artwork. This flexibility empowers creators and developers to adapt their collection organization as projects evolve or collaborations emerge.

·       Relationships queryable through standard blockchain API calls

·       Easy integration with marketplace scrapers and indexers

·       Transparent and accessible organizational structure

·       Low overhead for data retrieval and relationship verification

This Parent/Child structure is also designed to be highly accessible. By keeping the organization within Tezos storage, the data can be easily retrieved via blockchain API calls or data scraping. This enables third-party marketplaces or portfolio platforms to efficiently gather collection relationship data, index collection relationships, and present a unified view to end-users without complex integrations.

·       Storage-level implementation maintains simplicity

·       Metadata independence ensures relationship flexibility

·       Seamless integration with existing marketplace infrastructure

·       No changes required for existing contracts

·       Minimal gas costs for relationship management

·       Compatible with fully on-chain collections

·       Scalable for large collection networks

·       Supports dynamic reorganization without impacting collection integrity

In conclusion, the Parent/Child storage model offers a practical and compliant solution to support the organizational needs of creators, studios, and developers within the Tezos ecosystem. Its lightweight, flexible structure not only simplifies collection management but also enhances discoverability and collaboration across diverse projects. This implementation provides a robust yet simple solution for organizing NFT collections while maintaining the flexibility and autonomy needed by various stakeholders in the ecosystem. The storage-level implementation ensures broad compatibility while enabling powerful organizational capabilities.

A Collaborative Descent into On-Chain Art

The full scope of motivation, intentions and execution of my De Stijl Demons is too broad to fully share here, but some concepts are important to know in regard to on-chain minting. The collection began with a simple question posed by another artist – What would a De Stijl demon look like? I decided to find out and built a robust process that is both deeply personal and highly collaborative.

From the beginning the concept was to leverage modern tools and see what an artist can accomplish with little to no budget. I sketched out some ideas on the artwork aesthetic and formulated a way to engage latent model generation.  It did not take long to find the right recipe to get the desired look, and through the assistance of this technology was able to generate 6666 unique artwork that fit the overarching collection concept. Engaging my fellow collectors, artists I appreciate, and even trader communities a solid start of a collector base was gathered. I moved onto using an LLM (ChatGPT) to build a unique selection process to view and curate the artwork. To earn a mint spot, each collector is required to Like/Dislike the artwork so that we collaboratively refine the collection down to 666 pieces.

Continuing with the collaboration concept, collectors play a vital role by picking the artwork they want, deciding on which blockchain (any blockchain) they want it minted, and developing the name, number and attributes. To me the specific blockchain is not important so much as the comfort of the collector in the artwork they want. In the end each artwork is a personalized Demon curated by the community and co-created by both the artist and collector. Much of the data and process will eventually be enshrined on-chain. With this in mind, it was important that the artwork itself also be fully on-chain to be immortalized and immutable. After finalizing the artwork with each collector, it is converted from raster (PNG) into vector (SVG) for 100% fidelity. The artwork not only will be saved direct to the blockchain, omitting potential issues with third-party storage, but the NFT can forever be used for display or printing purposes at any size never needing to be edited or remastered.

2024 : A Blockchain Odyssey

When developing the collection, I completely pushed off the minting process. People have been minting artwork for so long, even on-chain, that I assumed this would be the simplest element of execution. I chose an initial artwork to mint and keep for myself. As De Stijl Demon #1 named New Plastic Pepe, it made sense that the inaugural artwork would be minted on Bitcoin.

The process was really quite simple. Ordinals are still developing and do not have the full gamut of traits and functions that other blockchains provide, but everything as an Ordinal is by default minted on-chain. (Ordinals are technically inscribed, but I’ll continue using “mint” for consistency.) I could not really mess that part up. Different platforms offer different levels of service, but all of them mint on-chain. I ended up choosing Luminex which incorporates Parent-Child relationships, on-chain attributes, and minting on specific sats, choosing Block 666 for obvious reasons.  I cleaned up my SVG file to fit Ordinal parameters, triple-checked that the attributes were formulated properly, and made sure I had a sat available. Click-click done! While I sweated because once it is sent there is no way to undo the mint, the process was smooth and easy. Simply decide how much to spend and send it off. The mint transaction just stayed in place in the mempool until all the pricier transactions executed, and then I was rewarded with my on-chain Pepe. All-in, including purchasing Block 666 sats, the cost was around $80 which was less than anticipated.

Bitcoin, the OG blockchain, even though it was never intended for artwork, was making me feel good. Simple process. No major hurdles. Just had to educate myself and jump in.

The Dance in a Virtual Machine

After the successful start on Bitcoin, it was time to start expanding. My first collector was interested in using the Base blockchain. Having heard nothing but positivity about the ease and usefulness of Manifold, I had already used it myself. It was the obvious choice since it supports Base. As a Layer 2, Base is known for low transaction fees and Manifold has worked with many big-name artists to execute unique collections and interactions. Slam dunk.

Much to my surprise, Manifold really had no built-in mechanism for on-chain minting. The platform was designed solely around uploading images that get stored to Arweave. At first, I just assumed I was missing a step, but through some investigation realized while it streamlines the minting process in general, Manifold lacked the functionality to directly embed the SVG data on the blockchain. I was forced to build the collection in Manifold but then use a less ideal process of minting direct from their contract on Etherscan. While disappointing, I was familiar with that type of execution, so I wasn’t too worried. Just a little road bump. Even though it was a clunky interface, I successfully sent the mint.  However, the unexpectedly poor experience just kept going. I did not find out until after minting that any artwork minted via contract instead of their interface will not show up in my dashboard. I could not see or organize my mints effectively making Manifold 100% pointless. And to top it off, the mint price was over $10 which was shocking considering the low fees on Base.

Sufficiently frustrated, and knowing I had collectors interested in both Ethereum and Polygon, I decided to take matters into my own hands. I never considered writing my own NFT smart contract and didn't think it would ever be necessary. Back to the LLM for help. Leveraging the technology, much like the whole project began, a working smart contract was constructed in under a week. The advantages were immediate and recognizable. After plenty of testnet debugging, I deployed my own contract and not only reminted Amaranth on Base, but also deployed a contract and minted Ned Kelly Demon on Polygon. On account that the custom contract is so simple, it can be redeployed the exact same on multiple EVM blockchains. I did not have to change a single part.

I was back to having full control of the minting process and really high level of flexibility. No limitations on the SVG or attributes and the only constraint is the data size in relationship to EVM gas costs. The simple smart contract helps with those costs as well. While the Manifold Base mint cost 0.003ETH at 6 gwei, reminting only cost 0.0006 at 7 gwei. Approximately 80% cheaper at only $1.75 using my own contract. The Polygon mint was even more economical. Minted during a moment of high gas prices (56 gwei), I still only spent $0.04 for fully on-chain artwork. Truly amazing.

Even with this success I still had some hesitancy minting to Ethereum because of the potential fees. My first Demon on Ethereum was minted for one of my sons. I was prepared to pay quite a bit to get him a special on-chain piece of art. The initial tests came back at around $350 in gas. Not going to work. I set off a new process of making the SVG more efficient and compact. The only chance at minting Ethereum on-chain was to reduce file size as much as possible. It took some time, but with the simple contract, a compact SVG, and some days with low gas, Tukultu, and several others, were minted for between $25 and $40. Success continues.

Showdown with the Artist’s Blockchain

Now things were cooking. Successfully minted Demons on-chain with the clunky Bitcoin blockchain and the sterile Ethereum blockchain. My first Tezos collector had made their choice, and it was time to enjoy the simple process minting on the artist's blockchain. Back to the LLM for a custom smart contract in SmartPy. I had never even heard of this programming language before, but it has an online complier and lots of templates, so figured this would be even quicker than generating my EVM contract.

I don't think I've ever hit a brick wall so hard before.

There appears to be minor idiosyncrasies in the coding that change a smart contract from being recognized as “FA2 Ledger” (an NFT) or just “Ledger” (not an NFT). Both compile and mint tokens, but only the former shows up in the Objkt marketplace so we can view the artwork. Even when utilizing the SmartPy templates, compiled contracts would fail or simply not get recognized as an NFT. Starting over from scratch several times, it took months working with the help of three LLM’s, as well as putting in a lot of manual reading and coding, to get a working contract. I have successfully generated something that truly works.  It compiles correctly.  It is recognized as FA2. It mints tokens with on-chain data. It shows up on the marketplace. Yet that brick wall still stands.

Much to my surprise (again), the artifactUri attribute used to display the image on Objkt is limited to only a 250-character length. My Demon SVG, even when highly efficient and compressed, are thousands of characters long. The underlying concept for this restriction is that it only wants to see a link to find the artwork at some off-chain storage. The entire environment, for whatever reason, was never designed to support on-chain art. In fact, this design actively discourages minting artwork on-chain. Some artists have successfully minted Tezos art on-chain. They all include artwork that can fit within the 250-character limit. This typically means tiny PNG files – like 8bidou with its 8x8 pixel artwork. I tested a super simple SVG that worked, but that's not useful.

I’ve tried clever ideas around this restriction, but so far have had no success. However, I haven’t given up. I’ve been in contact with Objkt team members, trying to see how this can be resolved or modified. I am encouraged by the fact that the entire SVG string does in fact mint.

Any person can view the token data, copy the string, and use it to view the art. It displays perfectly. I know that my art truly is minting fully on-chain. Somebody can mint, buy, sell, or transfer the token. We just don’t have a way to see it when interacting within the marketplace. There are sloppy workarounds I might have to employ, but I really do not want to go that route unless absolutely necessary.

Are We too Early?

I’m still taken aback how difficult it has been to mint on-chain with Tezos. Always a big proponent of that blockchain, this experience has changed my perspective. There are many more blockchains out there that I will engage with for on-chain minting of my Demons. So far, with the ones I have used, the results have been different than expected. There has been a lot of learning but being that we are in 2024 there are too many shortcomings that are easy to address but have simply been glossed over.

• Bitcoin Ordinals provides a refreshingly straightforward minting process, leveraging the inherent simplicity of the inscription protocol, though it lacks more advanced features on most platforms.

• Ethereum provides complete control and flexibility with a smart contract that can be repurposed for potentially every EVM-compatible blockchain. Unfortunately, user-friendly platforms are still focused solely on off-chain storage and ignore the benefits, and often ease of on-chain mints.

• Tezos, despite its artist-centric rhetoric, presented technical challenges designing smart contracts and maintain seemingly irrational marketplace limitations that appear against on-chain art.

Giving artists options and making it easy to accomplish should be a priority. Options are simple and cost nothing. While there are numerous platforms out there for artists to use, across blockchains, they are nearly exclusively designed to focus on off-line storage and simply ignore on-chain data. For an industry built on the concepts of fidelity, immutability, and longevity none of it makes any sense. The technical aspects are not even difficult to overcome. Blockchains can inherently support on-chain art. It is the platforms and the marketplaces that get in the way. Working with my De Stijl Demons I’ve seen a small microcosm of the challenges on-chain artists face.  On the flipside, these challenges are really giant opportunities for platforms and marketplaces to consider before they fully mature. As they grow, and new ones appear, I hope we can expect to see new pathways where artists have a wider range of tools, empowering them to create truly immutable works of art that reside permanently on the blockchain instead of just riding down the same old road again and again and again.

One day, right?

We are so early.