Truly on-chain NFT projects

For research am doing about on-chain art projects on different blockchains, I’m looking for 100% on-chain examples. So far I’ve only found Tezos projects that store some metadata (mostly the unique properties) of an NFT on the blockchain with a link to the rest of the code on IPFS to render the NFT.

After reading this post I’m wondering if it is even achievable on Tezos. To quote the answer there:

It follows that the storage of a contract cannot increase with more
than 60000 bytes per transaction. Note that such a transaction would
cost ~180 usd today.

Currently, on Cardano, the size limit of a transaction is 16 kB. Creating it would cost about 0.858517 ADA or currently ~1.1 USD. By comparison, the same transaction would cost roughly $48 on Tezos. So that’s probably the reason why most of the code is stored off-chain.

To come to my question, does anyone know of any projects on Tezos, generative or not, that are stored 100% on-chain, either L1 or L2?

What’s wrong with IPFS? Storing large amounts of data on chain is expensive because it costs disk space to all node operators. On the opposite, you don’t need to store all IPFS content to participate to the IPFS network.

1 Like

I’ve got something for you. At the beginning of my Tezos journey is was doing experiments with on-chain NFTs, and came up with an interesting way to fully store a (small) NFT on Tezos.

From a previous post of mine:

The idea is to use the parameter data (or calldata on ethereum) to store the actual payload/bytes of the file or art. It’s still stored on-chain, but you will need to rely on an archive node or indexer to fetch the data because it’s not actually in storage. That’s the biggest drawback, but the biggest plus is much cheaper storage data.

This link has my experiment. If you scroll down to where I’m using the “abyss” endpoint you’ll see me send some base64 strings in parameter data but I don’t actually store anything in the contract. I was able to get some ~9.5kB taco gifs in for around 0.01xtz fees each time, far cheaper than 0.25/kB.

Now, this is more of a blockchain party trick and isn’t meant for production. But I think for research purposes this kind of thing is pretty fun, and some people do want on-chain NFTs.

2 Likes

I wonder if using the new on-chain views provides a path forward here? Then we would no longer need to store entire image sources in a big_map (which takes a substantial amount of storage, as each unique image string needs to be written individually), and could instead generate the image (and the metadata) from parts stored within the contract, which are constructed into an image inside the view? This is currently how on-chain images are done on the EVM chains, where storage is much much more expensive.

Yes, that’s exactly what I’m looking for. This is great and really exciting, thanks! :slight_smile:

I’m not completely familiar with indexers, so I’ll read up on that. So those 4 gifs are roughly 40 kB in total. Is there a hard limit on the amount of data you can store that way?

Would you mind if I referenced this in a blog post I’m writing? Do you maybe have a Twitter profile I can link to?

Thanks again! This is really helpful.

It’s not that IPFS is bad or anything, but it creates a dependency. I’m researching the blockchain as a medium for art, and having all code on-chain is a step in that direction. We can do a lot within a 16kB (taking Cardano’s example), so why do we need to store the code elsewhere? That’s the question for which I’m looking for answers. So far, it seems, Cardano is the only blockchain allowing to do this without smart contracts and exorbitant fees.

As far as i understand avalanche, cardano, solana and tezos all cost ~ 1USD / 1kB storage. so i am not sure about the mismatch with the cardano numbers you’ve mentioned. Deso btw, say they can do 0.01 cent/kB.

The issue with IPFS is that there is no intrinsic incentive to keep the data and you need to use subscription based pinning.

I am actually giving a tutorial on on-chain media storage this week, and in this google sheet you can find some more numbers + all on-chain projects i am aware of for cardano, etherium, solana and tezos.

Namely for tezos you have artcontracts, fxhash, and mentioned in another thread here was PixelPlace. The last one - webzos https://wbtz.github.io is a small conceptual/learning project of mine that plays with the idea of putting complete websites (code+media) on the Tezos blockchain, so they can live as long as Tezos does. I am currently using contract byte storage limited to 32kb. If you click the example on the webzos page you can see a demo of a 25kB site (cost 22USD) with some media, animations and interactive sound and a thematic manifesto…

1 Like

Tezos Mandala is stored 100% on-chain (L1):

2 Likes

I am currently using contract byte storage limited to 32kb.

Contract storage is not limited. Operation size and storage increase are bounded though.

2 Likes

Thanks for all the info, that’s really helpful!

As far as i understand avalanche, cardano, solana and tezos all cost ~ 1USD / 1kB storage.

Don’t know about Solana, but Cardano is much less than that. I minted a 14K genesis piece for a collection, containing the source code for the project, and the fees were 0.766 ADA (±0.81 USD). Here’s the link:

The transaction size is 16K there, so that’s significantly less than Tezos’ 32K.

That really is the perfect example of such a project!

yes. i did the wrong calculation. ada price = 0.155381+0.000043946*bytes
so in today’s prices 1kB = 0.23 USD, 14kB = 0.9 USD. sweet!

1 Like

Regarding what you mention with having no incentive for running an IPFS node, has there been any thoughtful discussions within the Tezos community attempting to resolve that issue? I find the topic interesting and important to discuss.

1 Like

I’d also be interested to see a discussion around this topic. On-chain projects are an answer to the issue, but there’s only so much you can store. It’s a constraint that will define what we’ll know as blockchain-native art.

Here’s another on-chain NFT project on Tezos I found: