ArtContracts: On-Chain Art via Tezos Smart Contracts

ArtContracts is a project facilitating storage of art directly on the Tezos blockchain.

A prototype was built (OBJKT#112092) which displays on-chain static image data within an “HTML NFT” frame on HicEtNunc.

Any arbitrary data can be stored on-chain, specifically in hexadecimal form (as a bytestring). The type of art stored is limited only by the ability for that data to be translated back and forth between its original form and the hexadecimal form.

In the future, it’s likely that this project will support not only static images but also animations, videos, text, audio, and even generative & interactive artworks.

Beyond simply supporting a variety of media types, the primary goal of this project is to explore the applications of on-chain art technology, and to build utilities that other developers and artists can implement into their own projects. This includes compression tools to lower the storage costs for deployment.

Some exciting possible utilities include collaborative art (multiple people editing on-chain data) and art that evolves over time without human intervention (changes in on-chain data facilitated purely by smart contract interactions). There are also many applications in the world of “collectibles”, due to the permanence lent by blockchain storage.


This decentralized application seeks to create tools, standards, and interfaces enabling users to:
0. (Optionally) compress artwork in order to save on storage costs

  1. Encode artwork in a format which can be readily stored on-chain
  2. Deploy that data to the Tezos blockchain, stored within one or more smart contracts
  3. View these artworks with “interpreter” software, which queries the relevant on-chain data and decodes it into the original artwork form
  4. (Optionally) monetize their on-chain data through token creation, whether on an established NFT platform like HicEtNunc or through custom minter and marketplace contracts.

Much of this post (and surrounding documentation) uses words like “art” and “artwork”. Notably, this same approach could also be used for storage of data unrelated to artwork. One survey respondent suggested the option of a “blockchain notarization tool”. I am certainly interested in exploring these non-artistic applications as well.

So far, I am writing all contracts in SmartPy. The interpreter code (which can be seen as the NFT prototype on HicEtNunc) is written in JavaScript and can be embedded into HEN’s “HTML NFT” template.
Currently, the steps of compressing data and encoding it in hexadecimal form are done with Python. The speed of execution for these steps could be greatly improved using a compiled language like C++.

The first prototype on-chain artwork was originally deployed on 3 June 2021, but has since received an update. This update modified the pixel data of parts of the image in order to add text asking the viewer to vote in my platform survey.
This “upgradable” aspect of on-chain storage has many interesting implications in the world of interactive art, and is one of the project attributes which I am most excited about in the long-term.


I have released a survey allowing the public to express interest in the project and vote about which features they find to be most important.

You can take that survey here.

The results of this survey will be used to prioritize user preferences when determining which project features should be developed first.
The “survey governance” model is as follows:

  • Users who do not own any copies of OBJKT#112092 will have a weight of 1 applied to their response (each vote counts as 1)
  • Users who own one copy of OBJKT#112092 will have a weight of 5 applied to their response (each vote counts as 5)
  • Users who own multiple copies of OBJKT#112092 will have a weight of 5 multiplied by the square root of the number of copies owned. This mechanism is called Quadratic Weighting. It provides some marginal benefit to project supporters who purchase multiple copies of the prototype NFT, but simultaneously ensures that no single individual holds too much power in the vote.

NOTE: The use of OBJKT#112092 to weight votes is not planned as an indefinite feature, and will likely only apply to the first survey. Future surveys will use an actual governance token, distributed to community members who participate and demonstrate interest in the project. The first copies of this governance token will be distributed to users who fill out the above survey.
All users who provide a valid survey response will receive the same number of governance tokens, whether they hold OBJKT#112092 or not. Ownership of the prototype NFT will determine weight of votes when assessing public opinion in this first survey, but such ownership will not lead to any outsized share of future voting power.

Along with this survey, I have written some introductory documentation, which can be viewed as a PDF here. Among other things this includes an FAQ, diagrams, an outline of potential future features of the project, and discussion of topics like governance, royalties, and open-sourcing.

If you would like to stay up-to-date about this project, the best way to do so is to follow the @ArtContracts account on Twitter.
You can also find me on twitter at @MathMakesArt. This pinned Tweet links to a variety of information about the project, both on and off Twitter.


This project is still very much in its infancy. This is my first attempt at creating a DApp. I began this project primarily for learning purposes, and I still have a significant amount of learning to do.

At this stage, there are many directions that development could go. It will likely be a long time before any full public release with user-friendly interface.

My main goal in creating this post is to solicit feedback from the community, both through survey responses and external replies.
Any feedback, including criticism, is highly appreciated.

I am happy to answer any questions you may have in the replies as well. Thank you for taking the time to read about my project!

Here’s something you may be able to pick up, since you are interested in on-chain storage. I was doing some experiments a couple months ago with optimizing on-chain storage from the contract side and stumbled upon a process to make the storage alot cheaper. I call it paramdata abuse.

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.

That’s 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.01 fees each time, far cheaper than 0.25/kB.

Just something to explore if you are interested. I was able to integrate these NFTs into a dApp for sending/auctioning/etc as they are backed by FA2 standard. You just have to index the data a little differently.

But I do think you have something here with on-chain data. I stopped my experiments because I couldn’t figure out the “why?” of what I was using it for, and I think you have that “why”. Combining your compression expertise with on-chain storage is a great selling point, since you can get more data on-chain.

Otherwise, I think you should figure out whether this is a compression software project, or on-chain NFT marketplace project. Imo you could get the compression to a workable state then build the NFT, DAO, and community to fund further enhancements to the compression software, further benefiting the community.
On the other hand, the compression software on its own with all the planned enhancements could probably be used across marketplaces and even chains. Everyone needs compression on blockchain, and creating an all-in-one service for on-chain storage could lead to integrations in multiple places.

:+1: hope to see more!

1 Like

Wow! This is fascinating. Thanks so much for sharing your knowledge. I will absolutely take a deeper look into this.

And thanks for your feedback on the project as well.

This is a very insightful point. I do think the compression-related aspects are the most interesting and innovative, versus more generic marketplace stuff that has been done before.
Especially given that this is my first smart contract project, I’d rather explore novel concepts versus building a mediocre version of something that’s already been done better by others (art marketplaces).

Greatly appreciate all your input, it has given me a lot of things to think about. Cheers!

If I understand correctly, you want to build a new art NFT platform that features interactive artworks (that change over time either automatically or based on collaborative edition). If so I strongly encourage you to contribute to existing platforms such as HicEtNunc instead of building everything from scratch. It is likely that HicEtNunc developers have already thought about developing something similar and they are very open to contributions.

Storing large amounts of data in the storage of smart contracts is generally a bad idea because on-chain storage is super expensive (0.25 tez / KB) because it is duplicated on all the nodes of the network. That’s why NFT platform usually don’t store artworks onchain but rely on other decentralized storage solutions like IPFS instead and only store the hash of the artwork onchain. Storing a hash however only makes sense for totally immutable data; if you want to store mutable data that can be mutated by a well-identified trusted party you can do it by adding a level of indirection: the platform stores the address of a smart contract and the smart contract stores a hash and authenticates the trusted party to let it update the hash.

Also I am afraid that the latency of Tezos (one block per minute, several blocks to finalize transactions) is probably too high for collaborative edition to happen onchain. There are plans to reduce the latency but I doubt they will be enough for these kinds of applications.

Size limit is another drawback. The storage size of a smart contract is not limited but operation size is so you cannot put more than 32KB in the parameter.

Thanks for your reply, I appreciate your enumeration of these concerns.

My main goal is not to build an interactive art platform (or an art platform at all) but specifically to facilitate the storage of on-chain data (including things like compression). This does have applications in art, so that’s what I’ve focused on for the prototype. I realize there are significant monetary costs to on-chain data storage, and other drawbacks beyond the cost alone. Regardless, I also feel that there are many potential cases where these drawbacks are outweighed by potential user demand.

As stated in my previous reply to Arrijabba, I’m less interested in rebuilding things that have already been done (e.g. existing features of Hic Et Nunc) and more interested in exploring utilities that don’t yet exist in the Tezos ecosystem. You may disagree that there’s actual value in storing data on-chain but for me the existing level of user interest is enough motivation for me to explore these ideas.

I will definitely take into account your points about latency as well. I don’t necessarily anticipate that any sort of “live” collaboration will be possible, but I still do want to experiment with giving multiple users the ability to edit the same chunk of data at different times.

My main goal is […] to facilitate the storage of on-chain data (including things like compression).

IMO storing data on chain should be a means not a goal. If you don’t have at least one precise application in mind you cannot take into account the specific constraints imposed by the applications.

You may disagree that there’s actual value in storing data on-chain

I don’t disagree, storing data on chain is what all Dapps do! I am just pointing that it is very expensive so usually we try to store as little as possible.

No prob. And regarding the operation size limit, back when it was 16kB my plan was basically to chunk into 16kB parts and store it that way.

Also, I can’t believe I forgot to link you to

That is the project that finally gave me the push to start doing any development on Tezos. Its an Ethereum on-chain NFT based dApp and it’s pretty successful imo. The big selling point is on-chain storage, then they combine it with some really cool generative art.

1 Like