Introduction

Bitcoin, a peer-to-peer payment system without a middleman, has existed for over 15 years. Bitcoin blockchain was designed in such a way so that Bitcoin is optimized as a "hard, sound" money system. Unlike Ethereum and many subsequent blockchains, Bitcoin does not include Turing-complete smart contract functionality. Moreover, the community historically did not opt for changes at protocol level to enable such a feature at the base layer. However, efforts to expand the Bitcoin ecosystem in terms of scaling and capabilities have never ceased. The development of a second layer or sidechain, such as the Lightning Network, Liquid Network, Rootstock, Drivechain and protocol upgrades like Segwit and Taproot indicate a desire to extend Bitcoin beyond a secure digital asset.

On January 20, 2023, Casey Rodarmor launched the Ordinals software on the Bitcoin mainnet. Although non-fungible tokens (NFTs) on Bitcoin are not a new concept, with Colored Coins and CounterParty allow for asset issuances and has existed for over a decade. Ordinal NFTs, however, feature a fundamentally different architecture. They do not exist on a separate layer but are entirely native to the Bitcoin blockchain. Ordinals order sats to create the non-fungibility essential for NFTs. The "inscriptions" are essentially the content of the NFT, similar to the "metadata" of traditional ERC-based NFTs.

On March 8, 2023, Domodata introduced the concept of BRC20 and deployed $ORDI, which sparked new developments in the BTC ecosystem. In this piece, we (Vamient) would like to shed some lights on the new concepts and projects of the Bitcoin ecosystem that we believe will play a significant role in 2024 and beyond.

Bitcoin Landscape Q1 2024. Credits: Sora Ventures

Runes - new standard of token on Ordinal

Ordinal enables the inscribe of any arbitrary data to individual sats. There are many different methods of inscription, each with its unique standards and advantages. The most popular standard for fungible token is BRC-20. BRC-20s are based on inscribing JSON data, a text-based data format, onto individual Sats via the Ordinal Protocol to create fungible tokens. Currently, BRC-20s dominate Bitcoin Ordinal, with a total of 4000 BTC paid in fees for minting to date.

However, as BRC-20 is not designed based on UTXO, it can result in higher transaction fees and network congestion during periods of high activity. In September 2023, Casey - the original Ordinals software creator - introduced Runes, a new token standard for Ordinal.

Runes utilizes Bitcoin’s Unspent Transaction Output (UTXO) model, allowing it to be minted, transferred, and updated on Bitcoin. The primary distinction is that Runes includes a specific number of Output in its script data. This makes raw data easier to read on the blockchain and enables it to store all information directly on the Bitcoin blockchain.

The protocol message contains a second data push that signals an issuance transaction, which is decoded into SYMBOL - the token's unique identifier and DECIMALS - recording the token's decimal precision. Any additional number would deem the message invalid.

Unlike other token standards that link token balances to wallet addresses, Runes stores them in the UTXO itself. When a new token is created, its supply, symbol, and decimal places are defined in the issuance transaction and assigned to a specific UTXO, whose acts as the balance tracker. Upon token transfers, the UTXO would divide itself into smaller ones, each recording the transfer amount.

Runes offers a unique ticker symbol service. Once a ticker name is registered, it becomes permanent to prevent duplication and ensure clarity. Despite the official launch of Runes being scheduled for April at block 840,000, various projects will compete to etch the first $RUNES token. To avoid this, Casey, the creator of Runes, suggested that the first 1-10 Runes, numbers 0 through 9, may be pre-set and open to everyone. This approach ensures a fairer token distribution for all participants. At this moment, as Runes protocol is still on nascent stage, here are some notable names in this particular ecosystem:

RCIS: 21,000 RCIS were airdrop to Ordinal users, by holding RCIS holder can pre-mine $Runes token when it launch and $Runes will be allocated to your address until the supply is fully allocated.
Rune Alpha: all in one platform that help minting, launchpad Runes standard. It also has marketplace built inside and the explorer

Other token standards

In addition to BRC-20 and Runes, there are several other token standards being proposed and gaining adoption:

SRC-20

The SRC-20 token standard is developed based on the Bitcoin Stamp theory. It differs from the BRC-20 token standard as it uses UTXO for data storage, enabling permanent storage on the blockchain. However, the downside is the expensive minting fee, which is approximately 5-10 times higher than the BRC-20.

CRBC-20

The CRBC-20 token standard leverages the ability of Inscription envelopes to store arbitrary data directly. This significantly reduces the cost of inscriptions and simplifies the indexing process, making CRBC-20s a more affordable and faster alternative to BRC-20s.

Atomicals

Similar to BRC-20, the ARC-20 standard also supports basic functions such as deploy, mint, and transfer. However, the fundamental designs of ARC-20 and BRC-20 differ. In Atomicals, ARC-20s are treated as first-class citizens, use sat as the unit of account, and include a built-in ticker name service. A decentralized minting operation, known as DMINT, is also provided. The ARC-20 token standard is built on the UTXO model and uses ElectrumX as an indexer, allowing anyone to run their own Electrum server and access indexes of the Bitcoin blockchain.

TRAC

TRAC is developing an ecosystem to support various Bitcoin use cases. Within this ecosystem, TAP is a token standard that facilitates features such as token staking, swapping, and liquidity pools. This standard enables the creation of DeFi applications and gaming on TRAC. Another token standard, PIPE, has similar functions to BRC-20 but is based on UTXO. PIPE is primarily focused on digital arts and collectibles.

TRAC Ecosystem. Source: https://medium.com/trac-systems/trac-ecosystem-ff99787585d4

BitVM

Bitcoin's Scripting language is not Turing complete, meaning that implementing smart contracts directly on Bitcoin is impossible. This is because Bitcoin was initially designed for secure value transfers, not complex computational tasks. Adding layers to facilitate smart contract functionality introduce additional trust assumptions and risks, plus consuming substantial block space, leading to increased gas fees. Proposals to add computation to Bitcoin, which would require a soft fork, were historically not gain enough popularity and faced too much backlashes from the community to get approved.

In October 2023, Robin Linus from ZeroSync introduced BitVM, which allows computation on the Bitcoin layer without needing consensus changes. Essentially, BitVM performs computation off-chain and confirms state changes on-chain using fraud proofs. Code written in any programming language is converted into a binary circuit by a Prover and Verifier. The prover commits to that circuit in a Taproot address which has a leaf script for every logic gate in the circuit. Additionally, they pre-sign a sequence of transactions, enabling a challenge-response game between the prover and the verifier later upon dispute.

During this challenge window, the verifier randomly checking each input and output at a circuit gate according to the pre-sign transactions sequence during the setup stage. If the Verifier proves fraud by the Prover, they can claim the Prover's fund. This interactive process stops when either the pre-sign sequence of transactions has been all completed, or one of the two parties stop engaging, which results in the other one winning the challenge. The verifier can also slash equivocation immediately in the case the prover ever reveals two conflicting values. This approach enables the final proof to be verified on-chain without requiring consensus changes.

BitVM's Challenge-Response Transactions. Source: https://www.gate.io/learn/articles/a-simplified-interpretation-of-bitvm-how-to-verify-fraud-proofs-on-the-btc-blockchain/1864

BitVM increases expressiveness and introduces many new use cases for the Bitcoin base layer, but there are still several limitations to be addressed. At the time of writing, it's difficult to establish a universal rule for verification on BitVM. Instead, each BitVM contract sets its own rules and allows only parties within a state channel to engage in a smart contract. Additionally, BitVM requires the conversion of coding language into NAND circuit construction, which is both intricate and inefficient. Finally, Proposers and Challengers need to generate interactions off-chain repeatedly, which is complicated to design and optimise in real practice.

Albeit still being on such infancy stage, many developers are collaborating to improve BitVM. They've resolved several issues and enabled numerous use cases. To stay updated on the latest BitVM development, we suggest the interested parties to join this group: https://t.me/bitVM_chat.

L2s war, but on Bitcoin

Bitcoin is one of the most robust peer-to-peer networks, supporting a trillion-dollar economy. Any changes to the Bitcoin base layer must be carefully considered and accepted by majority of node operators before implementation. Since the launch of Ordinal, Bitcoin as an ecosystem has garnered increased attention. The fee that users pay to miners to include their transactions on the BTC network has grown tenfold year-over-year, making Bitcoin one of the top three networks where users pay the most fees.

However, the developments don't stop there. According to a report by Electric Capital, over 40% of Bitcoin developers are working on Bitcoin Layer 2 solutions. Some of these have been in development for several years. Early-stage examples include the Lightning network, which are state channels, and side chains like Liquid Network, RSK and Stack V1. Despite the progress, there are still some certain missing pieces lacking for an ultimate version of Bitcoin Layer 2 - especially for rollup, the type of Layer 2 that is popular in the Ethereum ecosystem and is considered the best form of Layer 2 for scaling without sacrificing security of the base layer.

For a L1 to secure a L2, it needs to verify the complete state of that L2. Currently, Bitcoin's base layer lacks the ability to verify proofs from L2s. Although there have been proposals to facilate zk proof verification on Bitcoin's base layer, it’s generally difficult to achieve consensus among the community and would require a soft fork. An alternative approach is to use BitVM, which extends Bitcoin's functionality through off-chain program execution and can verify state change provide by roll up with the assurance that execution can be challenged on-chain via fraud proofs. However, the cost of verifying fraud proofs can be extremely high in BitVM (a parallel can be drawn to call data to L1 in Arbitrum and other Ethereum L2s).
To reduce the cost of verifying fraud proofs, there's a proposal to re-introduce OP_CAT as an op code for Tapscript. OP_CAT, originally removed by Satoshi himself, is an opcode within the Bitcoin scripting language that allows two items from the script's stack to be combined into one. With this opcode, expressiveness and functionality of tapscript is massively increased. In the practice of proof verification, the increase expressiveness would allow to reduce the cost of verifying fraud proofs dramatically.
A trust-minimized bridge: To build a fully trustless bridge on Bitcoin, new Bitcoin op-codes would be needed to verify lock/unlock on other networks/systems. The popular solution right now for bridging is using multi-sigs to store all assets of the L2. There are many different approaches, such as using multiple multi-sigs, but in the end, it's still a trusted bridge that depends on the reputation and identity of the signers, as well as a certain threshold of honest signers. There's also an initial idea by BitVM that leverages a Bitcoin full node to run a side chain and uses BitVM's fraud-proof to prevent dishonest actions by unavailable or malicious participants.

Below are the some of the new approaches to build BTC L2s or Bitcoin-aligned L2s on 2024 and beyond that we think deserve some attentions:

Build on BOB

BOB is a rollup developed using OPStack by the team at Interlay. It's currently in testnet, with plans for mainnet to go live around the time of the Bitcoin halving. Although they're considering using Celestia or Bitcoin as their Data Availability (DA) layer and still using Ethereum as settlement for the boostraping phase, they plan to align more closely with Bitcoin in the future. Their plans include a gradual 5-phase roadmap that ultimately transforms into an optimistic rollup and then a zk-rollup with Bitcoin-staked sequencers. They are currently working with the likes of RiscZero and Optimism to fulfill this ambitious roadmap.

BOB's 5 Phases Roadmap. Source: https://t.co/FG3Zw8ABVb

For bridging, BOB accepts different types of BTC assets (tBTC, WBTC). They plan to use a two-way bridge using BitVM in the future once it's production-ready. Although BOB isn't a Bitcoin-settled rollup at the moment, they introduced a merge mining concept called OptiMine. This allows Bitcoin miners to partially contribute to the network's security. BOB runs a Bitcoin Light Client, which adds hashes of Bitcoin blocks to BOB. This allows for simple payment verification (SPV) that the submitted transactions were executed on the L1 and included in a block, enhancing the security of its L2 and reduces the trust reliance on the sequencer or block producers.

Botanix

Botanix is a Proof-of-Stake Layer 2, built on top of Bitcoin. Validators on Botanix stake native Bitcoin on Spiderchain to secure this second layer. Spiderchain is a distributed network of multisigs managed by the Orchestrator Nodes, which secure the actual Bitcoins.

The signers of the multisigs are randomly selected and rotate among a set of orchestrators. This process ensures that potential future malicious actors cannot control the older multisigs. Furthermore, the keys of the orchestrators are freshly generated for every new epoch to verify the orchestrators' liveness.

Lastly, the management of UTXOs selection upon bridge out follows a LIFO (last-in-first-out) approach. This means that the oldest Bitcoins staked in Botanix are secured by the oldest set of orchestrators, further enhancing the security of those coins. According to the network's documentation, there will be a maximum of 100 orchestrators.

Spiderchain functions as a bridge for pegging in and out. The orchestrators lock the user's funds on the L1 and sign an attestation to mint an equivalent number of BTC on the L2.

In the execution layer, Botanix utilizes a fork of Reth, a Rust-based Ethereum full node implementation maintained by the Paradigm team. They initially anticipate a 12-second block time, offering users an experience similar to using ETH. Furthermore, in order to achieve finality, for every Bitcoin block the current Orchestrator will inscript the Merkle Tree root hash of Botanix on Bitcoin. The other stakers are allowed the challenge in the case that Orchestrator is malicious and posting the wrong root hash. The malicious Orchestrator will then getting his stake slashed.

Botanix is currently in the testnet phase and mainnet is expected to launch soon.

Citrea

Citrea, developed by Chainway Labs, is a zk-rollup settled on Bitcoin. Initially, Chainway started by using the Sovereign Labs SDK to construct a sovereign rollup that utilized Bitcoin as the Data Availability (DA) layer. Citrea is now developing its own Type 2 zkEVM rollup. Currently, their EVM implementation is built using RiscZero's zkVM, but their modular architecture allows for the integration of different VMs in the future.

Citrea has implemented a trust-minimized two-way peg for bridging and uses a BitVM-based approach called Clementine for their zk proof verification process. Clementine’s process includes a BitVM challenge response period during which any single honest verifier can challenge the operator by producing fraud proof. If the operator tries to claim more BTC than the covered amount or doesn’t cover any withdrawal before the checkpoint (light client cut-off), the verifier can initiate a challenge. At the end of the challenge period, there are two possible outcomes:

The connector source UTXOs become spendable by the operator, which means the operator can claim the amount of BTC it covered during withdrawals. This occurs when no challenge is made by any verifier, or the verifier doesn't start the challenge with the correct block height, or the connector proves it satisfied all the withdrawals and revealed the preimages that match the satisfied withdrawals.
The connector source UTXOs are burnt alongside BitVM response UTXO, resulting in the operators' access to the bridge funds being revoked. This occurs when an honest verifier successfully initiated a challenge, and the operator’s proof has failed.

With this mechanism, as long as there's a single honest verifier in the BitVM setup, Clementine remains secure. This makes it more trust-minimized than most current federation approaches to bridges.

Additionally, rather than recording full transactional data, the prover documents only the state difference between two consecutive batches. This optimizes blockspace usage and data cost. This design, along with Citrea's trustless light client, reduces the trust requirements for Citrea's two-way peg without necessitating a soft fork.

Currently, Citrea is in the Devnet phase, featuring a synthetic native BTC integration. They have already open-sourced Clementine which you can check it out at: https://t.co/3ZWCsNWgRM

BSquared

Bsquared is developing a zk rollup that supports zkEVM as an execution layer, and includes an Account Abstraction module built inside. The Bsquared Network consists of two main layers: Rollup Layer and DA Layer.

The rollup layer consists of a zkEVM with native account abstraction, a sequencer set which is nominated by a mechanism akin to dPOS, and a RPC Service that performs preliminary validation, either directly sending them to the Mempool service or processing them for account abstraction before dispatch. There are also provers whose generate zk-STARK proofs for validity, and aggregators that aggregate proofs generated by the provers.

The DA Layer of Bsquared consists of a decentralized storage layer to store data sent by the sequencers, and a set of off-chain validators called B2 Nodes. B2 Nodes consists of six modules: ZK Proof Verifier of Rollup Module, ZK Proof Verifier of Storage Module, Sequencer Selector Module, Bitcoin Indexer Module, Bitcoin Committer Module, and Validator Set Module. These modules execute different features required in the network as their names suggested. The final rollup data is inscribed in Bitcoin by the Bitcoin Committer Module, whose also breaks down the verification computation from the ZK Proof Verifier of Rollup Module into bit-value commitment and places in a tapleaf script, sends those to Bitcoin for an interactive challenge-response window similar to BitVM.

Bsquared is currently in the testnet phase and plans to launch mainnet soon.

Stacks V2

In their version 2, Stacks introduced Proof of Transfer (PoX). To be eligible to mine blocks, miners commit Bitcoin to the Stacks network. The more Bitcoin committed by a miner, the better their chances of winning the block lottery. On the other hand, 'stackers' lock STX tokens in the protocol to validate new blocks and ensure network consensus.

Stackers also play a vital role in bridging. For asset bridging to Stacks, users deposit their BTC to a Layer 1 (L1) address, which is controlled by the Layer 2 (L2) Stackers. Once the deposit transactions are confirmed, sBTC is minted on L2 and stackers can receive BTC rewards to secure the network.

This alter in the consensus layer means that Stacks block times are anticipated to be between 5 and 9 seconds. The Nakamoto update is expected to take place around April/May this year.

Merlin

Merlin is an EVM zk rollup on Bitcoin, developed by Bitmap Tech (formerly Recursiverse) , the team behind BRC-420 protocol and Bitmap.game.

The compressed transaction data and ZK proofs from the sequencer are uploaded via the decentralized oracle network, whose nodes need to stake $BTC, to the Taproot on Bitcoin L1. Users can generate fraud proof initiate challenges to the ZK-Rollup based on compressed data, ZK state roots, and ZK Proof. Successful challenges result in a rollback to the last verified state, and the forfeiture of the Oracle node's locked $BTC.

To be Bitcoin ecosystem aligned, Merlin Chain will support different major Bitcoin protocols and standards, such as BRC-20, Bitmap, BRC-420, Atomicals, SRC20, and Pipe. Particle Network’s BTC Connect is used to allow native Bitcoin wallet users to connect to Merlin’s EVM rollup, as well as supporting account abstraction for those BTC users.

Merlin also looks like bridge the gap between Bitcoin ecosystem and the others by supporting bridges from/to other EVM chains and allows them to purchase Ordinal assets.

Bitfinity

Bitfinity is a layer 2 Ethereum Virtual Machine (EVM) for Bitcoin, built on the Internet Computer. It enables smart contracts to use Bitcoin, BRC20, and other BTC protocol assets in a familiar Solidity smart contract environment. To bridge with Bitcoin Layer 1, Ethereum, and the Internet Computer, Bitfinity employs a threshold cryptographic scheme known as Chain-Key which is natively integrated on Internet Computer for trust minimization. Chain-key enables security of the custody Bitcoin since no node would have access to the threshold key, and the threshold key shares of each node are regenerated every 11 minutes.

Bitfinity is enabled by the deep integration between ICP and Bitcoin through their adapter. ICP has one subnet consists of nodes that actually participate in Bitcoin network. These nodes are used to fetch the Bitcoin state and blocks and send transactions to the network. The above mentioned Chain-Key allows the bridge smart contract on Bitfinity to store Bitcoin securely and directly sign Bitcoin transactions.

How an ICP smart contract interacts with Bitcoin network. Source: https://internetcomputer.org/docs/current/developer-docs/multi-chain/bitcoin/overview

Bison

Bison is a zk-STARK rollup anchored on Bitcoin. It utilizes Cairo VM, a STARK-based virtual machine developed by Starkware for StarkNet, as its execution layer. Giza, a CairoVM prover that employs the Winterfell proof system, is used for zk-STARK proofs.

Since Bitcoin Layer 1 currently can't verify the zk-STARK proof natively using Bitcoin scripts, Bison delegates this verification to the users (self-verification). This allows each user to become their own validator and verify the proof, requiring only low computational resources.

All Layer 2 transactions and zk-STARK proofs are inscribed and stored on Layer 1 using Ordinal. To bridge assets between the BTC network and Layer 2, Bison uses multisig and Discreet Log Contracts (DLC) - a type of Bitcoin transaction that utilizes an oracle to execute smart contracts on the Bitcoin blockchain, enabling two parties to create and execute private agreements off-chain, with the Bitcoin blockchain acting as the final settlement for the agreements.

Mercury Layer

Mercury Layer, developed by the CommerceBlock team, is a Layer 2 statechain on top of Bitcoin. Mercury allows the transfer of individual UTXOs' ownership between two parties without requiring any on-chain transaction.

The Statechain Entity (SE) is needed to facilitates this ownership change, but without the ability to seize, confiscate, or freeze the output (hence it can be a centralised entity). Mercury Layer also enhances privacy through blinded co-signing, making it impossible for the SE to learn any details about the transactions it helps facilitate. Hence, it is more suitable to large, privacy-sensitive transfers compared to other channel approaches like Lightning Network.

For this UTXO ownership transfer process, an address is created with the private key sharded into shares owned by the SE and the original owner. Neither party knows the full private key, hence cooperation is needed to spend the UTXO. This shared secret key allows the SE to modify its key share to combine with a new owner’s key share with the original owner's cooperation, but the full shared key remains the same. This happens without revealing key shares or learning the full key, hence the private key’s security is intact. UTXO control then passes to the new owner without an on-chain transaction, and the SE only needs to delete/overwrite the previous owner's key share.

During this key transfer process, a backup transaction is also signed by the SE and the current owner, paying to an address controlled by the new owner. This can be used by the current owner to claim the UTXO's value if the SE does not cooperate or disappears. To prevent a previous owner from broadcasting their backup transaction and stealing the deposit, the nLockTime value is set to a future specified block height. Each time UTXO ownership is transferred, the nLockTime decreases by a specified value. This enables the current owner to claim the coin before any of the previous owners, when the nLockTime is reached.

Bitcoin L2s War - Short and Long-Term

This is by no mean the complete list of the new efforts on building out a layer two on top of Bitcoin to expand its capability and use cases, with names such as Via (formerly Viacoin), Rollux (formerly Syscoin), Cashu, Bitlayer, BitLynx, Flash Protocol, SatoshiVM,… also on the race. Producing the low-down of everything is out of the scope for this piece.

Given the restrictions of Bitcoin's base layer, as previously mentioned, and the fact that BitVM is still some time away from being ready and efficient for production use, we anticipate that projects which don't rely heavily on these factors could initially gain traction in the short term (less than a year) to satisfy the current demand in the ecosystem. This is despite them potentially not being the ultimate Layer 2 solution for Bitcoin due to a lack of a trust-minimized bridge or not inheriting (or very weak inheritance of) Bitcoin security, and some of them shouldn't even be considered a L2 itself (we avoid going too deep on this topic in such a pure informational piece). This expectation also factors in the general caution and complexity involved in making protocol changes/new BIP or activating an op code like OP_CAT. In the longer term, those things could totally change the picture and projects whom aligned their ethos on utilizing Bitcoin blockspace to secure its execution and providing trust-minimized bridge to the Bitcoin Layer 1 might be the “end game” of the ultimate Layer 2 that we are looking for.

Finally, here are two very useful sources to get updated and educated about Layer 2s and rollups on Bitcoin:

Written by Auris and Zany. Special thanks to Dorus and Krisma for reading through the draft and providing feedbacks.