Throughout history, money has fulfilled three critical functions for society; it has served as a store of value (wealth), medium of exchange, and unit of account. The types of money changed, but their functions remained largely the same. Broadly speaking, there have always been two schools of thought—one that supports credit money, or soft money, and the other that supports hard money. Credit money, like the fiat system today, is always someone’s liability.

The dollars or rupees you possess are the government’s liability. If the government defaults, your money will not be able to buy essential goods and services.

Hard money, on the other hand, is money that is not the liability of the government. For example, precious metals like gold do not lose value if governments default. On the contrary, their value is enhanced because of their perceived stability.

Bitcoin was the first successful digital implementation of non-sovereign hard money. In 2009, Satoshi Nakamoto released Bitcoin when the world had just witnessed a global financial crisis due to bad lending practices and unilateral interest rate decisions that impacted monetary supply. The mighty dollar lost more than 95% of its value over its lifetime. In his essay, Paradigm Shifts, macroeconomics stalwart Ray Dalio wrote about how central banks reduced interest rates in response to various crises and the impact they had on their respective economies.

Source – Paradigm Shifts

The chart above shows how interest rates have fallen across the developed world since the 1980s. At the same time, the monetary base grew as a percentage of the GDP. As a result, the gross output did not grow at the same pace as the money supply. When the money supply increases rapidly, with or without a lower rate of household income growth, it can lead to higher inflation, higher cost of living, increasing debt burden, and greater income inequality. The high inflation environment that we are currently in is a result of the policies central banks have adopted.

This scenario is where the use cases for precious metals like gold come to the foreground. Government intervention related to the supply of gold is minimal. With lower government influence, the gold supply is more predictable than fiat currencies. This high predictability has allowed the metal to retain its value over decades and become a storehold of wealth.

Bitcoin was born as peer-to-peer electronic cash. Over the years, as with many innovations, it deviated (or at least expanded) from its original goal of electronic cash and evolved into digital gold.

In 2018, I came across an interesting analogy between cities and blockchains. As blockchains are disconnected from the outside world, they are more like closed islands. Each island has its own priorities and character that reflect technically and socially. The Bitcoin island always preferred security and decentralisation over other aspects, like speed and programmability.

Decentralisation is a broad term with nuances. Balaji Srinivasan suggested a way to measure it by breaking a blockchain into its subsystems, like mining, client, developer, exchange, nodes, and ownership. He proposed that overall decentralisation can be arrived at by measuring the Gini¹ and Nakamoto² coefficients of the subsystems.

According to many Bitcoiners like Jonathan Bier, we can look at decentralisation from the lens of how difficult it is for users to verify transactions on their own. This difficulty in verifying transactions is why Bitcoin blocks are small (up to 4 MB). For blockchains to offer general purpose programmability (not just on paper but in practice), developers must curate a few things.

Firstly, the language or the system they use should be Turing complete. ‘Turing complete’ refers to a system’s ability to perform any computation that can be expressed algorithmically, given enough time and memory.

Second, the gas metering needs to be optimum. Gas metering refers to how the system is designed to measure the cost of resources (e.g., the maximum gas spent per block and the gas consumed by different operations). Ethereum’s Solidity is a Turing complete language, but it is often limited by gas. Bitcoin’s scripting language is intentionally limited to ensure higher safety. Moreover, as Matt mentions, it is a low-level stack-based language rife with unfixed bugs from Satoshi’s days, and missing key operators keep it from being very useful.

Subscribe

Islands like Ethereum and Solana have evolved to be connected with each other, developing interactions they arguably benefit from. However, while the Bitcoin island remained steadfast with its aim of security, it has not incorporated any changes to its infrastructure that would allow easier movement to other islands. The Bitcoin island only allows residents to hold, transfer, or trade their BTC for inscriptions and runes with a clunky UX.

With limited things to do, the BTC remained in coffers. Meanwhile, assets like ETH have had abundant opportunities to enjoy yield and passive income in the form of staking, restaking, lending, and so on. Because they developed new infrastructure, other islands have seen rapid modernisation while Bitcoin has remained antique but formidable.

Don’t get me wrong, Bitcoin’s conservative approach has ensured its security and decentralisation. More functionality usually produces complexity, with increased surface for attacks.

The Bitcoin island remains formidable but isolated. Other islands are connected with each other via stronger bridges.

The concept of separated islands evokes the history of my home, Mumbai. Once known as Bombay, it was originally composed of seven distinct islands. The fusion of these islands began in the 1680s and spanned centuries. Today, as I wander through the bustling metropolis, barely a trace remains of that former separation. The city feels seamlessly unified, its past fragmentation almost forgotten.

This transformation of Mumbai prompts an intriguing question: Could we witness a similar evolution in the Bitcoin landscape? Some teams are building towards it.

The Evolution of the Seven Islands of Mumbai. Source – Reddit

This article is about how some teams are building different ways for Bitcoiners to use their riches other than just holding them. I lay the foundation by explaining why we need better infrastructure, and then diving into different approaches taken by teams aiming to expand use cases for BTC. Finally, I mention how the ultimate vision is as much about a social consensus as it is about a technical one.

This is happening as teams are building different auxiliary islands to the Bitcoin island and finding solutions to modernise the Bitcoin island itself. A permanent overhaul of the Bitcoin island can only take place if there’s a social revolution among the islanders and they agree to make changes to its rules so that it can use bridges to other islands with the same confidence as using the island’s internal infrastructure.

Why better infrastructure?

Established blockchains like Ethereum, Solana, and even the upcoming ones like Monad are built with developers in mind. They are built as platforms for developers to build applications. These chains offer comprehensive ecosystems that support developers through various learning resources, tools, frameworks, and features. Satoshi built Bitcoin on the go. There isn’t a thoughtful API, and there’s little clear documentation for learning Bitcoin development.

There are three critical reasons to keep improving the network infrastructure – better UX, more financialisation, and scale payments.

Better UX will boost activity to bring in more fees

The Ordinals protocol, a way to leverage Bitcoin UTXOs and see individual Satoshis (the smallest unit of BTC) differently, brought about innovations like inscriptions (NFTs on Bitcoin). The enthusiasm around ordinals and inscriptions brought about the evolution of fungible standards like BRC-20 and runes. Inscriptions and runes gave Bitcoin an activity boost. The total number of daily transactions increased by 70% compared to BTC transfers alone.

These new ways of transacting on Bitcoin help boost the fees by ~40%. However, these new ways often spark intense debates within the Bitcoin community. One faction argues that Bitcoin should remain focused solely on enhancing its core function as a decentralised payment system. They contend that expanding beyond this scope could compromise Bitcoin’s security, simplicity, and effectiveness as sound money.

On the other side, proponents of a more flexible approach advocate for expanding Bitcoin’s capabilities to include non-payment use cases. They argue that this evolution is necessary for Bitcoin to remain competitive and relevant in the rapidly advancing blockchain ecosystem.

Is it enough? Not really. According to Token Terminal, Bitcoin miners have earned ~$109 million in fees in the last 30 days. Over the same period, applications like Uniswap and Lido Finance have raked in $90 million and $104 million, respectively. With the latest halving in April 2024, miners have received 50% less block subsidy. After the recent halving, the block reward (subsidy) halved from 6.5 BTC to 3.125 BTC per block. With this, the monthly tally of the miners’ subsidy cut comes to 13,500 BTC (3.12514430). At $66K apiece, this is $891 million, so the monthly fees are only about 12% of the subsidy loss.

Recent developments like runes are encouraging, but we need more. What are the challenges? Well, the UX on Bitcoin is nowhere near the likes of Solana or Ethereum L2s like Arbitrum. A swap takes a few seconds and a fraction of a cent in fees on Solana. However, if you want to trade runes on Bitcoin, you’ll have to pay a few dollars in fees and wait one block to confirm your transaction.

In addition to that, when you buy runes, you have to buy the listed quantity. The buyer cannot modify the number of runes to buy. Another drawback is that one rune cannot be exchanged for another, which is the way we can exchange USDC for MKR on Ethereum. A trader has to sell one rune for BTC and then buy another rune they desire. An additional step in between adds unnecessary friction in the UX.

The UX to trade runes is far from ideal. There are no ways to use BTC as collateral or lend it. You must take BTC out of Bitcoin L1 and put it onto other chains to use in financial applications.

Increasing the financialisation of BTC

Firstly, Bitcoin has a market capitalisation of close to $1.3 trillion at $66K per BTC. Just like gold, Bitcoin is outside money, which means that governments cannot manipulate the supply of Bitcoin. Although the exact size of the gold loan market is unavailable, some reports estimate it at $100 billion. So, one of the most important reasons for building applications on Bitcoin is to use native BTC as collateral to borrow stablecoins. Robust lending marketplaces will allow Bitcoiners to earn a yield on their BTC.

Take staking, for example. Other native assets like ETH and SOL have inherent use in staking to secure the network; ~27% of the total circulating ETH is staked across staking protocols, earning ~4% annual yield. Another ~4% ETH is staked in re-staking protocols and 67% of the circulating SOL is staked. Plus, ETH and SOL are both extensively used in their respective DeFi ecosystems as collateral assets.

Subscribe

Wrapped BTC (or WBTC), the most widely used version of BTC in different DeFi ecosystems has a market capitalisation of ~$10 billion, less than 1% of the total BTC in circulation. It shows the opportunity that exists in BTC financialisation.

Assuming a similar level of BTC gets used for staking or in DeFi as Ethereum, at ~30%, the amount translates to $390 billion. For context, all of DeFi, the total value locked in all other chains, is worth $101 billion. BTC can potentially be the most productive liquid asset. Right now, that potential is caged by intentional technical limitations.

Scaling BTC payments

The Bitcoin base layer has not been designed for throughput. If Bitcoin has to be the settlement layer of the Internet, we need faster transactions. As Mohamed Fauda puts it, there’s a limit to how many transactions can be posted using this. At a maximum block size of 4MB, Bitcoin can support 6.66 kbps (4 MB / 10 minutes) of data.

The Bitcoin network cannot currently handle high traffic. Users face a degraded experience around anticipated events like the Quantum Cats’ mint and runes launch. The bad UX is not limited to those who are trying to mint inscriptions but also includes those who are sending and receiving BTC.

Lightning Network (LN), the leading BTC scaling network, has had lacklustre adoption. The network’s capacity or liquidity stands at ~5k BTC. This is the amount of BTC locked across all lightning channels. It affects the network’s liquidity and how much BTC can be moved through it.

Why is this important? Let’s try to understand it using an example. Joel is raising $1 million to pay coffee plantation workers in India and he decides to use LN to receive donations. He can’t just spin up an LN wallet and accept donations. He needs to have $1 million in inbound liquidity. Inbound liquidity is the amount of BTC locked in a channel by your counterparty. Sid is one of Joel’s counterparties with $10,000 locked. Joel needs more counterparties like Sid, who have locked up an aggregate of $1 million to receive $1 million worth of donations. This represents a significant challenge for the network to scale as the inbound liquidity will always be constrained by the opportunity cost of the capital.

The challenges with Bitcoin development

Bitcoin is as much a cultural or social phenomenon as it is a technological one. Social consensus is the last line of defence. For example, the 21 million hard cap of supply can be amended by forking the code to add a tail emission of 1%. But for this change to take effect, all the miners would have to mine on this fork, and they are unlikely to do so. This is because the hard coded cap has been one of the major value drivers for BTC. There can be a perceived loss in value if that ceiling is broken. Miners are unlikely to mine on a fork that potentially loses value.

The technical effort needed to change the codebase will be rendered useless due to a lack of social consensus. The last time Bitcoin had a contentious fork was during the Block Wars in 2017. The network split into two, with Bitcoin implementing SegWit (explained later) and Bitcoin Cash, which increased the block size. At the time, most of the mining power chose to stay with BTC.

For something to be considered money or a store of value, it must not change very often. The leading reason why fiat money loses its purchasing power over time is that central banks often use their power to increase the supply. This unpredictability of unilateral central bank actions makes some currencies perpetually weaker. Bitcoin culture is such that it resists changes. Even something like Taproot, which is not contentious, took years to implement since the idea was born.

Bringing about the above changes is not just about changing Bitcoin. The Bitcoin base layer needs to be as simple as possible. Simplicity is critical for fewer attack vectors and greater stability. The idea is to execute complicated things like lending and minting stablecoins with BTC as collateral outside the base layer, like Ethereum’s L2s.

Bitcoin L2s?

What is an L2? It should;

• Provide layer 1 with sufficient data to validate and resolve disputes, if any.
• Not have security assumptions in addition to the base layer.
• Allow users to unilaterally withdraw their assets to the base layer or layer 1.

Since the current set of Bitcoin operational codes (opcodes) limit it from verifying any proofs, these conditions cannot be met. Thus, none of the chains claiming to be Bitcoin L2 can be called L2s.

Another aspect of what constitutes an L2 is to look at the security assumptions of that layer in reference to the security assumptions of Bitcoin. Every blockchain has some security assumptions, such as;

• The majority of the mining nodes are honest
• Nodes can independently verify blocks and reject invalid blocks
• Forks are resolved in favour of the longest branch of the chain, and so on.

The second layer, or L2, should not expand the set of security assumptions of the base layer on which it is built. For example, if the second layer has a centralised sequencer that has a monopoly on block production, users need to be able to contest block production at trivial costs. The L1 should be able to dictate to L2 that user funds be released as long as they are not spent. At this stage, these mechanisms are absent even in Ethereum L2s.

If we are strict about the L2 characteristics mentioned above, even some consensus Ethereum L2s like Arbitrum are not really L2s. Since the current set of Bitcoin operational codes (opcodes) prevent it from verifying any proofs, none of the chains claiming to be Bitcoin L2 can be called L2s. The Lightning Network is probably the only solution that fits the L2 definition. As a general term, this article refers to these solutions as Bitcoin extension layers.

The Bitcoin Layers’ Landscape

Broadly, putting BTC to use has two components – 1) use a bridge, since there’s not much to use on Bitcoin, and 2) create an environment or chain where the applications that let investors use BTC can reside.

To facilitate more use cases and scale, the new layers will likely make security assumptions over and above Bitcoin’s. Users wanting to use their BTC will want to accept the least number of security trade-offs. Ethereum’s scaling roadmap is a good reference to understand how the design space for scaling Ethereum evolved.

Over a few years, Ethereum realised rollups are how it will scale. At this stage, we still don’t know which approach is the best way to scale and make BTC more programmable.

Whether it is storing data or choosing the bridge design, projects make trade-offs between decentralisation, security, speed, and UX. Answers to the following questions make up the design space for projects or companies building extended Bitcoin layers –

• How do they implement the bridge from Bitcoin to the new chain?
• How do they store data (data availability)?
• How do they use Bitcoin L1 for settlement?
• Do they expect any changes to Bitcoin’s base layer to materialise their complete vision?
• What kind of execution environment do they choose?
• Does the extended Bitcoin layer promote the use of BTC for things like gas and staking?

Various teams are making different kinds of trade-offs to offer better functionality and scale to BTC holders.

Bridges

BTC on Bitcoin cannot move to other chains. There needs to be some infrastructure to take BTC to other chains. A typical bridge mechanism locks a user’s BTC on Bitcoin and mints an equivalent amount of the synthetic token representing BTC on a destination chain.

What is a typical locking mechanism? It means that a user who wishes to take their BTC from Bitcoin to any other chain sends it to a particular address on Bitcoin. The bridge operator controls this address. When the bridge operator detects incoming BTC, they mint equivalent synthetic tokens representing this BTC and send it to the address specified by the user on the destination chain.

The risk here is that if the bridge operator loses BTC on Bitcoin, the token minted on the destination chain will be rendered worthless. We witnessed this risk play out in the aftermath of the FTX collapse. SolBTC was the wrapped version of BTC operated by FTX/Alameda. It became worthless because FTX did not honour redemptions after it filed for bankruptcy.

So, everything a user does on the destination chain relies entirely on the security practices of how the bridge operator controls users’ BTC on Bitcoin. How users’ BTC is controlled determines the different types of bridges. There are three types of current designs in production.

Trustless bridges

These bridges are possible only when the L1 can verify proofs submitted by the L2. In the case of Bitcoin, this is not possible as it cannot understand anything happening outside of it.

Trust-minimised bridges relying on economic security

The next best alternative for BTC bridges is to have multiple public parties handling peg-ins and peg-outs. These parties secure users’ BTC on Bitcoin and mint/burn synthetic BTC tokens on other chains. One such implementation is Threshold Network’s tBTC, which works on the honest majority.

This means it needs a majority of the operators running Threshold Network nodes to agree before operators can perform any actions on users’ BTC. Instead of centralised intermediaries, tBTC randomly selects a group of operators running nodes on the Threshold Network to secure BTC deposited by users.

Who gets to be a node operator on Threshold Network? The network has a governance token, T. While T is used for governance, a minimum of 40,000 T needs to be staked in order to become a node operator. As of 25 June 2024, 139 nodes are active on the network.

The tBTC Beta Stakers programme is designed to decentralise the node network progressively. Beta stakers can delegate their stake across five professional node operators—Boar, DELIGHT, InfStones, P2P, and Staked. Beta stakers are expected to run the node for at least 12 months with active participation. For example, they need to be highly responsive towards network upgrades, ideally upgrading their nodes within 24 hours of the notification.

Whenever a user requests to mint tBTC, a new deposit address on Bitcoin is generated. This address is dedicated to the user and controlled by nodes on the Threshold Network. Users can request to mint tBTC on networks like Ethereum, Arbitrum, Optimism, Mezo, and Solana.

They need to provide two addresses—a recovery address on Bitcoin (this is the address where their BTC is returned in case there are issues with the minting process) and a destination chain’s address where they wish to receive tBTC. Once the request is made, the user must deposit BTC to the address generated and await a guardian to confirm their deposit. Upon confirmation, the minter sends tBTC to the users’ address on the destination chain.

The network has ~3,500 BTC, or over $200 million, in locked value.

With what Bitcoin opcodes can do, trust-minimised bridges are arguably the best possible bridge implementation at the moment. Trust-minimised bridges can vary in implementation depending on how the multisig is designed. Threshold Network’s tBTC, Stack’s upcoming sBTC implementation, and Botanix’s spiderchain are examples of trust-minimised bridges.

Custodial Bridges

In this design, a centralised provider locks users’ BTC on Bitcoin in addresses maintained by the custodian. WBTC by BitGo is the most widely used way to bridge BTC to other chains. Over 150k BTC is bridged using WBTC. The current distribution of WBTC looks as follows.

BitVM

While the three types of bridges were already live, Robin Linus published the BitVM whitepaper in late 2023. BitVM proposed a new way to express Turing complete smart contracts on Bitcoin. A machine or a system is said to be Turing complete if it can execute any computation given enough time. As mentioned earlier, Bitcoin is Turing incomplete by design, and BitVM proposed a way to overcome this without making any changes to the existing opcodes. It also proposed a supposedly trustless bridging mechanism.

The core idea of BitVM is to verify a ZK proof on Bitcoin optimistically. As long as there’s no objection to transaction execution, it is assumed to be correct. This system typically works under the assumption that there is at least one honest verifier. If the execution is incorrect, at least one honest verifier is supposed to challenge it.

So, as long as the ZK proof is not challenged, everything is fine. If there’s any objection, the challenger and the prover enter a challenge-response or bisection game on-chain. The definition of a bisection game is beyond the scope of the article but is linked for interested readers. But a consequence of the bisection game is an increased load of on-chain transactions.

Liquidity management is another significant drawback of the early versions of BitVM. When a user withdraws from the bridge, the system completes a partial withdrawal, and the bridge operators must front the liquidity. Operators get reimbursed from the bridge later. As the amount locked in the bridge increases, operators must maintain more liquidity to honour withdrawals. This puts a strain on operators and makes the design highly capital-inefficient.

Let’s say, on average, operators need to keep 10% of the bridge TVL in liquid funds at all times. If the bridge TVL is $10 billion, operators need to maintain liquidity of $1 billion at all times. As the bridge attracts more liquidity, operators need to keep more BTC inventory on hand. Tyler White and Rijndael have written an @twhittle/bitvm-bridges-considered-unsafe-9e1ce75c8176">excellent article explaining the issues with BitVM.

Subscribe

Execution Layers

The next piece of the puzzle in making BTC useful is designing the chain that facilitates this use with the best possible UX. Multiple considerations go into how developers want to design this chain.

• Execution environment – Should it be an Ethereum Virtual Machine (EVM) compatible chain? Being EVM compatible has its advantages, such as,
  • Several years’ worth of available tooling, such as wallets and bridges to other EVM chains, is at the disposal of developers.
  • The UX is familiar to users.

Ethereum’s L2s have already benefited from EVM compatibility. L2s like Arbitrum and Optimism that were EVM compatible could quickly gather users and applications already on Ethereum. In contrast, L2s like Starknet that are not EVM compatible struggled to gain adoption.

However, EVM has its disadvantages, too. Because EVM executes transactions serially, parallel processing is not possible. Newer execution environments, however, like the Solana Virtual Machine (SVM) and the upcoming Monad, allow parallel processing.

• Data availability – Similar to Ethereum, a few rollup solutions are also emerging in the Bitcoin landscape. Depending on how and where they store data, rollups have multiple flavours. Some store state differences (differences in two states of the chain after executing a batch of transactions) on the L1, along with validity proofs. Some store compressed transaction data on the L1, and some only store the validity proof on the L1 with transaction data on a separate layer.

Some chains like Stacks use Bitcoin as a checkpointing mechanism. Block time on Stacks is much lower than Bitcoin’s. Stacks post data from its blocks between two Bitcoin blocks onto every Bitcoin block.

Execution layers can post transaction data on Bitcoin in the form of inscriptions. Recall the 6.66 kbps bandwidth of the Bitcoin network. If I take 10 bytes (10 bytes is generous typically; this would be ~20 bytes) as the size of a compressed transaction, a Bitcoin block can include a theoretical maximum of ~600 compressed transactions. However, this maximum is almost impossible since 4 MB blocks are a rare phonemon and it is even rarer that the entire 4 MB space is available for inscriptions.

The block size depends on the mix of SegWit and non-SegWit transactions. SegWit, short for Segregated Witness, separated or segregated transaction data from witness data. The idea was that not everything stored in a block is of equal value. Instead of limiting the block size to the traditional 1 MB, SegWit proposed a new limit of 4 million weight units. So if a block had all non-SegWit transactions, the limit would be 1 MB. But if it had all SegWit transactions, it could be a 4 MB block.

Several teams are building layers of Bitcoin to tap into BTC’s massive liquidity. For this article, we looked into six different teams that make different trade-offs and have interesting designs. We briefly describe how they work, their development stage, and their traction so far.

Babylon

Babylon focuses on expanding the use of BTC as a staked asset. It brings in a different approach than the rest of the Bitcoin layers (the so-called L2s) in the form of remote-staked BTC. What this means is instead of locking BTC on Bitcoin to mint a synthetic version on a different layer, Babylon introduces the following mechanism;

1. A user locks their BTC in a self-custodial vault by creating a UTXO that can be spent only once, either when the pre-specified time (staking period) has passed or when the user burns their staking UTXO through their special EOTS (extractable one-time signature).
2. After confirming the staking transaction, the user can use their EOTS to validate blocks on PoS chains in the Cosmos ecosystem to earn a yield.
3. If the user behaves honestly, they can unlock their BTC at the end of the staking period or submit an unbonding transaction to Bitcoin.
4. If dishonest behaviour is detected, the user’s EOTS is revealed to the public. How is this detected? Babylon’s vigilantes ensure at least one honest operator. It is a program suite that acts as a relayer of data between Bitcoin and Babylon. The submitter program submits Babylon checkpoints to Bitcoin using OP_RETURN. The reporter programme scans Babylon checkpoints and reports them back on Babylon. If an anomaly is detected, anyone (called a slasher) can use the public EOTS key and submit a Bitcoin transaction to claim the malicious user’s stake.
5. An obvious question is why users can’t use the key themselves and get the stake back. The answer probably is that when the miner sees this transaction and if someone else initiates the same transaction, the miner will pick up a transaction with a higher fee. For example, if the stake in question is 5 BTC, the slasher can share even 4.99 BTC with the miner and be profitable. In this case, the miner keeps most of the profit instead of the slasher. However, the malicious user loses most of their stake, either to the slasher or the miner.

Although Babylon provides an interesting approach to expanding the use of BTC, the mechanism is fairly complex. For example, slashing has yet to be successfully implemented on many PoS chains, even though some of the have been live for years. Additionally, although Babylon can utilise remote staking so that BTC can be used to secure other PoS chains, it needs a bridge to enable other BTC use cases like lending.

Build on Bitcoin (BOB)

Better known as BOB, Build on Bitcoin is ironically an Optimism-based rollup that settles on Ethereum as of June 2024. It claims to be a Bitcoin-aligned Ethereum L2. BOB will launch in four phases;

• Phase 1 – OP stack rollup. It is purely an Ethereum rollup in this phase. Fraud proofs are not yet live on the mainnet. Fraud proofs are a mechanism that allows anyone to challenge the validity of transactions included in a rollup batch.
• Phase 2 – Ethereum rollup with Bitcoin’s security. In this phase, BOB will utilise Bitcoin’s merged mining. Merged mining allows miners to secure (or mine on) multiple chains along with Bitcoin.
• Phase 3 – Optimistic Bitcoin rollup via BitVM. BitVM is not live currently. As it goes live after improving upon the current version, BOB will start settling on Bitcoin using BitVM.
• Phase 4 – Zk rollup on Bitcoin. After Bitcoin accepts an opcode that allows it to verify Zk proofs, BOB will use Zk proofs to settle on Bitcoin.

As of June 17, 2024, BOB has a TVL of ~$60 million, with Sovryn DEX contributing ~$20 million.

Botanix

The Botanix team brought about a significant innovation: the Spiderchain. What is Spiderchain? It is a rolling multisig of orchestrator nodes on Botanix. Let’s break it down. As we mentioned earlier, an L2 needs a bridge and a chain that executes transactions. An orchestrator node keeps users’ funds secure on Bitcoin and mints and burns synthetic BTC (on the EVM layer) for users. Orchestrators run Bitcoin and Spiderchain EVM (Botanix) nodes.

Let’s say there are N orchestrator nodes on the network. M (<N) orchestrators are randomly chosen for every Bitcoin block to secure incoming BTC. Every epoch, new keys are generated with a new set of orchestrators. While bridging out, the last BTC is chosen first to ensure that older and established orchestrators control older coins.

Botanix’s chain is EVM-compatible and secured by a PoS consensus mechanism. Along with securing BTC on Bitcoin by participating in a rolling multisig network and facilitating minting and redeeming synthetic BTC, orchestrators also participate in the EVM chain’s block building. They post the root hash, a compact version of the Botanix EVM transactions, as an inscription in Bitcoin.

Readers must note that merely posting data on Bitcoin doesn’t mean settlement. The difference here is that the data that external chains like Botanix post in the form of an inscription gets stored in a place not validated by Bitcoin nodes (miners). The Bitcoin protocol is entirely unaware of this data. Thus, it cannot be determined whether the transaction data posted in the inscriptions is correct.

As of June 2024, Botanix EVM and Spiderchain are in the testnet phase.

Citrea

Citrea is building a Zk rollup on top of Bitcoin. What does ‘on top of Bitcoin’ mean? Just that it intends to use Bitcoin as the data availability layer. It says that the most secure and incentive-aligned way to scale Bitcoin blocks is to shard the execution with on-chain verifiability and data. Sharding the execution means breaking execution into smaller pieces.

Citrea then aggregates shards or batches of transactions and posts the state differences between the two transaction batches on Bitcoin along with a proof known as the validity proof. But the problem is that Bitcoin doesn’t have the capability to verify any proofs at the moment. The final form of Citrea will have to wait until Bitcoin has opcodes that allow it to verify zk proofs.

In the meantime, it will use a BitVM implementation as a stop-gap arrangement for proofs and to bridge BTC in and out of the rollup. Naturally, Citrea inherits BitVM’s drawbacks mentioned in the previous section. In the future, as BitVM improves, Citrea will improve its bridge functionality.

Source — Citrea

Citrea is in the testnet phase as of June 2024.

Mezo

Mezo touts itself as the economic layer of Bitcoin. It does not call itself a Bitcoin L2. It uses Threshold Network’s tBTC bridge (mentioned above) to bring BTC in and out of the EVM chain, Mezo.

Mezo is being built by the same team that has built products like tBTC, Fold, Keep, and Taho. The team has been building applications around Bitcoin for years. Mezo’s aim is simple: to expand the use cases of BTC. It does so via three mechanisms;

1. Letting Mezo users earn a yield by staking BTC to secure the network.
2. Letting users pay gas fees in BTC, which is distributed to veBTC and veMEZO stakers.
3. Building an end-to-end BitcoinFi experience.

What do BitcoinFi and the economic layer even mean? Most new chains, including the EVM ones, rely on existing UX — the same wallets, bridges, etc. Revamping the UX is almost never a priority. Mezo is curating the whole UX from the ground up, something I have rarely seen. It includes;

• A native stablecoin (mUSD) backed by BTC so that users don’t have to bridge from other chains.
• A long-tail lending protocol guaranteed by BTC.
• A fully integrated on and off-ramp via Fold.
• An integrated wallet experience via Taho.

Combining all of these applications creates a unique, end-to-end BitcoinFi experience:

Mezo is based on the Cosmos SDK. It uses Comet BFT for consensus.

CometBFT is software for securely and consistently replicating an application on many machines. By securely, we mean that CometBFT works as long as less than 1/3 of machines fail in arbitrary ways. By consistently, we mean that every non-faulty machine sees the same transaction log and computes the same state. Secure and consistent replication is a fundamental problem in distributed systems; it plays a critical role in the fault tolerance of a broad range of applications, from currencies to elections to infrastructure orchestration and beyond. — Source: CometBTF docs

It consists of two components—a consensus engine and a generic application interface. Based on the Tendermint core, the consensus engine is responsible for block production, validation, and finality. Tendermint was one of the first proof-of-stake consensus designs. It offers @learnwithwhiteboard_digest/what-is-byzantine-fault-tolerance-bft-in-blockchain-explained-cb06a12559be">Byzantine Fault Tolerance (BFT) consensus and can tolerate up to one-third of malicious nodes.

The application interface, Application BlockChain Interface (ABCI), separates the consensus engine from applications. A major advantage of ABCI is that since consensus and applications are separated, developers are not mandated to build applications in the same language in which the consensus engine is built.

The interface acts as a medium that delivers transactions to applications for execution. This capability makes the system more modular and helps target more application developers. Initially, Mezo will only be compatible with the EVM runtime.

Mezo’s economic design is such that, as it gains prominence, BTC holders may benefit directly or indirectly. They can either stake BTC on Mezo and earn staking yield or, if they choose to keep holding their BTC on Bitcoin, they will derive some benefit from BTC being taken out of circulation (to pay for fees on Mezo).

Mezo has a dual-staking model, as shown in the image below. Validators on the network can stake both BTC and MEZO (the native token of Mezo Network). By staking BTC and MEZO, validators get veBTC and veMezo, respectively. The ‘ve’ stands for validator escrowed, and these tokens are typically locked in a smart contract. Validator escrowed token holders have governance rights, and network rewards and fee revenue are shared with them.

The longer an asset is locked, the more ve-tokens are given out. veBTC stakers earn BTC, and veMEZO stakers earn MEZO rewards. A part of the MEZO reward can be burned to grow the BTC treasury.

Yield is one of Mezo’s core offerings because the fees paid by users are paid to validators who stake BTC. Mezo is set to further expand the scope of BTC staking by offering liquid staking with Acre, Mezo’s sister project. When a user deposits BTC into Acre, they get a liquid staked token, stBTC, in return. Deposited BTC is used across chains and DeFi applications. Yield generated through these activities accrues in stBTC, which is 1:1 redeemable for BTC.

Source – Acre blog

With over a trillion-dollar market capitalisation, BTC is not even scratching the surface of the lending market. The distribution of WBTC used in the lending markets is shown in the image below. It shows that the amount of WBTC used in the top three lending applications decreased from ~50k to ~23k between July 2023 and June 2024. The decline of total WBTC in lending applications can be attributed to a 48% decline in WBTC supply, from 285k WBTC in May 2022 to just over 150k WBTC now. This decline is primarily due to the market realising the risk of centralised parties amidst the aftermath of Luna, 3AC, and Alameda.

In its first phase of the launch, Mezo has already started accepting BTC deposits with three lock-up periods: two months, six months, and nine months. Deposits attract points in the form of a HODL score. One BTC generates 1000 points daily, and a multiplier is associated with lock-up periods. A higher lock-up period implies a higher multiplier. Users can also deposit other assets like USDe, USDC, and USDT to get a boost on their BTC deposits. As of July 2024, Mezo’s TVL stands at $135 million.

In addition to rewarding holders, Mezo will share a portion of their fees with the Bitcoin core protocol.

Stacks

Stacks, formerly known as Blockstack, recently rolled out its much-awaited Nakamoto upgrade aimed at solving issues like constant forks and slow transactions before the upgrade. Stacks works on proof of transfer (PoX) consensus.

So, Bitcoin miners interested in producing blocks on Stacks need to send some BTC. A miner, say, Alice, is chosen randomly to produce blocks on Stacks. The BTC from this miner is given to users who stack (lock/stake) STX, the native token of the Stacks chain. This is interesting because although it’s a small yield, it is in BTC. On most chains, the yield is offered only in the chain’s native token.

Once chosen, Alice can produce Stacks blocks until the end of the Tenre (next Bitcoin block). As the miner produces Stacks blocks, they are shared with signers for validation. Once more than 70% of the signers accept the Stacks block, it is accepted on the Stacks network. Let’s assume that Alice produces 10 Stacks blocks before the next Bitcoin block is mined and that Bob wins the subsequent tenure to produce Stacks blocks.

Bob takes the hash of the first Stacks block that Alice produced on Stacks and adds it to his block commit transaction to the Bitcoin chain. Stackers detect this transaction. They include a tenure change transaction on Stacks that includes the last block’s hash, the 10th block in this case, that Alice produced on Stacks. This way, Bob understands that he has to build on Alice’s previous block, #10.

Although these are the early days of development for Bitcoin layers, here’s a comparison of the above-described chains. It considers chain design, bridge design, and the dollar value secured.

We must mention that in addition to the teams mentioned above, many others, such as Alpen, Bison, BitLayer, Rootstock, SatoshiVM, and Soveryn, have been building extended layers of Bitcoin. Readers can find the list here.

The relationship between L2s and L1

L2s help the L1 with two things – scale and cost. They provide users with an avenue to transact much more cheaply without giving away too much security (or any security in the case of L2s with non-custodial, trustless bridges and no additional security assumptions).

Take Ethereum L2s as an example. As per Token Terminal, in the second week of June 2024, Ethereum supported 7.1 million transactions for $10.6 million in revenue. The cost per transaction for users comes to ~$1.5. At the same time, five L2s—Arbitrum, Base, Blast, Optimism, and Polygon—supported over 70 million transactions for $2.75 million in fees. That is $0.03 per transaction.

We can argue about the quality of transactions, including whether they are bots or the transaction value, among other things. However, the fact is that Ethereum couldn’t support that many transactions.

However, a drawback of this is that L1s are no longer directly connected to their customers or users. In the traditional world, it is generally the businesses closer to end users that capture a major chunk of value. Amazon is an excellent example. Its enormous distribution allows it to have the upper hand over suppliers and manufacturers.

Dollar Shave Club disrupted the razor industry by selling directly to consumers via a subscription model, eliminating traditional retail channels. This allowed them to price products at a lower point and retain most of the value rather than sharing it with the entire supply chain.

It is usually a bad idea to add another layer between you and your customer. Why are L1s going down this road, then? By adding L2s to the mix, L1s are not losing customers. They are introducing a B2B mix into a business model that was previously strictly B2C. But there can still be a concern— do L2s get to capture most of the value? Do they pass on enough fees to L1?

Luckily, Ethereum has been down this road over the last three years, and we can observe the impact of L2s on Ethereum’s value capture. There are two ways to understand whether L2s have been predatory to Ethereum.

1. The first is whether Ethereum lost revenue to L2s. We can inspect this by examining how Ethereum’s revenue share has changed in the Ethereum ecosystem’s revenue. The following chart considers the revenue of Ethereum and five leading L2s. Ethereum consistently makes up 90%+ of the revenue stream.

1. Another way is to see the market capitalisation or price. Because value capture is almost always reflected in prices, ETH makes up ~95%+ of the total market value of the Ethereum ecosystem, considering its top 10 L2s by market capitalisation.

1. Ethereum could not have supported so many transactions, yet it still captures 90%+ of the ecosystem’s value, suggesting that L2s have been the correct step forward for scaling Ethereum. As long as L2s settle on L1, healthy competition among L2s for the L1 blockspace bodes well for the health of the base layer.

What’s next?

Think of the island analogy again. When it comes to real L2s, the two islands must collaboratively build a bridge. But without the Bitcoin islanders’ internal consensus, that’s impossible. What’s happening right now is those who want to be L2 islands to the Bitcoin island are trying to ensure infrastructure as a stop-gap arrangement.

So once Bitcoin islanders agree that they need to bridge to other islands for their growth, L2 islands are ready. Until then, what matters is that instead of trying to find more complex ways to bridge and create L2s, the focus needs to be on using what has worked and using infrastructure that has already been battle-tested.

How different projects are modernising the Bitcoin island and readying the bridge infrastructure to connect with other islands.

Everyone is aware of how Bitcoin islanders are set in their ways and take island security very seriously. Any changes to the island are thoroughly debated. Anyone who wants to suggest changes to Bitcoin can draft a Bitcoin Improvement Proposal (BIP). After informal debates on various forums, the author takes in the feedback and makes changes to the BIP. A committee of islanders then gives a number to the BIP, which is when it becomes official.

Some islanders understand the importance of cautiously modernising the Bitcoin island. Teams like Botanix, Taproot Wizards, and Thesis are laying the groundwork for adding opcodes to expand Bitcoin’s programmability. BIP-420 (also known as OP_CAT) by Ethan Heilman and Armin Sabouri will bring a plethora of exciting possibilities to Bitcoin. CAT stands for concatenate. It is an opcode that was a part of the original Bitcoin opcodes but was redacted by Satoshi due to security concerns that have now been alleviated as the Bitcoin execution environment has evolved over the years.

The opcode allows two pieces of data to be joined together. It unlocks numerous possibilities from custom transaction types like dynamic escrow systems, smart contracts like atomic swaps, different DeFi applications, and greater interoperability with external chains.

Teams like Starkware have already suggested that OP_CAT can bring STARK verification to Bitcoin. This means that Bitcoin can verify Zk proofs, thereby enabling rollups. This design paradigm not only allows general-purpose designs on Bitcoin but also improves its scalability, which it desperately needs.

Other designs by the Taproot Wizards team, like CATVM, are already in the works. This design will use OP_CAT to create trustless bridges. Unlike the current BitVM design, CATVM does not have liquidity requirements. CATVM will enable decentralised trading of ordinals and runes with a UX that is as good as other chains.

Segwit paved the way for Taproot, which was, in turn, critical for ordinals. Ordinals and inscriptions made BRC-20 and runes possible. Recent enthusiasm among Bitcoin developers suggests growing support for achieving social consensus on BIP-420. It also helps that it will be backwards compatible, so the network doesn’t need a hard fork to activate it. We are excited for it to go live and witness a new era of genuinely Bitcoin-native programmability.

After a long time, there has been a surging developer interest in Bitcoin. All the independent projects building around Bitcoin are like small modern islands around the mighty Bitcoin island. With BIP-420, there will likely be ways to fuse these islands together to make one prosperous and modern island.

With all the changes happening to Bitcoin, I hope for a future in which we will be able to use BTC in different financial applications with little knowledge of the layers beneath. The integration of Bitcoin layers will be as natural as navigating through Mumbai today, where we are completely unaware the bustling metropolis was once seven separate islands of Bombay.

Disclaimer：

1. This article is reprinted from [Decentralised.co], All copyrights belong to the original author [Saurabh Deshpande]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.