For the sake of this entry, I am referring to on-chain as any NFT that is fully on a single blockchain, including its data, meaning it doesn’t rely on any external references such as IPFS or CDNs.
When it comes to the on-chain art form there are benefits and sacrifices. The biggest benefit is permanence. It makes the NFT a true digital artifact with permissionless ownership. It removes the risk of off-chain assets disappearing and the NFT becoming an empty shell. In the case of Ethereum this permanence is backed by hundreds of billions of dollars, or more than a trillion on Bitcoin. I can’t imagine a better medium for digital art, and I don’t think any of us fully appreciates the new paradigm it’s forming.
Some of the biggest sacrifices manifest as a degraded user experience (UX) and artistic restrictions. The degraded UX mostly stems from media formats. Most on-chain artwork is generated as SVGs. This format differs from rasterized ones like JPEG or PNG. Some of the problems with directly serving SVGs are: browsers don’t natively support right-click-save, social platforms (like X) don’t support them, and dapps/metaverses vary – often resulting in blurry or glitched rendering. In short; SVGs aren’t as interoperable as other visual web formats.
On-chain also restricts the artist. Every medium has its limits. On-chain takes digital art and imposes severe limitations. There is size, storing on a blockchain is expensive! There is computational power, you can’t just run resource hungry Javascript on an EVM. There are protocol limits. An argument could be made that this friction can be beneficial, but I personally have sacrificed a lot of what I want to do on the on-chain alter.
Lessons learned with Treeangles
The on-chain approach I took with the Treeangles collection was generating SVGs. I was proud of my innovations in fitting all 300 on mainnet Ethereum. However, I spent weeks troubleshooting rendering issues on different browsers and devices. Then after the drop I was disappointed to see collectors struggle with sharing or using their pieces. Because of the nature of on-chain I had to provide the SVGs as the default, and offer the UX friendly rasterized afterwards. If I didn’t choose on-chain I would have gone the standard route of providing the PNGs as the default, and the SVGs as a bonus.
Approaching Hexag⬡ns
With the Hexag⬡ns collection I went all-in on interactivity. My vision was a living collection that continually provides new interpretations and functional assets directly through the NFT. Doing this fully on-chain would have been impractical. I had a tough choice to make; My passion for on-chain, or my vision for Hexag⬡ns? Then I had a realization: Why not both?
Enhanced On-Chain
I wanted the on-chain vibes with off-chain power. What I decided on for Hexag⬡ns is “enhanced on-chain”. The collection itself is fully on-chain, all the metadata, SVG generation, even the collection metadata. However, it returns an enhanced version that points to off-chain resources for the fully interactive NFT. Every 4 weeks I have to ping the smart contract to let it know I still want it serving the enhanced NFT. If I miss a ping, then the contract automatically removes the off-chain pointers and moves to serving everything itself. The art and all its data would remain the same, the interactive NFT part would just be removed. It’s a graceful degradation.
This approach keeps the spirit of on-chain permanence, and allows me to deliver more to collectors with a better experience. Even if I disappear, holders will keep their Hexag⬡ns. Best of all, this is all provable on-chain.
Technical Implementation Details:
All contracts are open source under an MIT license.
-
Hexag⬡ns NFT contractThe main contract for the NFTs. It also has functions to convert ERC-721 IDs to Hexag⬡n Keys
-
Rendering contractCalled by the main NFT contract, has all the logic to generate SVGs, assemble metadata, and return token URIs
-
Traits contractSimple storage for all the Hexag⬡ns traits. Used by the rendering contract. Kept modular for future API usage.
-
Paths contractStorage for all the SVG paths (the visual cells that compose a Hexag⬡n). Used by the rendering contract. Kept modular for future API usage.