From the Editor: I warmly welcome and thank a special guest, Fully On Chain, run by Greyblok an expert in on-chain collections and valued member of the Mad Masks community for contributing to our growing resource area of articles. Make sure to follow them on Twitter and get the latest updates on your favourite on-chain work. It’s great to have you here! – Mad Jack
When discussing fully on-chain NFTs it is easy to think of it as a black-and-white argument. It’s either on-chain or it isn’t. But the reality is that it’s not that simple. There are a lot of factors to consider which is why it is a very nuanced subject. There are subtle distinctions that can even be subjective.
On Chain Requirements
First, let’s talk about two things that I believe to be hard requirements.
Single Chain
To be considered on-chain, a project must be on a single chain. Some arguments that say projects with assets stored on Arweave are on-chain. The problem is that this interdependency can become fragile and eventually lose that connection. To instill full confidence, projects must be confined to a single blockchain.
Reproducible from On-Chain Assets
There should be no off-chain dependencies. This goes into more of a core belief. The idea is that by using only on-chain data, an asset can be reconstructed and doesn’t need to be fully rendered and output from the blockchain. An example of this is Artblocks. Each project is required to upload the JavaScript that can reproduce the artwork using the mint transaction hash as a seed but must then be combined and executed off-chain. To reiterate, the instructions are on-chain but are composed offline.
Another example is Deafbeef, as the on-chain code must be run on an off-chain C compiler, which outputs the audio and video frames. The NFT you see on OpenSea is the result of compiling those assets off-chain. You can even go down this rabbit hole and make an argument that JavaScript or C themselves are an off-chain dependency. Where is that line drawn? What happens if current-day javascript-based projects can no longer run with the current version of JavaScript in, say, 50 or 100 years?
Fully on-chain projects, like The Kiss Precise, are fully constructed on-chain and the final SVG output is provided from the blockchain. This is where the term “In-chain” comes from, which means that the low-level asset, like an SVG or BMP, are provided directly from the blockchain.
Is on-chain tokenUri required?
TokenUri is a function on NFT contracts that provides the artwork and metadata about a token. Projects and marketplaces have come to an agreement that tokenUri is how this data should be provided. So what happens if tokenUri points to off-chain data? The initial reaction says this invalidates its on-chainness. If another function in the contract provides on-chain artwork, should that make it a valid on-chain NFT?
After a long thought about this subject, I think there is a strong argument to consider this project still on-chain. tokenUri is a standard but not a requirement. There are also some advantages to taking this off-chain approach, such as quick response to serving artwork if it is an expensive call to make. Also, for projects serving SVG artwork, this is a handy way to provide jpegs that render smoother and are supported on all marketplaces. Indelible Labs has a clever solution by allowing owners to choose to serve off-chain or on-chain to help with these problems.
Multiple Contracts
A common practice is to let one contract handle the tokens while another handles the rendering of the artwork and metadata. This would be considered valid and rightfully on-chain. What if one rendering contract is not referenced at all in the original contract? This is how Cryptopunks currently are constructed. While this is an on-chain solution, we can make an argument that they are “on-chain” but not “fully on-chain”. We should be able to successfully render on-chain artwork from the token we want to get the artwork for, and this isn’t the case.
Most fully on-chain projects are constructed with multiple contracts but are linked together via a “Renderer” contract. This contract can do the imagery output. Doing so this way allows the owner to potentially “fix” rendering mistakes by creating a new renderer and updating that on-chain connection.
Where It’s Rendered
Some contracts define all the parameters in the contract and render out a final output, while some output html/js to let the browser do the outputting. Where this rendering happens is important. Rendering in-chain is one thing, and providing assets to do the rendering is another. These are nuanced differences that some argue is the differentiator. Does it matter where that rendering computation happens? While this is an on-chain approach, it is not fully on-chain as the contract could not generate the thumbnail or image that the code outputs.
Trustless and Immutable
While trustlessness and immutability are not a requirement of on-chain NFTs they are a valuable and beneficial part of on-chain assets. Being trustless and immutable allows collectors to truly own their NFTs and not have the potential of the contract owner changing the underlying asset out from under them.
Conclusion
On-chain NFTs can be hard to classify. Some projects are definitively on-chain and very evident but some can be more difficult to classify as there could be arguments on both sides. As described, it is evident that there is no silver bullet for describing what exactly fully on-chain means. Many variables need to be considered. This is still an ongoing debate for many projects but over time we can start to get clearer definitions. What does on-chain mean to you?
