crypt0den is a blockchain version of a work in 44 Signs of the Times. The NFT can be viewed here, but, like much software, is badly engineered and temperamental. Documentation of both below.

Motivation

In early 2021, the media, and many in the Artworld, were afire with excitement about NFT (Non-Fungible Tokens), which had in fact been around for a few years. Others were in a lather about the ecological impact, which had also been apparent for a while. In 2016, I wrote about blockchains and art, and was really interested in the philosophical and technological issues raised by proof-based-consensus and distributed ledgers. Yet, the idea of actually making an NFT was a bit meh...captured perfectly in an essay I was reading: Bartleby, or On Contingency.

In it, Giorgio Agamben deconstructs Bartleby's rejoinder 'I would prefer not to', and uses the story as a scaffold to talk about potentiality, particularly in Aristotle and Leibniz, and also in Jewish/Islamic accounts of the creation. This fit in quite well with my own research on the Simulation Argument's theological and museological implications. Some of this found its way into a video, which I then encased in a NFT. The video (see above), entitled '.deleteIdentity()', is on show at Mana Contemporary as a bog-standard .mp4. The NFT is online, deployed on an Ethereum testing network owing to ecological concerns (the big energy burn happens when contracts are actually deployed to the main network).

Why cares?

On a technical level, crypt0den is interesting because it involves two interacting codes. One is a webpage written in Javascript/CSS/HTML (like most webpages), and the other is a 'smart contract' written in Solidity (Ethereum's principal language). Depending on who owns the smart contract (i.e. I, who made the thing, or some future hypothetical collector), the webpage renders in different ways (it degrades/glitches). This is different from most NFTs one finds on (say) OpenSea: most NFTs are a sound, video, or image file that can be bought/sold but essentially remains unchanged. But I specifically wanted the webpage to change itself by querying the smart contract's internal logic.

I also wanted to explore notions of how an artwork changes between the creation (i.e. studio) and the collector. Like, certain paintings are arguably famous owing as much to their collection history rather as their intrinsic merit. The intersection of collecting and value - both monetary and aesthetic - continues the investigation begun in Derivative Work.

As institutional critique, does an artwork sitting in a public collection or commons (like the web) have a different cultural value when/if it is privatised by a collector? Can an artwork, in our time of pervasive reproduction, be destroyed or damaged, that is, what is the site of content (or identity), for an artwork? Does that burnt Banksy exist in a meaningfully worse sense now that a NFT has recorded its immolation?

Writing the thing

Lastly, I wanted to write a smart contract from scratch (as opposed to using the NFT widgets on OpenSea etc.). I built off the ERC721 template, but the act of writing in Solidity was curious - because the blockchain has so little space, the language is parsimonious and restrictive, akin to assembly one might have used decades ago. There was also the terror: the consequences of writing a program that can never be changed (once it is committed to a blockchain) in a language that is primarily used for financial transactions, i.e. fuckups cost real money.

Then I tried to re-implement the Solidity (Ethereum chain) code in the Michelson/Ocaml language family (used for Tezos chain), which got weird fast and was a total fail.

Some NFT resources

Within the NFT world, there are many artists' projects that push the envelope in fascinating ways: e.g. Larvalabs' Autoglyphs, Ezra Miller's Solvency, Ryan Kuo's File, or some of the extensions on hicetnunc.

The venture capital firm Andreessen Horowitz has a good 'canon' for all things NFT.

One of the best guides to writing an ERC721 contract from the ground up, testing, and deploying with relatively little jargon or assumptions about prior knowledge comes from Alchemy. In particular, they focus on the Ropsten and Rinkeby testnets, which allow experimentation without expenditure.

For playing with Solidity, making fake (costless) calls to a blockchain, debugging: can't beat the Remix browser-based development environment. The documentation is pretty decent.

A somewhat more involved guide, more focused on deploying production-quality contracts, comes from OpenZeppelin who also produce a well-known implementation of the ERC721 standard.

Gas, i.e. the cost of making a transaction on Ethereum, was confusing for me. This Ethereum-hosted page explains gas and other topics. The price of gas is not fixed, this is one of the sites that tracks it. Remix and Alchemy/Ropsten provide estimates of the gas consumption of one's proposed contract, and there are fiddly little ways of making contracts more gas-efficient.

The issues around energy consumption in crypto have been written about. However, there are other options - for instance, the hic et nunc art platform use a different chain called Tezos, the foundational technology of which (proof-of-stake) uses much less energy and costs much less in fees (than proof-of-work, the technology underlying Ethereum, though that is due to change), hence is better for messing around with. hicetnunc is easy to work with, but the underlying Tezos chain is harder to program (rather than Solidity, a C or Javascript-like language, there are a bastard family of LISP-derivatives used in Tezos.)

hicetnunc has the advantage of (easily) accommodating more complex websites, such as those containing shaders or p5js scripts, see the templates and wiki sections here.

For geeks and the historically-minded, the foundation documents for Ethereum and Tezos are worth a read. The Ethereum paper elucidates some basic concepts around proof-of-work and cryptography, while the Tezos paper has interesting insights about self-modifying code and blockchain governance.