Starting to define layers, a year later

I’ve been working on Bitcoin Layers for over a year. Before working on this full-time, I hacked on a clunky front end with ChatGPT after my day job at Espresso. Fun times.

It’s been a wild ride. It hasn’t been perfect, and figuring out how to define this new category is certainly a challenge.

But it’s been a year. It’s about time we work towards providing a clear and concise definition of what a bitcoin layer is, and which protocols are legitimately connected to bitcoin. Let’s get to it.

Layer 2s and bitcoin native protocols

A layer 2 is a protocol that provides users the ability to leave an offchain system if its operators go offline and also ensures that the operators of a system cannot cheat. Both of these assumptions need to be provable and enforced onchain.

Currently, Lightning is the only protocol in production that can meet this standard. But, there’s protocols that make different tradeoffs and can still provide users the ability to unilaterally exit. Unilateral exit means that a user can leave a system if its operators go offline.

To exit a protocol unilaterally, a user needs a couple things. A claim on a UTXO locked in a contract on bitcoin, and the most recent state of the respective network. Meaning, they need custody of their funds and the data for the protocol needs to be made available to them. They also need a mechanism by which the validity of the offchain systems state progression can be proven onchain.

Bitcoin has limited scripting capabilities and can't enforce state-carrying spend restrictions on UTXOs. It also cannot verify offchain state transitions to update the spend restrictions on said UTXOs. This is a fancy way of saying bitcoin cannot build trust-minimized bridges to sidechain-style protocols (for our definition of trust minimized, see here).

Thus, the only offchain protocols that see users retain (a semblance) of custody are Lightning, Statechains, and implementations of Ark. These are systems where users enter a collaborative, 2-2 multisig with a counterparty or operator. If this entity goes offline, a user can exit any of these protocols with an L1 transaction.

There’s tradeoffs related to these systems, but ultimately a user can reclaim their funds onchain. That’s what makes them bitcoin native.

Arks, statechains, and Lightning are bitcoin native protocols.

Sidesystems

Sidesystem is a generic term that describes a blockchain that provides offchain execution for bitcoin users. 

We are adopting this term because it is ambiguous and enables us to include various types of protocols within this category. For example:

Sidechains are independent, monolithic blockchains that are bitcoin-denominated systems. Networks like Rootstock are bitcoin sidechains. They do not rely on another token to incentivize network operators.

Other systems, like client-side validated protocols, are not sidechains because users do not rely on an independent blockchain for consensus and finality. But since they need a mechanism to “bridge” bitcoin onto the protocol, they fit within the bitcoin sidesystem category. Rollups (blockchains that use bitcoin for consensus) are also sidesystems, and are more closely integrated with bitcoin than sidechains.

Systems like Stacks are not sidechains. This is because they rely on another, alternative validator set with an alternative token to function (e.g. pay rewards & fees). Stacks is more closely related to an anchor chain; a system that anchors itself to bitcoin and receives some additional protection against chain reorganizations. Stacks does this through its hybrid Proof-of-Burn/Proof-of-Stake mechanism.

Upcoming systems like Arch Network are alternative blockchains where their execution environments can interact with L1 scripts or PSBTs. Because they enable L1 and offchain execution, we will refer to them as Hybrid Chains.

Bitcoin staked, proof-of-stake systems will be referred to as Stakechains. Systems that enable remote bitcoin staking, but use an alternative token for their own consensus mechanism, are Hybrid Chains because they enable users to interact with L1 scripts, but an alternative chain with its own token is used for consensus, transaction finalization, coordination of slashing, and assignment of stake.

Why are we creating so many definitions? Well, if everything is called a sidechain (as many people do), we lack nuance. Breaking up this sole large category into smaller categories enables us to more clearly define what their relationship is with bitcoin.

With all of these definitions in mind, we can define the sidesystem group as:

Alternative blockchains that are bitcoin-denominated and/or rely on bitcoin for consensus, transaction finalization, are secured by native BTC, or support interactions with L1 scripts or PSBTs.

Alternative chains

Using a wrapped version of BTC on an alternative blockchain (e.g. Ethereum) does not qualify something as a sidesystem. If we consider the use of wBTC on Ethereum as making Ethereum a bitcoin sidesystem, then our definition for sidesystems has lost all meaning. Without this meaning, we cannot encourage projects to meet higher technical standards related to their connection with bitcoin. 

Thus, any alternative environment that supports derivatives of BTC on its chain is considered an alternative chain. Alternative chains have no connection to bitcoin, but allow users to leverage custodially backed BTC-assets for different onchain applications.

There is no incentive for an altchain to create an execution layer for derivatives of BTC. There also is minimal incentive to create more distributed forms of BTC custody for the derivatives. On the top 5 execution layers for offchain BTC, 93% of the BTC backing various derivatives is secured by centralized exchanges. This trend will only continue if we continue to equate bitcoin sidesystems to alternative chains who have no incentive to build more distributed forms of BTC custody for their blockchains.

Why altchains cannot be classified as sidesystems

You might think, “well, most so-called sidesystems are really no different than altchains in practice.” You’re 100% correct. This is why we have decided to list all execution environments for BTC on our website. Users should be able to understand the risks associated with using derivatives of BTC across many chains. But, because we previously listed everything together, people may have gotten the impression that we are celebrating all use cases and usage of offchain BTC.

This isn't the case. We want protocols to distribute their trust assumptions as much as possible. If not, then why are we building on blockchains in the first place?

The requirement to be a sidesystem on Bitcoin Layers

We need minimum technical requirements for bitcoin layers. So to be considered a sidesystem, protocols need to have a two-way peg with bitcoin. They must also at a minimum:

• If federated, disclose the operators of their system and two-way peg
• If denominated in another token, disclose the operators of their system and two-way peg and at a minimum checkpoint its state to bitcoin

If a protocol is a rollup, sidechain, hybrid chain, or a stakechain, then they likely surpass these requirements. 

A challenge to protocols aiming to be sidesystems

With these requirements in mind, we have a challenge for teams who claim to be a bitcoin L2. 

On the Bitcoin Layers website, there are 15 protocols listed as sidesystems. 1 is a completely federated system and only 4 of them have a direct connection to bitcoin. These projects are:

• Nomic: checkpoints bitcoin to create a reserve wallet for BTC backing nBTC
• Stacks: has a public federated bridge and checkpoints to bitcoin for added reorg resistance
• Rootstock: is merge-mined, public federated bridge and is a sidechain denominated in BTC
• Internet Computer Protocol: enables interactions with bitcoin transactions via its bitcoin canister

Of the other 10, there are a number of reasons the protocols do not meet our minimum requirements to be a sidesystem. The majority are custodial systems. You can find our recommendations for these projects here.

If the other 10 projects do not implement a mechanism that would qualify them as a sidesystem, on testnet, by July 30th, they will be moved to the alternative chain category. In this category we will clearly state that these protocols have no direct connection to bitcoin.

Other protocols, on testnet, that launch without the necessary technical requirements to be considered a sidesystem will be immediately placed in the “alternative category”.

Liquid is not currently at risk of being moved because its federation members are public and it is denominated in BTC. However, this may change due to its functionaries not being public.

Sidesystems and softforks

In the event of a softfork, some sidesystems could become bitcoin native protocols (and L2s). The only protocols that could do this are rollups and client-side validated protocols. If bitcoin had more expressive scripting capabilities, then trust-minimized bridges would be possible. An example of this is being built out by the Bitcoin Wildlife community.

However, this is not the current state. We can only push projects towards being improved sidesystems. In the event that rollups, alternative rollups (aka validiums), and CSV protocols can be bitcoin native, we can establish further ways to review this nuance.

To finish

It’s been an interesting year researching this category. Lightning is still the only in production L2, Mercury Layer is a close second, and over 90% of BTC on alternative blockchains is held by centralized custodians.

The purpose of scaling through L2s is to ensure as many users as possible are able to access bitcoin in a trust-minimized, self-custodial manner.

Our research and data show that this is clearly not what is happening in practice. And even in protocols where users can use the system in a trust-minimized fashion, custodial solutions count for 80-90% of usage.

It’s time to start pushing projects to improve their trust assumptions.