Radioactive Punks: Pushing the Future of On-Chain NFT Metadata and Rendering
Preserving a Sludgy Future On-Chain
Ethereum collectibles hold serious value, but long-term provenance and storage have been a major concern for collectors and creators alike since day dot.
The solve? Well, I am a firm believer that migrating as much data on-chain as possible is a crucial step for ensuring uninterrupted access to all of our digital assets well into the future.
As part of my on_chain_summer.exe program, I will be writing here when I release experimental on chain artworks. Consider this program 0.
I tackled this challenge recently with the Radioactive Punks series featuring artwork by Pixantle and came out the other end successful so I figure I’d braindump some of the process.
Without further stalling, here’s the code:
You can lookup your punk on our website by logging within your wallet.
How’s it work?
The system consists of five smart contracts working in tandem.
Each smart contract uses a combination of approaches pioneered by Dhof, xtremetom, and wattsyart where data is stored in a pre-compressed state and then inflated on the fly when viewed in-browser. You then create a separate contract which puts all that data together into an HTML document that will display you artwork.
I was able to store full-detail SVG image information without relying on any external resources besides the EVM — an essential milestone for long-term NFT preservation.
By mixing that approach with some techniques I picked up via Mathcastles, concatenating a JSON Data URI was reasonably straight forward.
The next problem I had to solve was how to store trait data for 1614 punks, each containing fifteen traits that have up to nineteen different values.
The answer was actually pretty straight forward: bytes
Since each byte is two hexadecimal values (ex: 1a) we can store 32 unique values inside each byte. Hell yeah. That means we can easily store each trait’s value as a byte and each punk as a group of 15 bytes in-a-row.
Thus I deployed a massive contract containing 1614 * 15 * 2 hexadecimal values.
To save gas I was able to use bytes public constant data and then write my own function to index into the structure instead of using bytes16[1614] , which wastes gas for the convenience methods and padding every trait to be a bytes16 with 00 at the end.
Ex:
010100000400000003000200000000encoded bytes15 of RPUNK #0
Notably, this made deployment costs low. A little less than0.5 ETH — significantly less than other on-chain data storage projects, such as CrypToadzChained which did an incredible job at compressing data and still came out to over 15 ETHat similar gas fee prices (although they had to deal with GIF 1/1s and I only had to deal with SVG 1/1s, CryptoDickButts came in around 1 ETH).
Why do this?
This was always part of the plan my dudes!
From day one, Arweave was meant to be used until I could acquire the knowledge and funds to put the data completely on chain.
I was finally able to set the METADATA_PROVENANCE_HASH feature of the original NFT contract, ensuring the secure and sustainable storage and access to Radioactive Punks data.
Secondarily, I like to think this pushes the boundaries of on-chain rendering. Using a combination of compressed and uncompressed on-chain SVG data, HTML data, and JavaScript to render fully responsive 4k downloadable NFTs without external resources is pretty nifty.
Hopefully the open-source nature of my code and modular contract system can serve as a reference implementation for other projects and inspires them to experiment with their own on-chain rendering projects.
Easter Eggs
One thing is that the bytes data is totally public and reusable by any project for use as PRNG/seed data for your minting process.
Another small thing is that I’ve included a built-in right-click-save-as function to download your punk in 4K resolution.
Final Thoughts
The future of NFT longevity lies in on-chain data storage, and I like to think my technical work with Radioactive Punks stands as a testament to that belief.
This process has demonstrated to me that migrating all PFP data on-chain is a difficult but critical component of long-term provenance and storage, but it gets more accessible every day.
🤘🏼 💀
Shoutouts and Resources
This would not have been possible if I was not standing upon the shoulders of these giants:
