Subscapes (Part 1 – Preface)

On-Chain Generative Art

This is the first post on a three-part series about Subscapes, a generative art project where the core rendering code has been immutably secured & hosted on the Ethereum blockchain. In Part 1, I’ll explain some of the motivation and technical merits of blockchain-based art, and introduce the Subscapes project. Part 2 will break down the features and traits of the algorithm in more detail—which may be of particular interest for Subscapes owners to better understand their collection. The final chapter, Part 3, will be more technical, going into the JavaScript code, how the rendering is achieved, and how the software and digital tokens can be reused and remixed in interesting ways going forward.

If you are already well-versed with CryptoArt and ArtBlocks, and looking specifically for details about the Subscapes features, you might want to skip ahead to Part 2.

Software as Art

Since 2014, I’ve been exploring code, generative systems, and algorithmic processes as a means of producing artwork. Much of my work today draws inspiration from early pioneers like Vera Molnár, Lillian Schwartz, Georg Nees, Harold Cohen, and many others, who were some of the first to write computer code and software to realize an artistic output, such as an image, mechanical plotter print, or some other form of digital or physical artefact.

Often, when we look at Generative Art over the years, the output of the program isthe artwork that we regard. For example, Computer Composition with Lines by A. Michael Noll is a computer program developed in 1964, using FORTRAN, likely coded on punched cards, but the artefacts of this work that gets archived, displayed, and shared are the digital images and/or physically printed reproductions. Although a computer program drives this kind of work, and may be capable of rendering an infinite multitude of possible unique outputs, the computational aspect can be difficult to archive and display. In many cases, the software and code is lost to history, perhaps because it eventually goes offline, or becomes obsolete with the advent of new technology.

As code and generative art became more widespread, and more accessible to share on the web, we entered into an era of realizing and displaying the software itself to global audiences, rather than a still or video reproduction of the software’s output. For example, Processing used Java applets to allow generative programs to be run and experienced in-situ by any viewer through a web browser. Around a similar time, Macromedia Flash was also being widely used to deliver real-time drawing software on the web, such as Jared Tarbell’s beautiful Substrate algorithm (2003). Sadly, today, years later, both of these technologies have been deprecated and largely removed from the web experience, and we are forced to view and access artworks like Substrate through video reproductions.

While the software is the source of all these artworks, the code is usually forgotten about in favour of a static reproduction. The code must be hosted somewhere; which has historically proven difficult with our traditional centralized systems (such as a web host linked to a domain name; services that the artist/archiver must continue to pay for in perpetuity year after year). The code must also be runnable on future systems, either directly or via an emulator like @bbcmicrobot.1

Archival Coded Artworks

And this brings us to the topic at hand: decentralized and distributed computing as a new form of software art preservation. Platforms such as, which allow artists to upload, market, and distribute their software-as-art, also enable a new paradigm in archiving and hosting these works. When a piece of software is uploaded to the platform, it will be linked with a unique identifier on a peer-to-peer network known as IPFS. This shifts the burden of maintenance from a centralized source (the platform) to a decentralized source (the users), allowing the artists and users to collectively maintain the assets they create and own by pinning the IPFS content on their own machines. Technically, pinning is somewhat similar to ‘seeding’ a video file with BitTorrent.

This solves one aspect of archiving the artwork: hosting the code itself. But what points to the artwork identifier in the vast web of IPFS content, and verifiably links that pointer back to the artist’s hand (to ensure authenticity), and done in such a way that we continue to avoid relying on centralized servers? This is achieved with the distributed ledger, which can log the action of the artist minting the work. Minting is a fancy way of saying “recording an action on a distributed ledger.” The artist pays a small transaction fee to create a new record in the ledger, and includes with this transaction a link that points back to the file identifier in the IPFS network.

When the distributed ledger is a blockchain, the records will be maintained for future archivists to explore, as each new transaction occurs on top of the last in an ever-growing digital logbook. With Hicetnunc, this is achieved with the Tezos blockchain, but other platforms such as SuperRare achieve this with the Ethereum blockchain. Blockchains are the backbone of these cryptocurrencies, and also the source of the currency’s security and value.

With these technologies, and this new paradigm of CryptoArt, we can archive and display the software itself, verified and certified in the ledger by the artist’s hand, and continue to maintain and host these assets in a decentralized manner.

On-Chain Assets

Reading the above, you may begin to see an issue with decentralized hosting: because the burden of maintenance relies on the users, there may be some artworks that are not pinned by enough users in the network, and thus the file could one day go offline or become lost. This is rare, but can happen if the users are not taking collective ownership of that asset. We could imagine this happening in the future, perhaps in a scenario where the platform has become forgotten or obsolete, and so the users may stop bothering to pin and host the body of artworks enabled by the platform.

You may wonder, if we have a distributed ledger like Tezos or Ethereum that (in theory) allows the records to be maintained with a strong degree of permanence and longevity, why not just place the entire software and metadata within the transaction itself, rather than host it with IPFS?

This is exactly what ArtBlocks aims to do, embedding the entire software artwork on the blockchain (“on-chain”), hosting it within the transaction details of the Ethereum distributed ledger. This is very expensive, as each byte of data must be paid for in transaction fees to the blockchain, so it is generally limited to a small program that can fit under several kilobytes. It is so expensive that it warrants a significant return on investment, such as relying on an established marketplace for the distribution.

The transaction fees associated with each byte of data tends to drive many on-chain artworks in the CryptoArt space toward generative art, which allows for a diverse range of high-quality outputs despite the size restrictions. These works are typically created with code, in an almost demoscene-like fashion, rather than through mainstream digital art tools that are popular on many IPFS-based platforms.

ArtBlocks, launched at the end of 2020 and largely created by a single developer (snowfro), is a platform that aims to help facilitate on-chain art with nothing more than a JavaScript program. This enables a wide array of interesting possibilities such as generative imagery, audio, animations, and other interactive and real-time web applications.

It should be noted that, although I appreciate the technical, archival, and conceptual aspects of on-chain art, I also see plainly that its costs are currently a limiting factor, and deserves further research and improvement. This is why, although I may hold some on-chain work to a higher standard, I am also interested in IPFS-based works such as those on Hicetnunc, and believe in both approaches. And, after learning to pin my own assets, I’ve come to better understand how long-term archiving could also be possible with IPFS, with additional effort and considerations.


A final piece of the puzzle that helps drive this new market of CryptoArt is the tokenization of an artwork. The blockchains that secure and host this on-chain archival software not only helps to host the art, but enables a new market and distribution channel for it. The artist can decide to sell, via the cryptocurrency, a limited number of tokens associated with the artwork, similar to a print artist creating a limited edition series from a master. On ArtBlocks, the artist chooses an edition size and cost, and collectors can mint each edition by purchasing a token, known as a “Non-Fungible Token” or NFT. In the case of generative art, where each iteration of the software is often unique, the Ethereum transaction also records the metadata necessary to reproduce the particular output associated with the purchased edition.

These purchases are backed by “smart contracts,” small programs that can be designed to distribute and manage the finances in different ways within each blockchain transaction. Smart contracts are developed by the platforms and hosted on-chain, ensuring the financial operations are secured and verified by the blockchain. In the case of ArtBlocks, each “mint” operation directly sends 90% of the token sale to the artist, and 10% to the platform (for its services). And, further, if a collector re-sells their token in what we call the secondary market, moving the token from one owner’s digital wallet to another, a 5% royalty on that sale will be fed back to the artist.

Tokenization and smart contracts open the doors for many applications around creative markets, but also allow for new ways of computationally sharing earnings, such as large scale collaborations (automatically splitting proceeds among many creators), setting up royalties for the Open Source tools and libraries driving these artworks, automated charitable contributions, Decentralized Autonomous Organizations (DAOs), and much more.


In April, I was invited onto ArtBlocks’ Curated Artists track, and given the tools needed to upload a small generative JavaScript program (~17 kilobytes in size) and its metadata directly onto the Ethereum blockchain. This is how the Subscapes project came about; creating a unique set of 650 program iterations minted from an infinite array of possibilities.

The design of Subscapes started as a rather simple concept: a generative algorithm that, each time it runs, produces a unique and other-worldly landscape, realized in the style of a topographic map, and rendered with pen-like strokes, as if it were mechanically plotted by a team of geologists surveying the metaverse.

Although the algorithm is capable of producing an infinite number of unique visual editions, I developed the work with the intention of being distributed as 650 limited editions, using deterministic randomness to ensure each single edition produces the same unique output each time the software is run. When an edition is first minted by ArtBlocks collectors, a Token ID from the transaction is tied to a hash generated by the ArtBlocks smart contract. This fixed hash is used as input for my generative algorithm, producing a rendered output. With this system, the artist and buyers do not know exactly what kind of output will be minted across all editions, as it will be randomly determined at the time of purchase. However, collectors generally have a good sense of the overall aesthetic and quality of a work before purchasing, as they can see various draft mints the artist publishes on the Rinkeby testing network.


Subscapes was well received by collectors in the ArtBlocks and CryptoArt community. All 650 editions (or ‘tokens’) sold out within 8 minutes of the project’s release. At the time of writing, eleven days later, 268 Subscapes tokens have continued to trade on the OpenSea secondary market totalling 289.41 ETH spent by collectors ($977,962 USD at the current exchange rate). Seeing this kind of enthusiasm and market form around Subscapes across Discord, Twitter, and Instagram, reveals to me the rapidly growing appetite for collecting on-chain generative artworks, and the potential for these platforms to further evolve as a new space for supporting artists & creatives. This is particularly the case with ArtBlocks, which has become a trusted source for these works, and sits comfortably among the top CryptoArt/NFT platforms by sales.

🌱 A portion of proceeds from Subscapes have been directed toward 3 pro-climate carbon offset initiatives in Brazil (rainforest protection), Belize (nature conservation), and Honduras (wind energy), purchased through Offsetra. Some proceeds will also be directed toward non-profits in the art space, including Processing Foundation.

Going Forward

Over the last few months of participating in CryptoArt and better understanding some of the technical merits of decentralized computing, I’ve come to appreciate many aspects of it. I’ll be continuing to explore this space going forward with a mix of on- and off-chain projects, primarily across two blockchains: Ethereum and Tezos. I see this as a space that is still young and imperfect, with plenty of room for improvement (fees, energy efficiency, democratization, and so on), but the amount of public interest and new opportunities being created for artists—particularly digital and computational artists who have been traditionally exempted and ignored by the mainstream art world—is hard not to celebrate.

Continued in Part 2

Part 2 of this post will break down the “features” and traits embedded within the algorithm, to help collectors better understand how their work fits into the set of 650 minted editions.

Addendum: May 5, 2021

I originally posted this May 4, 2021, but the platform (Substack) spontaneously deleted my account and all of my written content within an hour of publishing. I was only able to recover my two posts thanks to some readers that still had local copies open in their browser tabs. The irony of losing my own essay about decentralized hosting because the content was hosted on a centralized platform is not lost on me. I’d like to explore some decentralized and distributed blogging solutions in the near future, given what I’ve learned in the last several weeks, once my current projects wrap up.


Something I didn’t address in this Part 1 is the possible need for future emulation of on-chain works. This may be addressed in the technical details of Part 3, as the Subscapes algorithm is designed to be usable outside the constantly-moving target of the web platform.