layer_two visuals generated from the_coin


A little experimental NFT project exploring the conceptual and technical curiosities of “L2” in Bitcoin and other chains

Takens Theorem
17 min readMay 22, 2022


Summary, tl;dr

“layer_two” is a small, experimental NFT project inspired by how ecosystems expand and diversify. In crypto, this is best illustrated by “layers.” A base layer, or “L1,” is a foundation for layers built on it. A new layer built upon an L1 is referred to as a second layer, “L2.” This layered development is meant to expand and diversify the capabilities of the base layer’s ecosystem.

The NFT project layer_two is itself a kind of second layer. It is built on my 2021 project the_coin: fully on-chain expressive data visuals of Bitcoin’s nature and history. layer_two is free for collectors of the_coin (except gas), and enables them to mint NFTs that make use of the_coin’s on-contract memory to create new visualizations. layer_two visuals transform and manipulate the raw data of the_coin’s on-chain visuals. Emerging from this process are forms more complex and curious.

Example visuals from base token; owners can mint 1 per week (42,000-block interval)

In simple terms, you can think of layer_two as a kind of 100% on-chain generative “art” contract. Owners of the_coin can mint new visualizations onto layer_two that are derived directly on-chain from the_coin pieces they own.

But the main ingredient in layer_two is an experimental curation layer. layer_two lets the_coin owners control the supply and direction of an extension project. Owners manage the expansion collectively, they control the supply (relative to the tokens they own) and they can expand the community as they see fit. They can gift a set of layer_two visuals, put them on secondary, collect batches of them under particular themes, and so on. In that sense, layer_two decentralizes ecosystem expansion by putting it in the hands of the_coin owners themselves.

As my other projects, I share detailed motivation for this project. I hope you’ll forgive the detail, but find it interesting. (If you’re a collector of the_coin and don’t have much time, jump to “⭐️ Quickstart” below, or visit the project’s interactive website.)

Table of Contents

  • Background
    — Emergence
    — L1 & L2
    — Generalizing “Layer” Concept with NFTs
  • Introduction to layer_two
  • Guide for the_coin Collectors
    — Contract
    — Important Features: Rules, Distribution, Etc.
    — ⭐️ Quickstart: Minting with a “Nonce”
  • Tributes & Related Projects
  • ✳️ Terms & Conditions


“…a self-organizing system of patterns, relations and wholes, constantly rebuilding itself and re-relating itself, leading to the creation of new wholes and newer ones and newer ones.”
B. Goertzel, “Emergence and complexity” (2002)


Blockchains seem like clunky things, data chunks fused by immutable hashes. But blockchain protocols are more fluid than they seem. Their codebase evolves by the collective work of many developers. Their live behavior is also more stochastic as blocks get stitched together. A blockchain (with a community, liveness, etc.) is a dynamic, changing system. This is true even of Bitcoin (though it may change more slowly than others).

The quote above from the great Ben Goertzel makes us think about systems as developing and “re-relating” into new wholes—“newer ones and newer ones,” as Goertzel says. Blockchain is full of such expansive momentum. Sometimes this momentum leads to horrifying failure. Ecosystems proliferate nevertheless. Some are thriving, and constantly “rebuilding themselves and re-relating themselves, leading to the creation of new wholes and newer ones and newer ones.” These ecosystems can evolve rapidly into elaborate and gaudy things, rife with experimentation and curiosities.

In crypto, the most prominent area where this is true has become a strengthening narrative in 2022: the concept of “L2.”

L1 & L2

A second layer, or “L2,” is built on top of a base layer, or “L1.” Bitcoin is an “L1” layer, it settles its transactions directly on its own chain. But because Bitcoin is throttled, in both speed and transaction cost, an L2 can extend functionality of the Bitcoin ecosystem overall. This permits applications to scale up the rate at which transactions can be processed, and scale down their cost in fees. But the L2 stays “associated” in some way with the L1, the base layer. Because of this, the L2 is considered part and parcel of the L1’s ecosystem. It expands the range of possibilities of Bitcoin, emerging from but going beyond the base layer itself.

There is debate about how to define “L2” in technical terms. A key idea organizing this discussion is the manner in which this L1-L2 association is established.

Consider two examples built on top of Bitcoin: Lightning Network, and Stacks. The Lightning Network is built from payment channels that represent a commitment from a wallet on Bitcoin’s L1 and sent to the Lightning L2 (by committing some amount of bitcoin). As payment channels get established on Lightning, the network grows and it is possible to transact much more quickly in a peer-to-peer fashion without having an intermediary hold the relevant bitcoin. In theory, Lightning is rocket fast as it is a parallel system of channels, and so could easily achieve thousands of transactions per second or more. And because it does not require immediate L1 (Bitcoin) settlement, it can conduct business repeatedly across channels almost for free.

Lightning Network illustration (source)

Stacks can be considered a layer on Bitcoin, but it is often described as an “L1” that inherits Bitcoin’s security features. Bitcoin expends a lot of energy to secure its ledger. Stacks leverages Bitcoin’s energy spend. To do this, Stacks encodes its own blockchain history (relevant hashes) on Bitcoin, meaning that to attack Stacks (and reorganize its blockchain) would require as much energy to attack Bitcoin itself. But the content of these blocks is independent of Bitcoin, so Stacks can be considered a sovereign L1 that is strengthened through this link to Bitcoin.

In these examples, we see two strategies that emerge from the base layer of Bitcoin. Bitcoin’s rules (in particular, Bitcoin-based smart contracts) enable a solution to scaling in the Lightning Network, an explicitly designed L2. But another core property of Bitcoin, the manner in which its own ledger is secured, facilitates the emergence of other applications too — in this case a new L1 Stacks that makes use of Bitcoin.

Ethereum has many such examples of second-layer development. This development sometimes also prompts dialogue about how to define “L2.” Like the Lightning Network, the goal of most of these L2 solutions is to scale Ethereum by increasing transaction rate and lowering fees. Solutions abound, including innovations in using zero-knowledge proofs to bundle transactions. Ethereum includes an entire ecosystem of L2/scaling solutions: Polygon, Arbitrum, Optimism, Loopring, Immutable and more. Revisiting Goertzel from above: “…constantly rebuilding itself and re-relating itself, leading to the creation of new wholes and newer ones and newer ones.”

Map of Ethereum scaling solutions (source: bacool @ Messari)
Ethereum L2 activity, from recent Paradigm post (source:

(Important side note: “L2” may oversimplify the goals of these various projects. As scaling solutions evolve, it may be more important to specify the design features of layers, such as whether they use rollups or some other mechanism. Some argue that L2 may be replaced with a different scaling strategy, such as facilitating a multi-chain ecosystem with cross-chain capabilities. This is outside the scope of this brief post.)

Generalizing “Layer” Concept with NFTs

In the examples above, the L2 relaxes particular constraints on L1 while remaining, in some way, integrated with that L1. The most common constraints that L2s seek to relax are the rate limit and cost in transacting. But the idea of an L2 is more general than this. It does not have to be only about scale, it can also be about function. L2 scaling solutions are just a subset of a more general class of what could be called “functional constraint relaxation”—namely, relaxing limits or constraints on potential processes of which the L1 is incapable.

How might this work for NFTs? What is an “L2” for an NFT?

Here’s a related example. Contracts that fractionalize NFT tokens may be considered a kind of L2 on top of the ERC-721 (or other) standard. These contracts increase the functionality of NFTs by allowing wallets to own portions of NFT tokens, which are otherwise non-fungible and indivisible. The vaults of Fractional illustrate this. Vaults are contracts holding NFTs that have been fractionalized for others to own collectively.

Illustration from Fractional blog

We don’t typically think of L1s and L2s as instantiated on the same chain. But you can conceptualize the “L1” in this case as the base contract, and the “L2” as a contract built on top of it to relax particular constraints. Ideas for functional constraint relaxation seem to flow when conceptualizing NFT “L2” solutions in this way. Here are some example functions that can be accomplished on top of ERC-721 tokens.

It does seem awkward to think of NFTs in these “layer” terms. But it provokes a style of thinking about projects. NFTs are a kind of base layer, a “cultural raw material,” and they can be adapted as a foundation for other projects.

Building on NFTs this way will be more complex than just two layers, “L1 and L2.” As noted in the prior section, “L2” could become archaic as terminology. With NFTs, the future may hold “expansive NFT universes” as Simon de la Rouviere calls them in this beautiful blog post. Simon illustrates a “flywheel” theory of building on top of projects, which leads to more complex interwoven economies and artifacts, going beyond the simple frame of “L1” and “L2.” Akin to Goertzel’s “creation of new wholes and newer ones and newer ones,” de la Rouviere sees an “IP remixing theme park wonderland.”

Simon’s CC0 flywheel, from “Building Expansive NFT Universes
The Nouns NFT project exemplifies a rich derivative landscape (Noun Center; image from Simon’s blog)

Still, L1 and L2 are seed concepts for this complexity. L2 represents that first step beyond the base layer and into new ecosystems. So I use it here.

The next section introduces the project called “layer_two.” It relaxes constraints by building on top of my NFT project the_coin. layer_two is free to use for collectors of the_coin, and allows a token’s owner to mint weekly NFTs that make use of on-contract memory to create new visualizations. I am inspired by this concept of “new wholes” and “theme park wonderland”—the complex and gaudy forms that emerge into a base layer’s ecosystem.

Introduction to layer_two

I introduce a new and experimental little project I’ll call “layer_two” in the spirit of this first level of abstraction, from base layer to new functionality. The base layer of layer_two is my 2021 project the_coin. (Like my Ethstory project, most of the proceeds from the_coin’s initial sale went to several charities.)

the_coin is a small-scale NFT project. A “miniseries.” … I am inspired by Satoshi and Bitcoin and its history ... I decided to create just a handful of very simple data visualizations. These are carved carefully from on-chain and other data. They are small-scale graphical reminders of its history, encoded on Ethereum as on-chain SVGs, technically inspired by such projects as these. I decided to churn the data into visualizations inspired by a “digital time capsule” concept…
— from the_coin Medium article

the_coin base layer, “Issuance” token (1 of 4 editions; 21 each = 84 tokens on L1)
layer_two token rendered from “Issuance” (token #1)

In simple terms, you can think of layer_two as a kind of on-chain generative “art” contract. Owners of the_coin can mint new visualizations onto layer_two that are based on the_coin pieces they own.

layer_two is an ERC-721 contract that calls and manipulates the on-chain asset for the_coin (the_coin’s visuals are entirely encoded 100% on chain). layer_two inserts a stochastic snippet of CSS and renders a whole new on-chain SVG. This visual is entirely mapped onto the “L1” of the_coin. Using a single on-contract 20-line function, the CSS transforms and colors the objects in the_coin token’s original asset according to a “nonce” (a nonce is a number you supply to layer_two to generate pseudo-randomness).

Top: the_coin base layer “Miner 1”; bottom: layer_two renderings by “hashing” with a nonce

Once a layer_two piece is created, it is forever built from the content of its base layer. If the corresponding the_coin token changes hands, the piece updates on the L1 contract (specifically, the new owner’s wallet address is shown on the piece). This creates a corresponding change on layer_two. It is tied directly to the base layer (note: the visualization itself won’t change, just that encoding of provenance on the piece).

2021 the_coin is a dynamic NFT: provenance dynamically updated on assets themselves

What is the functional constraint relaxed here? I setup the_coin to have strict issuance limits. There are only 84 tokens (and at the time of this writing, about 40 owners of these). So layer_two relaxes this constraint, and allows a new “ecosystem” of visuals to be issued, emerging from the base layer. The layer_two also makes use of the contract memory of the_coin. Much as Stacks is secured by Bitcoin’s energy spend, layer_two’s pieces are rendered costlessly by using already-stored data on the_coin’s main contract.

Top: the_coin base layer “Issuance”; bottom: layer_two renderings by “hashing” with a nonce

I designed the algorithm that extends the_coin tokens to be gaudy, flashy or curious much as we described above: new forms and newer ones. the_coin owners have some control over these visualizations. layer_two has a “preview” contract function permitting its owner to “hash” over and over until they find what they like (see tribute remarks below, as this relates to some wonderful, important NFT projects). Owners can then commit their piece to the chain. And like the_coin, layer_two tokens are 100% on-chain variations of their base layers.

But the main ingredient in layer_two is an experimental curation layer. layer_two permits current owners to control the supply and direction of an extension project directly. Many other NFT projects that have released derivatives or associated brands have given minting priority to prior owners, but have also expanded the ownership set. In the layer_two project, I strictly limit the initial ownership set only to those who are current the_coin owners. Owners manage the expansion collectively, they control the supply (relative to the tokens they own) and they can expand the community as they see fit. They can gift a set of layer_two visuals, put them on secondary, collect batches of them under particular themes, and so on. In this way, layer_two decentralizes ecosystem expansion by putting it in the hands of the_coin owners themselves.

Top: the_coin base layer “Integration”; bottom: layer_two renderings by “hashing” with a nonce

Guide for the_coin Collectors


The layer_two contract is verified on Etherscan here. For the_coin owners, please make sure to check the address closely when interacting:


There are three main functions you can engage with as an owner of the_coin. The first is a previewer to see what your layer_two piece will look like: previewL2(...). This function does not require a transaction. You can interact with that function directly on Etherscan, but below I describe an interface that can help you preview pieces.

When you’re ready to mint your layer_two piece, use mintL2Token(...). This commits your piece to the chain. This requires a transaction. Note: As usual, I ask owners to use Etherscan to engage the contract. I will never use a special website for you to engage with my contracts. Why? On Etherscan, you can conveniently use the functions, and check the contract’s address and verified code all in the same place.

Finally, the function nextMinting(...) lets owners check how long they have to wait till their token ID can mint a layer_two again. This function displays “WAIT” if the interval has not passed, and then the number of blocks left, and an approximation of seconds, minutes, hours and days remaining.

✳️ Here’s the OpenSea collection.

Important Features: Rules, Distribution, Etc.

There are a number of features to layer_two. Some of them I will not mention, inviting you to discover them in working with nonces and hashing described below. Here are some key features to be aware of right away, starting with the most important:

  • You can only mint a layer_two (“L2”) token about once a week. As a second layer to the_coin, I chose 210,000/5 = 42,000 Ethereum blocks as the minting interval (usually just under a week). At first, I was tempted to make this much longer, restricting supply, but that seemed too slow. But if each the_coin token could create a layer_two daily, it seemed too frantic. I throttled it at 42,000 blocks, which seemed like a good pace. Slow enough to take care in what is minted, but passing quickly enough to mint each week. Note: The schedule for minting is a wait time interval not a calendar; when you mint one, you then have to wait another 42,000 blocks for the next (you can’t “save them up” over time).
  • It is free to mint layer_two tokens. You just have to cover gas. Because this layer_two makes use of the_coin’s contract functions, minting is relatively cheap, under 200,000 gas. Even if base fee were 50 gwei, this means that your minting shouldn’t cost more than about 0.01 ETH.
  • I developed and tested the rendering functions using OpenSea and Google Chrome. The pieces (SVGs) may look different in different browsers due to the CSS transformations that the contract generates. Please also consult the Terms & Conditions for a reminder that this is an experimental project.
  • the_coin is also modifiable, dynamic. As owners may remember, 2021 project the_coin is a fully modifiable NFT — owners can integrate snippets of CSS to transform their pieces. layer_two, in a sense, is creating new tokens out of this base layer of the_coin by facilitating the CSS-generating phase. It simplifies it by letting owners sift through various nonces to determine which they prefer (see below). Both the_coin and layer_two are rendered as 100% on-chain SVGs. layer_two uses an efficient 20-line function to embed a new CSS snippet that transforms and colors the data-based visualization on the L1 contract.
  • layer_two is not simply expanding issuance of the_coin. layer_two tokens are fixed once you mint them—they are not modifiable NFTs like the_coin, and they are on a separate contract. the_coin tokens will only number 84 (4 editions, 21 each), and only the_coin can generate layer_two tokens as the “L1.”
  • The theoretical supply of layer_two is infinite, but minting is throttled in time by a wait interval. If each the_coin token produced one layer_two per week, each year there’d be about 4,400 new layer_two tokens. I suspect engagement will vary across collectors and not all will mint — so the issuance over time will likely be much lower than this. As noted above, it is up to the owners of the_coin to determine this as an outcome of their individual decisions.

⭐️ Quickstart: Minting with a “Nonce”

Step 1: Find an output you like (previewing)

The layer_two contract has two functions to consider for minting. The first, previewL2(baseTokenId, nonce), generates a preview of what a layer_two piece will look like. You give it two pieces of information: your token number (the base layer token from the_coin) and a nonce, which is any integer 0 or larger. The nonce, in the spirit of Bitcoin itself, is the basis for the randomization of the layer_two visual. Like hashing with a nonce though, it is deterministic—the same token ID and nonce combination will reproduce the same visual (so owners can “fork” a specific visual, replicating a new copy). This function allows owners to preview their layer_two pieces before they mint them.

🛠 Helper website: I have created an interface on my main website that calls this function for you (it calls the contract directly through a node with Alchemy). It is a web-based GUI for you to choose your token ID and a nonce and inspect how it looks. Once you are happy, carefully record your token ID and nonce value.

Step 2: Commit your nonce to a layer_two mint

When ready to mint a layer_two token, use mintL2Token(baseTokenId, nonce). With the same base token ID from the_coin and the nonce that was chosen, use Etherscan to send your transaction. It requires no ETH besides gas for the transaction:

Your the_coin token ID goes in baseTokenId; nonce can be any integer ≥ 0

This will encode the new layer_two visual into contract, and display it in the OpenSea collection with the next token number in layer_two. The name of layer_two tokens has the following format:

L2 #(new token ID) ([base token name]/#[base token ID])

I’ve already minted a few layer_two from my own the_coin tokens. Here is the first, minted from “Issuance” token #1 on the_coin, as the first layer_two (“L2”) token:

L2 #1 (Issuance/#1)

I minted the second layer_two from the_coin token #81:

L2 #2 (Security/#81)

Left: L2 #1 (Issuance/#1) / Right: L2 #2 (Security/#81)

Tributes & Related Projects

Bitcoin. layer_two continues the tribute to Bitcoin like the_coin. It expands on some blockchain concepts that relate to this domain. As noted in the_coin project’s Medium post, “…because these modest visualizations live on chain, this encoding of Bitcoin — as an idea, as a history and as a transformative economic contribution to human civilization — will propagate long into the future. Like a digital time capsule.”

Proof of {Art}work (2021). Some features of layer_two are natural reflections of this core tribute. For example, “hashing” by a nonce to find a preferred visualization is akin to the race of miners as they seek a nonce that satisfies a particular candidate block on Bitcoin. There is a beautiful precursor project by the amazing @divergencearran that draws from this inspiration too. His 2021 “Proof of {Art}work” is a brilliant mathematical system that looks like a scintillating pointillism — a beautiful topology assembled from seemingly countless points, landscapes and alluring shapes. But this mathematical system is not guaranteed to render such beauty. The artist has to hunt for them in this topology. Thus the artist’s piece itself is a kind of “proof of work,” like Bitcoin—stochastically exploring an expansive parameter space in order to find aesthetic “solutions.”

Proof of {Art}work

Colorglyphs (2019). A classic project in the NFT space is Colorglyphs from Dan of OpenSea. Dan’s intention was to extend Autoglyphs by rendering vibrant new visualizations built from the Autoglyph generative art algorithm: “Colorglyphs turns the black elements in an Autoglyph colorful, using hex colors drawn from the address of the Colorglyph’s creator.”

Colorglyph #467

BlockArt began in early 2021, and uses a similar blockchain-based seeding mechanism to render art pieces. This innovative platform fuses block data with generative art aesthetics. Many artists have created projects on this platform, including artplusbrad, Ruben Alexander, Nadieh Bremer and others.

Wanderlust #10760 on EthBlockArt

Expansive NFT Universes. Finally, I’m much inspired by the idea of ecosystem expansion, especially in the NFT space. I’ve been brewing various plans, including this layer_two, for some time. Inspiration to ship came from Simon de la Rouviere’s compelling blog post. I share his inspiration for these NFT universes, and find his post to be the best statement of it at present.

Nouns. The Nouns universe is used as an example by Simon in this blog post, showcasing rich forms of derivation and building. layer_two’s weekly schedule relates to the ‘temporal scarcity’ that Nouns innovated: One Noun NFT can be minted each day for eternity.

✳️ Terms & Conditions

Experimental, use at your own risk. Each token provided as-is and as-available without any and all warranty. By using this contract you accept sole responsibility for any and all transactions involving layer_two. Tokens may appear different across browsers, and may not be formatted correctly on all exchanges. No assurances of any kind given. Like any project of this nature, there may be unforeseen errors or issues that are discovered during the course of deployment and use. These are important caveats, but I hope you like it.



Takens Theorem

Dynamic distributed data displays. Intermittent. Friendly.