SoK: Bitcoin Layer Two (L2)
Minfeng Qi Qin Wang Zhipeng Wang Manvir Schneider Tianqing Zhu Shiping Chen William Knottenbelt Thomas Hardjono











 





    pics/sema/.style args=#1/#2/#3code=
        #20
            [circle,minimum width=1mm,draw,fill=#1] ;
        
            (0,0)O
            [R,fill=#1](O,1mm)(90,90-#2)
            [R,fill=#3](O,1mm)(90-#2,90-360)
    
    ,










 





 


















arrows.meta
automata,positioning





















⌈⌉
⌊⌋











 





 



 





B-.05emi-.025em b-.08em
    T-.1667em.7exE-.125emX
    
  










   


 

L>X
















language=TeX,
escapeinside=“,
breaklines=true,

frame=none,
captionpos=b,
extendedchars=false,
keywordstyle=,
basicstyle=, 
commentstyle=,
showstringspaces=false,

numberstyle=,
numbersep=2em,
xleftmargin=4em,




plain         clmClaim thmTheorem    lemLemma  defiDefinition
definition    gameGame notaNotations  prfProof





 
 









 columns=fixed,       
 numbers=left,                                        
 numberstyle=,                       
 frame=none,                                          
 backgroundcolor=,            
 keywordstyle=,                 
 numberstyle=,           
 commentstyle=,                
 stringstyle=,   
 showstringspaces=false,                              
 language=sh,                                        





ŁØ
    
_ıȷłø
_  
+# 



packeditemize
	∙
			
			
			
			
			
			
			
			


circitemize
	∘
			
			
			
			
			
			
			
			








 

#1##1#1ALG@line-1

















    








SoK: Bitcoin Layer Two (L2)
    
Minfeng Qi^1,These authors contributed equally to the work.  , Qin Wang^2,*,  Zhipeng Wang^3, Manvir Schneider^4, 

Tianqing Zhu^1, Shiping Chen^2, William Knottenbelt^3, Thomas Hardjono^5  

^1City University of Macau, China | 
^2CSIRO Data61, Australia | 
^3Imperial College London, UK   
 
^4Cardano Foundation, Switzerland | 
^5Massachusetts Institute of Technology, US 

    September 9, 2024
============================================================================================================================================================================================================================================================================================================================================================================================







§ ABSTRACT 
We present the first Systematization of Knowledge (SoK) on constructing Layer Two (L2) solutions for Bitcoin.

We carefully examine a representative subset of ongoing Bitcoin L2 solutions (40 out of 335 extensively investigated cases) and provide a concise yet impactful identification of six classic design patterns through two approaches (i.e., modifying transactions & creating proofs). Notably, we are the first to incorporate the inscription technology (emerged in mid-2023), along with a series of related innovations. We further establish a reference framework that serves as a baseline criterion ideally suited for evaluating the security aspects of Bitcoin L2 solutions, and which can also be extended to broader L2 applications. We apply this framework to evaluate each of the projects we investigated.

We find that the inscription-based approaches introduce new functionality (i.e., programability) to Bitcoin systems, whereas existing proof-based solutions primarily address scalability challenges. Our security analysis reveals new attack vectors targeting data/state (availability, verification), assets (withdrawal, recovery), and users (disputes, censorship).






  



§ INTRODUCTION



Bitcoin <cit.> has surged in the crypto market since mid-2023 <cit.>. Several indicators demonstrate the growth of its ecosystem <cit.>: (i) The Bitcoin price (and marketcap) have reached a historical record price of US$73,079  (Mar. 14, 2024, #𝖢𝗈𝗂𝗇𝖬𝖺𝗋𝗄𝖾𝗍𝖢𝖺𝗉); (ii) The average block size of Bitcoin has increased significantly, from 1.2MB to over 2MB; (iii) The transaction volume in the memory pool has consistently risen, reaching nearly 24,000 transactions, compared to the stable level of around 5,000 transactions in 2022; (iv) Statistical platforms such as Dune Analytics <cit.><cit.> and UniSat <cit.> confirm the upward trend in Bitcoin transactions; (v) Numerous Bitcoin new projects <cit.> secure investment and been actively launched in the market; (vi) Governments soften policies toward Bitcoin assets, as evidenced by the approval of Bitcoin ETFs by SEC <cit.> and HK authorities <cit.>.


In this paper, we focus on the technical underpinnings, specifically the new developments designed and implemented on Bitcoin, collectively referred to as Bitcoin Layer Two (L2).


L2 protocols. Layer two in general is a mirrored concept to layer one (L1) protocols. While L1 protocols are designed to be self-sufficient and operate independently, typically referring to the blockchain base that consists of a series of core protocols (consensus mechanism, data structure, transaction/block processing) and network layer (P2P networks), L2 protocols often refer to secondary frameworks or technologies that are built on top of L1. The concept of L2 at the early stage (which we called “old-fashioned" to salute its classiness) majorly discusses off-chain computing techniques such as sidechain, channels (e.g., payment & lighting channels). Those solutions primarily improve the system's scalability while partially (i.e., byproduct) enhancing its interoperability.


    
  * Scalability[For clarity and quick reference, we use “∙” for general itemized classifications, “∘” for workflow-related steps, and “▹” for metric-related items.] refers to the ability to efficiently (also implies performance) manage an increasing volume of transactions, commonly measured by transaction speed (quicker confirmation) and throughput (transactions per second, or TPS). 
    L2 protocols are one of the main solutions for improving scalability compared to concurrent L1 techniques (e.g., block size <cit.>, consensus mechanisms <cit.>, sharding <cit.>, and chain structure <cit.>). 

    
  * Interoperability refers to the capability of heterogeneous blockchain systems to exchange data efficiently. Numerous interoperability solutions <cit.> leverage similar L2 underlying techniques (e.g., sidechains <cit.>, hash-locks <cit.>) to facilitate cross-chain communications.




Concept refinement: Bitcoin L2. When exploring the specific concept of Bitcoin L2, we find that the intrinsic nature of L2 introduces new dimensions, particularly concerning Bitcoin's functionality (i.e., programmability).



  * Functionality refers to the capacity of a blockchain to support and execute customized code, enabling state transitions directly on-chain. This term is predominantly associated with the Ethereum ecosystem (and other EVM-compatible platforms), where state-of-the-art solutions mostly utilize smart contracts to facilitate the creation of decentralized applications (dApps <cit.>), automated workflows <cit.>, and complex financial instruments (e.g., DeFi <cit.>).



However, due to the structural differences between the UTXO model (e.g.,  Bitcoin) <cit.> and the account model (e.g., EVM-compatible blockchains), discussions of Bitcoin's functionality were historically limited. This is largely because of the inherent constraints <cit.> in UTXO which is primarily designed for simple and stateless transactions. Unlike EVM-compatible platforms, Bitcoin and similar UTXO designs are not well-suited for hosting complex functional applications beyond their original purpose. To date, Bitcoin's primary role remains as a store of value (peaking at US$1.44T, Mar. 2024), serving as the anchor of crypto markets (occupying 69.2%[The global crypto market cap was US$2.08T(#𝖢𝗈𝗂𝗇𝖬𝖺𝗋𝗄𝖾𝗍𝖢𝖺𝗉).]).





 Gaps. Despite the growing importance of Bitcoin L2 solutions, awareness of this concept remains surprisingly low. Our preliminary surveys (i.e., random sampling of small groups) indicate that even experienced blockchain researchers and developers (31 out of 39) are not familiar with it. Therefore, we pose the following research questions:



  * RQ1: What is the current status of existing projects?

  * RQ2: What are the common patterns and architectural differences among these solutions?


Moreover, introducing an additional layer to the mainchain may expose the system to unexpected attacking vectors, posing significant security risks. For instance, a challenge-response pattern between the mainchain and sidechains could face risks such as falsified proofs or witnesses <cit.>; unreliable bridging services between two chains could lead to asset corruption <cit.>; and direct inscription on a transaction field might lead to transaction malleability issues <cit.>. Existing L2 studies center around classifying operational mechanisms, while security-focused research tends to address specific technical issues, often overlooking the general applicability of various constructions. This leads us to ask: 



  * RQ3: What distinct security threats (either new or existing) arise from those different design patterns?





Our approach. We show how we address these gaps.


    


  172 Collecting projects (Sec.<ref>). We start by conducting a comprehensive investigation of the projects in the wild. We then carefully examine the selected projects (40 out of 335) that can represent the most state-of-the-art developments.


  173 Identifying & assessing design patterns. Our classification is based on the modification areas within Bitcoin (cf. Fig.<ref>) where we identified two major approaches (Sec.<ref>): embedding inscribed scripts into transactions and incorporating contract management for off-chain proof verification. 



We then analyze architectural differences among various solutions (Sec.<ref>) (i.e., inscription, BitVM, rollups, sidechains, state channels, client-side verification) and examine how they integrate with the Bitcoin mainchain. To our knowledge, this is the first work to include and discuss inscription-based solutions that have not been explored previously. 





  174 Establishing new security frame (Sec.<ref>). We also, for the first time, identify a series of security threats aligned with the transaction execution workflow, specifically tailored to Bitcoin L2. We consider the security of native assets (e.g., withdrawal), the integrity of data during processes (e.g., proof/state verification, data availability), and incorporate the user’s perspective (e.g., dispute resolution).




Key findings. Bitcoin L2 introduces new dimensions (i.e., functionality) compared to earlier L2 conceptions (majorly scalability) and new methods (inscription, BitVM), while negatively also bringing more complexity and attacking vectors.  




  * Embedding scripts directly on-chain allows for implementing NFTs by uniquely numbering each satoshi and enabling state transitions via logic gates through commitments. 


  * Proof-based solutions such as rollups and sidechains enable trustless validation of off-chain transactions, ensuring that only valid state transitions are recorded on the mainchain. 


  * Complexity increases due to complicated commitment gates in BitVM, and cryptographic computations (e.g., generation, verification) in proof-based solutions.


  * Our identified attacking vectors include potential vulnerabilities in the cryptographic primitives used for transaction verification, the risk of data manipulation or censorship in the secondary chain, and the exploitation of weaknesses in withdrawal mechanisms and dispute resolution processes. 



























Our credits. We highlight several SoKs that are partially related to ours and credit (shaping our deep understanding) their discussions on Bitcoin <cit.>, “old-fashioned” L2 (off-chain) protocols <cit.>, SNARKs <cit.>, rollups <cit.>, interoperability <cit.>, and light client <cit.>.



Many recent parallel studies have made great contributions to exploring new techniques within Bitcoin <cit.>  and enhancing the scalability and robustness of Bitcoin systems <cit.>. Despite these topics being slightly beyond ours, we also acknowledge these important advancements.











§ OUR METHODOLOGY







 §.§ Project Collection










Data sources. We primarily collect Bitcoin L2 projects from four statistical websites: Rootdata <cit.>, BTCEden <cit.>, L2.watch <cit.>, and EdgeIn.io <cit.> (more in Appendix <ref>). These platforms have already amassed large-scale datasets and specialize in blockchain projects. Following this, we dive into each project's official website, GitHub repository, and open forums to gather additional information.

Selection strategy. Based on gathering initial lists of L2 projects, we apply a filtering process: (i) we conducted a deduplication process to eliminate redundancies; (ii) we primarily selected projects that had either achieved the mainnet stage or were on the cusp of doing so; (iii) we included a few projects in the testnet and pre-testnet phases with notable developmental advancements. For some borderline projects, we manually and subjectively evaluated their standing within the community, considering factors including the project team's background, media coverage, and industry recognition. 

Statistical results. Our initial results report 335 projects (detailed results in Table <ref> and Fig.<ref> in Appendix <ref>). By applying the filtering process, we screened out 40 eligible Bitcoin L2 projects (cf. the second column in Table <ref>). 



Project details. We further provide a summary of those 40 projects, which is included in Appendix <ref>.






    0.95

    
    (RQ1) Finding 1: Bitcoin L2 projects have experienced significant growth, with 335 new projects emerging within a short period (15 months). Of these, 40 have reached a stage where they are ready for examination.
    









 §.§ Design Spaces



Skeleton protocol. The Bitcoin mainchain operates through a series of fundamental protocols that ensure the secure generation of addresses and keys. Address generation involves creating a public-private key pair, where the private key k is a randomly generated 256-bit number, and the public key K is derived using the elliptic curve multiplication K = k · G, with G being the generator point on the secp256k1 curve. The Bitcoin address A is then generated by hashing the public key using SHA-256 and RIPEMD-160: A = 𝖱𝖨𝖯𝖤𝖬𝖣-160(𝖲𝖧𝖠-256(K)). 




Transaction details. In Bitcoin, a transaction T is the fundamental unit for transferring assets between addresses. Each transaction is composed of several key fields that define its structure. Specifically, a transaction T can be represented as:
T = {𝗂𝗇𝗉𝗎𝗍𝗌, 𝗈𝗎𝗍𝗉𝗎𝗍𝗌, 𝗅𝗈𝖼𝗄𝗍𝗂𝗆𝖾, 𝗏𝖾𝗋𝗌𝗂𝗈𝗇, 𝗐𝗂𝗍𝗇𝖾𝗌𝗌},
where,

    
  * 𝗂𝗇𝗉𝗎𝗍𝗌 are references to previous unspent transaction outputs (UTXOs) that the current transaction is spending. Each input contains a reference to a previous output, an unlocking script (𝖲𝖼𝗋𝗂𝗉𝗍𝖲𝗂𝗀), and a sequence number.
    
  * 𝗈𝗎𝗍𝗉𝗎𝗍𝗌 define the destination of the transferred Bitcoin, specifying the amount and a locking script (𝖲𝖼𝗋𝗂𝗉𝗍𝖯𝗎𝖻𝖪𝖾𝗒) that controls who can spend the output in the future.
    
  * 𝗅𝗈𝖼𝗄𝗍𝗂𝗆𝖾 is an optional field that specifies the earliest time or block height at which the transaction can be included.
    
  * 𝗏𝖾𝗋𝗌𝗂𝗈𝗇 indicates the transaction format version and can signal the use of new transaction types or features.
    
  * 𝗐𝗂𝗍𝗇𝖾𝗌𝗌 is used in SegWit transactions that contain the Taproot public key, witness program, and other witness data required to validate the transaction. 
    
    
    
















Supported techniques. BIP141 <cit.> introduced SegWit which separates signature data from the transaction data. BIP341 <cit.> allows complex scripts to be represented as single keys through the Taproot public key and Taptree structures, revealing only the executed path during transaction validation. We defer more technical details in Appendix <ref>.




Category by modification fields. Fields in Bitcoin transactions serve as the foundation for several L2 improvements. We categorized these improvements into two primary categories.

172 Modifying transaction data (Sec.<ref>). Techniques like inscriptions introduce new data types by modifying specific fields in transactions (i.e., embedding metadata within 𝗈𝗎𝗍𝗉𝗎𝗍𝗌 or 𝗐𝗂𝗍𝗇𝖾𝗌𝗌 fields), allowing for additional functionalities like digital assets or complex scripts.



  * Inscriptions: The inscription technique, enabled by the Ordinals protocol <cit.>, allows embedding arbitrary data into Bitcoin transaction. This process involves encoding data D, constructing a witness script S_w = 𝖮𝖯_𝖱𝖤𝖳𝖴𝖱𝖭  D. A transaction T is then created with an output script (𝖲𝖼𝗋𝗂𝗉𝗍𝖯𝗎𝖻𝖪𝖾𝗒) that references S_w as part of the witness data. The transaction is then broadcast and included in a block, embedding the data on-chain.




  * BitVM: 
BitVM <cit.> leverages the 𝖳𝖺𝗉𝗋𝗈𝗈𝗍 and 𝖳𝖺𝗉𝗍𝗋𝖾𝖾 structures to embed multiple conditions within the witness data, specifically within the Taproot public key 𝖪_𝖳𝖺𝗉𝗋𝗈𝗈𝗍. This setup allows transactions to represent more sophisticated logic by utilizing the 𝖳𝖺𝗉𝗍𝗋𝖾𝖾 structure to organize different possible execution paths. Each leaf in the Tapleaf can represent a specific logic condition or script. The root of those 𝖳𝖺𝗉𝗍𝗋𝖾𝖾s is included in the witness field as part of 𝖪_𝖳𝖺𝗉𝗋𝗈𝗈𝗍 and referenced in 𝖲𝖼𝗋𝗂𝗉𝗍𝖯𝗎𝖻𝖪𝖾𝗒.











173 Verifying proofs. Solutions that rely on cryptographic proofs typically include these proofs in the 𝗐𝗂𝗍𝗇𝖾𝗌𝗌 field or as part of 𝗂𝗇𝗉𝗎𝗍𝗌 or 𝗈𝗎𝗍𝗉𝗎𝗍𝗌, enabling the validation of off-chain computations or state transitions. Customized smart contracts often act as an automated verifier that checks the validity of the proof and manages the subsequent state changes.




  * Rollups (Sec.<ref>): Rollups utilize proofs to validate transactions off-chain and post summarized data on-chain. The validity of a batch of transactions is proved by a proof π:
π = 𝖯𝗋𝗈𝗈𝖿(T_1, T_2, …, T_n),
where T_i represents individual transactions. The rollup contract on the mainchain verifies π, ensuring that all transactions in the batch are valid.



  * Sidechains (Sec.<ref>): Sidechains use Simplified Payment Verification (SPV) proofs <cit.> to provide a cryptographic link between a transaction on the Bitcoin mainchain and the corresponding operation on the sidechain. This proof includes the Merkle path 𝖯_𝗆𝖺𝗂𝗇 from the transaction T_lock to the block's Merkle root 𝖱_𝗆𝖺𝗂𝗇, as well as the block header 𝖧_𝗆𝖺𝗂𝗇:
π_𝖲𝖯𝖵 = {𝖯_𝗆𝖺𝗂𝗇, 𝖧_𝗆𝖺𝗂𝗇, 𝖱_𝗆𝖺𝗂𝗇, T_lock}.








  * Client-side verification (Sec.<ref>): It leverages client-side validation <cit.> and the UTXO set to ensure data integrity. The provided proof π(T_x) for verification includes the following components:
π(T_x) = { C(T_x), H(U_i) },
where C(T_x) is a commitment for a transaction T_x, U_i is the UTXO associated with T_x, and H(U_i) is its hash. Verification is performed by comparing π(T_x) against the known state of UTXOs to ensure the commitment is valid.



  * State channels (Sec.<ref>): State channels enable off-chain transactions between participants by exchanging signed transactions T_i = SignedTx(S_i). These transactions result in state updates S_i, with the signatures serving as cryptographic proof of each participant’s consent to the new state. Participants can update the state without broadcasting them to the Bitcoin network. After n transactions, the updated state is:
S_n = {(𝖠, 𝗏_𝖠'), (𝖡, 𝗏_𝖡')},
where 𝗏_𝖠' and 𝗏_𝖡' are new balances of 𝖠 and 𝖡 after the n-th transaction.






























 §.§ Security Reference Frame
 

For the first time, we establish a comprehensive security reference framework specifically designed to evaluate a wide range of L2 solutions, including those previously overlooked in early-stage studies <cit.>. Our framework is rooted in an analysis of asset flow throughout its entire lifecycle, systematically categorized into three distinct phases:

172 Pre-execution. This phase focuses on security measures that need to be in place before transactions are initiated, ensuring that the system is prepared to handle transactions securely.



  * Data availability: Ensures that all necessary transaction data is fully available and accessible for verification prior to the finalization of the transaction.



173 Transaction execution.
This phase focuses on the integrity of transactions as they are being processed, including the transfer of assets and the recording of transactions.



  * State verification: Ensures that the L2 solution employs robust validation techniques to accurately mirror off-chain transactions on the mainchain.

  * Withdrawal mechanism: Safeguards the process of withdrawing assets, ensuring that funds can be securely transferred back to the mainchain without unauthorized access.

  * Anti-censorship measures: Prevents any manipulation or censorship during the transaction process, ensuring that all transactions are processed fairly and without interference.



173 Post-transaction. 
This phase addresses the measures that ensure the continued security and integrity of the system after transactions have been completed, including conflict resolution and recovery mechanisms.



  * Dispute resolution: Provide mechanisms for resolving conflicts that arise after transactions, such as fraudulent activities or disputes, to maintain network stability.

  * Emergency asset recovery: Ensures that users can reclaim assets in the case of emergencies (e.g., network failures), protecting their deposits after the transaction completion.


We defer the detailed definitions to Sec.<ref>.







§ EVALUATING BITCOIN L2 PROTOCOLS























 §.§ Bitcoin's Inscription




Bitcoin’s scripting capabilities are inherently limited due to the constraints of its scripting language <cit.>, which supports only a limited set of operations to ensure network security. 
Bitcoin inscription extends the functionality of Bitcoin by allowing string data to be embedded directly within transactions, enabling a weaker version of customized operations.

Working mechanism. The inscription process involves encoding the data (e.g., text, image, video) into a byte string or JSON format, which is then embedded in a Bitcoin transaction. The data are encapsulated within a 𝖳𝖺𝗉𝗋𝗈𝗈𝗍 script using opcodes such as {𝖮𝖯_𝖥𝖠𝖫𝖲𝖤, 𝖮𝖯_𝖨𝖥, …, 𝖮𝖯_𝖤𝖭𝖣𝖨𝖥}, creating a structure known as an “envelope”. This envelope is embedded in a 𝖳𝖺𝗉𝗋𝗈𝗈𝗍 output, leveraging the witness discount provided by SegWit <cit.> to reduce storage costs. The process is executed in two phases:


    
  * Commit Transaction: A 𝖳𝖺𝗉𝗋𝗈𝗈𝗍  output T_com is created, committing to a script 𝖲_𝖼𝗈𝗆 that references the inscription metadata 𝖣 without revealing it. This can be mathematically represented as:
    T_com = 𝖳𝖺𝗉𝗋𝗈𝗈𝗍( 𝖲_𝖼𝗈𝗆(H(𝖣)) )
    where H(𝖣) is the cryptographic hash of the inscription data. This transaction is broadcast and included in a block 𝖡_𝖼𝗈𝗆.

    
  * Reveal Transaction: The output from T_com is spent in a subsequent transaction T_rev, which includes the actual inscription data 𝖣 within its script 𝖲_𝗋𝖾𝗏. The reveal transaction is mathematically represented as:
    T_rev = 𝖳𝖺𝗉𝗋𝗈𝗈𝗍( 𝖲_𝗋𝖾𝗏(𝖣) )
    When T_rev is confirmed, the inscription metadata 𝖣 is permanently recorded on the blockchain.


The inscription technique can be used to create NFT on Bitcoin (e.g., BRC20 <cit.>) or inscription tokens on Ethereum (e.g., Ethscriptions <cit.>). For the case of BRC20, 
each satoshi during the minting process (cf.Listing <ref>) is inscribed with four pieces of metadata to represent the token's attributes. The ordinal/sequential numbers (𝖮𝗋𝖽 <cit.>) associated with these satoshis are tracked from the initial commitment to the final inscription <cit.>, ensuring that metadata is permanently linked to those specific satoshis on-chain. 

[caption=Operations (𝖬𝗂𝗇𝗍) for Bitcoin Inscription, label=list-mint,basicstyle=]
# On-chain Inscription
"p" : "brc-20", # protocol name
"op": "mint", # operation
"tick": "ordi", # token name
"amt": "1000" # the amount of token being minted

# Off-chain update
if state[tick] NOT exists OR 
                 "amt" > "lim" OR sum("amt") > "max":
    raise errors
else 
    account_state[tick]["balance"][minter] += amt







 §.§ BitVM & BitVM2



∙ BitVM. BitVM extends the design principles of inscriptions by enabling Turing-complete computation through Discreet Log Contracts (DLCs <cit.>) and cryptographic proofs.






















NAND gate. The NAND gate is an elementary component in BitVM. It results in a "1" only when both inputs are "0". For all other combinations of inputs, the result is "0". Within the Bitcoin scripting environment, the opcodes 𝖮𝖯_𝖡𝖮𝖮𝖫𝖠𝖭𝖣 and 𝖮𝖯_𝖭𝖮𝖳 can be strategically combined to emulate the behavior of a NAND gate. This composite operation, essential for constructing more complex logic, is termed "𝖮𝖯_𝖭𝖠𝖭𝖣" in BitVM. For example, Listing <ref> illustrates (also see Fig.<ref>) how a prover constructs the logic gate NAND  by pushing three bit values (E, B, and A) onto the stack, corresponding to the preimages of 𝗁𝖺𝗌𝗁𝖤, 𝗁𝖺𝗌𝗁𝖡, and 𝗁𝖺𝗌𝗁𝖠 using 𝖮𝖯_𝖡𝖨𝖳_𝖢𝖮𝖬𝖬𝖨𝖳𝖬𝖤𝖭𝖳. The verifier then checks the correctness of NAND by applying 𝖮𝖯_𝖤𝖰𝖴𝖠𝖫𝖵𝖤𝖱𝖨𝖥𝖸 operation to compare the consistency of outputs. 



[caption=Hash Commitments and Verification in NAND Gate, label=lst:hash-commitment-verification, basicstyle=, breaklines=true]
# Hash Commitments
<hashE0/1>  # Commitment to hashE
OP_BIT_COMMITMENT
OP_TOALTSTACK
<hashB0/1>  # Commitment to hashB
OP_BIT_COMMITMENT
OP_TOALTSTACK
<hashA0/1>  # Commitment to hashA
OP_BIT_COMMITMENT
OP_TOALTSTACK

# Verification
OP_FROMALTSTACK
OP_NAND
OP_EQUALVERIFY  # Verify A NAND B == E
















    






Challenge-response protocol.
The challenge-response mechanism <cit.> is crucial for ensuring the accuracy of BitVM computations. Similar to Optimistic rollups (discussed later), it provides a method for one party (i.e., the verifier) to test the veracity of another party's (i.e., the prover's) claims through a series of challenges. Both the prover and the verifier stake a certain amount of Bitcoin assets as collateral and pre-sign a series of transactions to prepare for potential disputes. The verifier, acting as a skeptic, randomly selects a logical gate from the circuit and issues a challenge to the prover. This challenge requires the prover to disclose the inputs and outputs associated with the selected gate. In response to the challenge, the prover reveals the specified gate's inputs and outputs. Notably, the process of challenging and disclosing is repeated multiple times. The verifier may challenge different gates to ensure the prover's claims are consistent across the circuit. If at any point the prover's claims about the same gate contradict each other, the verifier detects this inconsistency. Then the verifier uses this inconsistency as proof of fraud and can take punitive action, such as confiscating the prover's funds. 






Working mechanism. BitVM utilizes 𝖳𝖺𝗉𝗋𝗈𝗈𝗍 addresses to create a matrix, which functions similarly to a binary circuit. Each instruction within a Script corresponds to the smallest unit of a program, producing binary outcomes (true or false). These are organized into a matrix, resulting in a sequence of binary outputs (e.g., 01100101). The complexity of the program is directly proportional to the number of 𝖳𝖺𝗉𝗋𝗈𝗈𝗍 addresses combined, with traversal and execution time estimated at 𝒪(n) for a 𝖳𝖺𝗉𝗍𝗋𝖾𝖾 with n nodes.


    
  * Key pair generation: Participants generate their respective key pairs (k_A, K_A) and (k_B, K_B).
    
    
  * Funding transaction: A funding transaction is created with the inputs from k_A and k_B. The output script of this transaction utilizes a Taproot public key K_Taproot, which is a combination of the participants' keys and possibly other conditions:
    T_f = {𝗂𝗇𝗉𝗎𝗍𝗌(k_A, k_B), 𝗈𝗎𝗍𝗉𝗎𝗍𝗌(𝖳𝖺𝗉𝗋𝗈𝗈𝗍(K_Taproot))}.
    
    
  * Oracle setup: An oracle 𝒪 publishes a public key K_𝒪 and a signed message σ_𝒪 indicating the outcome of the event.
    
    
  * Contract execution transactions (CETs): Pre-signed CETs are created for all possible outcomes. These CETs incorporate the Taproot public key and are executed based on the oracle's signature, distributing funds accordingly.
    
    
  * State channels and off-chain state transitions: The BitVM execution process involves setting up state channels and performing off-chain state transitions s_i+1 = δ(s_i), where these transitions can be optionally validated using zero-knowledge proofs (ZKP):
    π_i = 𝗓𝗄𝗉(s_i, s_i+1).
    
    
  * On-chain verification: The final state s_n and proof π_n, and Taproot public key, are submitted on-chain for verification.


Limitations. While BitVM presents an approach to expanding the capabilities of the Bitcoin network for smart contract functionality, it also faces significant challenges. These include its current limitation to two-party interactions, the costs associated with scripting, and a narrow scope of ideal use cases <cit.>. Specifically, BitVM's architecture is limited to interactions between two pre-defined entities. Extending this to support N-to-N interactions, where multiple parties are involved in a single contract, would require a more complex logical design. In addition, the execution of preset unlock conditions for 𝖳𝖺𝗉𝗋𝗈𝗈𝗍 addresses in BitVM incurs miner fees, and as the number of addresses involved increases, so does the cost. Furthermore, BitVM is best suited for applications that rely on heavy off-chain computations. However, for applications that require frequent on-chain interactions, BitVM may not be the most efficient solution.











∙ BitVM2. BitVM2 is an advanced iteration of the original BitVM, designed to enable permissionless verification <cit.>. This iteration overcomes the limitations of the initial design, which was confined to predefined two-party setups, by allowing any participant to act as a verifier during runtime.


SNARK verifier. In BitVM2, the system employs a one-time setup with a 1-n honesty assumption, where anyone can challenge an invalid assertion without being part of the initial verifier group. The verification process in BitVM2 utilizes the Groth16 proof system <cit.> to verify assertions efficiently. A key technical enhancement is the division of the SNARK verifier program into smaller, manageable sub-programs, each verified through a sequence of steps using Lamport signatures <cit.>. Specifically, let's denote the initial state as s_0 and the final state as s_n. The state transitions are managed by an optimized state transition function δ:
s_i+1 = δ(s_i).
Each transition generates a proof π_i that verifies the transition without revealing any confidential information:
π_i = 𝖦𝗋𝗈𝗍𝗁16(s_i, s_i+1).
To handle the large size of the SNARK verifier programs, the computation is split into multiple steps. Each step j is signed using Lamport signatures σ_j:
σ_j = 𝖫𝖺𝗆𝗉𝗈𝗋𝗍𝖲𝗂𝗀𝗇(H_j, K_j),
where H_j represents the hash of the computation step, and K_j is the corresponding key.











Limitations. One challenges is the need to emulate covenants due to their absence in Bitcoin, which requires the involvement of a signer committee, thereby increasing off-chain coordination efforts. This adds complexity to the system and heightens the risk of operational delays or inefficiencies. Moreover, the design depends on the presence of at least one honest operator to prevent funds from becoming unspendable, creating the risk of ransom attacks, where malicious operators could freeze assets and hold them hostage <cit.>. Additionally, the system generates large, non-standard transactions that may not be relayed by default Bitcoin nodes, necessitating alternative propagation methods and increasing reliance on custom network configurations <cit.>. Lastly, the use of fixed deposit amounts restricts flexibility, which may force users to engage with professional services for peg-ins and peg-outs. This reliance on external services could reduce accessibility, particularly for smaller or casual users, and may create entry barriers for a broader range of participants.

















Discussion. The surveyed projects <cit.>, each building on BitVM in different ways, collectively advance Bitcoin’s capabilities of off-chain computation. For instance, BitLayer builds on BitVM by integrating a more sophisticated state management system. ZKByte focuses on incorporating ZKP into Bitcoin’s L2, utilizing a ZKP validator while managing cross-chain state transitions through the UTXO model. Bitstake leverages the BitVM framework to implement a PoS mechanism, enabling dynamic participation in transaction management. On the other hand, Citrea implements a ZK Rollup architecture, introducing the concept of execution slices that batch process thousands of transactions. SatoshiVM simplifies circuit complexity by adopting the Bristol format for logical gate circuit structures and introduces single-round non-interactive on-chain verification.





 §.§ Rollups



Data availability requires all necessary data for verifying to be readily accessible to all participants <cit.>. However, as Bitcoin networks grow in size, ensuring that every participant has access to all transaction data becomes increasingly challenging. 
Rollups move most computational work off-chain, transmitting only small size data (e.g., transaction outputs, state updates, proof data) to the mainchain <cit.>. By processing transactions off-chain and periodically posting summarized data on-chain, rollups can improve transaction throughput.








    













Components. The mechanism relies on three  components to ensure the off-chain transaction processing and validation.




  * Sequencer: A sequencer plays a crucial role in collecting and ordering transactions before they are aggregated and processed. Essentially, the sequencer's primary job is to receive transactions from users, order them, and then batch them into a single rollup block <cit.>. The way transactions are ordered can affect the state of the rollup and potentially the fees associated with those transactions.


  * Operator: An operator executes transactions in an off-chain environment and manages the resulting state transitions <cit.>. This off-chain execution and management facilitate reduced load and less computational effort on the mainnet. Operators are responsible for submitting proof of the rollup blocks to the blockchain mainnet. 


  * Challenger: The role of challengers is to act as external verifiers who check the validity of the operator's commitments to the mainchain. They continuously monitor the state transitions and proofs. If challengers detect inconsistencies or fraudulent activity in the submitted data, they can submit a fraud-proof to the mainchain.




Working mechanism. Bitcoin rollups work by processing a large volume of transactions off-chain on an L2 network and then summarizing the results to submit to the main Bitcoin blockchain. The process involves five main steps:


    
  * Transaction initialization on L2: Users initiate transactions on the L2 Rollup. The sequencer and operator are responsible for sorting these transactions, aggregating them into batches, executing the transaction logic, and computing the post-transaction state.
    
    
  * State representation: The state of the blockchain, including account balances and state variables, is represented in a specific data structure such as a Merkle tree. The Pre-state Root R_pre represents the state before the transactions are executed, while the Post-state Root R_post represents the state after the transactions are executed:
    R_pre  = 𝖬𝖾𝗋𝗄𝗅𝖾𝖱𝗈𝗈𝗍(S_pre) and R_post  = 𝖬𝖾𝗋𝗄𝗅𝖾𝖱𝗈𝗈𝗍(S_post).

    
    
  * Transaction proof generation: The Operator generates a transaction proof π along with the Post-state Root R_post. For zk-rollups, this proof is a succinct zk-proof:
    π = 𝖦𝗋𝗈𝗍𝗁16(R_pre, R_post, T).
    For Optimistic rollups, the proof involves a fraud-proof mechanism where participants can challenge incorrect state transitions:
    π_fraud = 𝖥𝗋𝖺𝗎𝖽𝖯𝗋𝗈𝗈𝖿(R_pre, R_post, T).
    
    
  * Submission to the mainchain: The Operator submits the Post-state Root R_post and the transaction proof π to the Rollup smart contract on the mainchain.
    
    
  * Verification on the mainchain: The Rollup contract verifies whether the state transition from R_pre to R_post is correct using the submitted proof:
    𝖵𝖾𝗋𝗂𝖿𝗒(R_pre, R_post, π) →𝖳𝗋𝗎𝖾.
    If the verification passes, the Rollup contract updates the state on the mainchain, confirming the transactions that took place on L2. If an incorrect R_post is submitted, other participants can challenge it using R_pre and the transaction batch data:
    𝖵𝖾𝗋𝗂𝖿𝗒(R_pre, R_post, π_fraud) →𝖥𝖺𝗅𝗌𝖾.



Types of rollups. There are two primary types of rollups: Zero-knowledge Rollups (zk-rollups) that utilize ZKPs to validate transaction efficacy, and Optimistic rollups that employ fraud-proof mechanisms to ascertain transaction validity.




  * Zk-rollups: Operators in zk-rollups generate and submit a ZKP, specifically zk-SNARks and zk-STARKs <cit.>, to the mainchain. This validity proof confirms the correctness of all transactions in the batch and the resultant new state. zk-SNARKks, while fast due to their small proof sizes and quick verification times, require a trusted setup that can be a security concern if compromised <cit.>. Conversely, zk-STARKs avoid this issue by not needing a common reference string, offering better resistance against quantum computing, albeit at the cost of larger proof sizes <cit.>.


  * Optimistic rollups: The fundamental assumption in Optimistic rollups is that the transactions and state changes are valid by default. Different from using a ZKP, Optimistic rollups use a fraud-proof mechanism <cit.>. When an illegal transaction is identified, challengers can challenge it by submitting a fraud proof to the network. The person who submitted the fraudulent transaction, faces penalties, typically losing their bond. A portion of this bond is awarded to the challenger as a reward. While both types of rollups increase throughput, implementing zk-rollups is generally more complex than Optimistic rollups because of the intricacies involved in generating ZKPs. Conversely, Optimistic rollups typically have a longer withdrawal time due to the challenge period necessary for potential fraud proofs.




Limitations.
Implementing rollups on Bitcoin presents a unique set of challenges due to Bitcoin's underlying design, which is quite different from platforms like Ethereum that support on-chain programmability. Rollups require a rich set of functionalities to manage state transitions, process fraud or validity proofs, and handle complex dispute resolutions, which are beyond the capabilities of Bitcoin's current scripting language. In addition, to implement rollups efficiently, Bitcoin would likely need adjustments at the base-layer protocol to support essential features, such as covenants. Such changes require broad consensus within the community, which has been slow to progress given the Bitcoin community's wariness of any agreement. Furthermore, the absence of a native smart contract layer in Bitcoin complicates the deployment of rollups. Technologies like zk-rollups depend on complex smart contracts for generating and verifying zpks. Similarly, Optimistic rollups need smart contracts for managing the challenge-response mechanisms essential for their security model. The deployment of such systems would require a foundational shift in how Bitcoin operates.

Discussion. The rollup-based projects <cit.> on Bitcoin demonstrate a range of strategies to enhance scalability. In the zk-rollups category, Projects like B² Network and Bison leverage ZKP for secure transaction validation, with B² Network incorporating a hybrid zkEVM and fraud-proof challenge mechanism, while Bison emphasizes computational efficiency with zk-STARKs. Tuna Chain and BL2 use zk-rollups for batch processing and integrating Taproot and decentralized data availability layers, respectively, with BL2 introducing a dual-layer architecture for distributed verification. Sovryn and Merlin Chain further extend this category by combining zk-rollups with decentralized oracle networks and bi-directional bridges to enhance cross-chain interactions. In the Optimistic rollups category, projects like Biop and Rollux utilize the Optimistic Rollup protocol to batch transactions off-chain, with Biop integrating PoS consensus and fault-proof mechanisms, and Rollux leveraging the Optimism Bedrock for EVM equivalence. BeL2 adopts Elastos SmartWeb and a relayer mechanism for fraud prevention, while Hacash.com introduces a multi-layered architecture that supports high transaction throughput and utilizes rollup for real-time settlement.






 §.§ SideChain
 
Sidechains <cit.> allow assets to be transferred between Bitcoin (acting as the mainchain) and secondary blockchains (sidechains) through a two-way peg mechanism <cit.>. This enables Bitcoin to be transferred to a sidechain, where it can benefit from the sidechain's unique features and capabilities, and then back to the mainchain. 







    




Simplified payment verification. SPV <cit.> is an essential component of the Bitcoin network that allows users to verify transactions without maintaining a full copy of the blockchain. The SPV node first calculates the hash H(T_x) of the transaction T_x that needs to be verified and then fetches all block headers H_b of the longest branch. It uses the Merkle path P(T_x) to calculate the Merkle root hash R_m and compares it with the Merkle root stored in the local block header to identify the block containing the transaction.










































Working mechanism. The core component of sidechain architecture is the two-way peg mechanism, enabling asset transfer between Bitcoin and a sidechain, typically through SPV proof. The working principle of the sidechain is as follows.


















    
  * Locking Bitcoin on the mainchain: The user initiates a transaction T_lock on the mainchain, sending 𝖠_𝖡𝖳𝖢 to a specific locking script, which is recorded with Merkle root R_main.

    
  * Generating the SPV proof: An SPV proof π_𝖲𝖯𝖵 is generated, including the Merkle path 𝖯_𝗆𝖺𝗂𝗇 from T_lock to R_main, as well as the block header 𝖧_𝗆𝖺𝗂𝗇:
    π_𝖲𝖯𝖵 = {𝖯_𝗆𝖺𝗂𝗇, 𝖧_𝗆𝖺𝗂𝗇, R_main, T_lock}.

    
  * Verification on the sidechain: The sidechain verifies T_lock using π_𝖲𝖯𝖵 by ensuring that
    𝖬𝖾𝗋𝗄𝗅𝖾𝖱𝗈𝗈𝗍( 𝖯_𝗆𝖺𝗂𝗇∪ T_lock ) = R_main.
    Upon successful verification, the sidechain creates 𝖠_𝗌𝗂𝖽𝖾 tokens, ensuring 𝖠_𝗌𝗂𝖽𝖾 = 𝖠_𝖡𝖳𝖢.

    
  * Returning Bitcoin to the mainchain: To transfer Bitcoin back to the mainchain, the user must destroy 𝖠_𝗌𝗂𝖽𝖾 tokens and provide proof π_𝗌𝗂𝖽𝖾. The mainchain verifies the proof and, if valid, releases the Bitcoin to the user.



Types of sidechains. Sidechains can be classified into three main categories based on their consensus mechanisms.




  * Federated consensus sidechains: Federated sidechains rely on a group of trusted entities, known as a federation, to manage the locking and unlocking of assets between the mainchain and the sidechain <cit.>. This is achieved through federated multi-signature to lock the bitcoins released in the sidechain. The security of federated sidechains depends on the trustworthiness and honesty of the federation members.


  * Merged-mined sidechains: A Merged-mined sidechains utilize Bitcoin’s miner network and the same PoW consensus to manage asset transfers. <cit.>. Miners validate blocks on both the mainchain and sidechain simultaneously, using a two-way peg mechanism for asset movement. Similarly, Drivechain <cit.>, employs Bitcoin miners as custodians to manage transfers. It uses miners' collective hash power to secure assets across different sidechains.





  * PoX-based sidechains: In a PoX-based sidechain, PoX miners commit BTC to the Bitcoin mainchain through a consensus mechanism other than PoW. These BTC transactions serve as “anchor points” that create a link between Bitcoin and the sidechain, synchronizing both blockchains. The miners are rewarded in the sidechain’s native token, like how miners are rewarded in PoW-based system.



Limitations.
Sidechains enhance the scalability of Bitcoin, but they come with several limitations. Security is a prime concern due to reduced decentralization in sidechains, which often rely on a smaller set of validators for consensus, potentially concentrating power. Interoperability is another challenge, as each sidechain may operate under different rules and protocols, complicating asset transfers between chains. The design of sidechains also involves trade-offs, particularly between decentralization and the desired performance characteristics such as transaction speed and cost. 




















Discussion. The sidechain-based projects <cit.> investigated in the paper can be grouped into the three categories above. Federated consensus sidechains, such athe Liquid Network, implement a consortium model that employs blocksigners and watchmen, diverging from Bitcoin's PoW mechanism. Merged-mined sidechains such as Rootstock leverage Powpeg mechanism, which involves multi-signature management to manage BTC transfers between the mainchain and the sidechain. In the realm of PoX-based sidechains, projects like MAP Protocol push the boundaries by using ZKP and light clients for cross-chain interoperability, while Stacks ties its security to Bitcoin via PoX, allowing miners to earn rewards for BTC commitments. Mintlayer and BounceBit extend this concept by employing PoS mechanisms, with Mintlayer using Bitcoin block hashes for randomness in block production and BounceBit integrating both CeFi and DeFi elements. Libre, operating on a Delegated Proof-of-Stake (DPoS) mechanism, integrates with Bitcoin via the Lightning Network. BitReXe introduces a multi-VM system using the PREDA programming model, and BEVM utilizes Musig2 for secure multi-signature schemes and native BTC as gas.




 §.§ Client-side Verification Plus UTXO
 
Client-side validation (CSV) allows for an efficient method of transaction verification. Instead of every node handling every transaction, clients validate the parts of the transaction history relevant to them. However, by enabling users to authenticate data validity autonomously, this method bypasses the standard consensus model, potentially resulting in data discrepancies among diverse clients.

The UTXO set, recognized for its immutability consensus, serves as a foundational ledger within the Bitcoin network <cit.>. Establishing a dependable linkage between off-chain assets and the state of UTXOs is essential for extending consensus-driven validation. The CSV+UTXO approach combines off-chain asset issuance with a dynamic on-chain UTXO ledger. The UTXO set acts as a time witness that can verify the precise state of Bitcoin transactions at any given time. This feature allows users to synchronize changes in these transactions with changes in the state of other assets.







    





Single use seal. 

A single-use seal is a cryptographic primitive that facilitates a two-tiered commitment <cit.>. It allows a committer to commit to a message at a future point in time, with the assurance that this commitment can only be made once. Bitcoin Transaction Output-based Single-use-Seals (TxO Seals <cit.>) apply this concept to the Bitcoin transaction graph. Parties in the protocol agree on a transaction output with special meaning, designated as a "seal." A future transaction, known as the "witness transaction," is required to contain a deterministic Bitcoin commitment to a specific message. There are two properties of TxO Seals:


    
  * Hiding: Independent parties cannot detect the presence of the commitment in the transaction graph, even if the original message is known.
    
  * Verifiability: Given information about the specific commitment protocol and access to deterministic Bitcoin proof data, any party can verify the commitment's validity for the intended message only.


Working mechanism. The CSV+UTXO technology leverages the hiding and verifiability of TxO seals to enhance the Bitcoin network's scalability. Below is a process overview:


    
  * Transaction initiation: A client C_i initiates a transaction T_x. This transaction is committed to the UTXO set, where each UTXO U_i represents an unspent transaction output.
    
    
  * Client-side validation: Each client C_i validates the transaction T_x by verifying the relevant UTXOs U_i associated with the transaction. The client computes the transaction hash H(T_x) and validates it using the Merkle root R_m.
    
    
  * Single-use seal commitment: A single-use seal S is applied to the transaction output T_x. Let M be the message to be committed, and C be the commitment. The commitment C is represented as:
    C = 𝖢𝗈𝗆𝗆𝗂𝗍(H(T_x), M).
    
    
  * Deterministic Bitcoin proof: The witness transaction includes a deterministic Bitcoin commitment to M. The proof π is verified using the UTXO set U_i, where H(U_i) represents the hash of the relevant UTXO:
    π = 𝖯𝗋𝗈𝗈𝖿(C, H(U_i)).
    
    
  * Verification: The commitment's validity is verified by any party with access to the proof data. The verifiability property ensures that the commitment C can only be valid for the intended message M and that it is linked to the specific UTXO U_i.
    𝖵𝖾𝗋𝗂𝖿𝗒(π, H(U_i)) →𝖳𝗋𝗎𝖾.



Limitations. The implementation of this approach is highly complex, primarily due to Bitcoin’s inherent design, which does not natively support such intricate computations. Additionally, When a client receives a payment, it may need to verify a large amount of data all at once, which can be considered a drawback. This issue typically arises when a client first acquires an asset with a lengthy transaction history.

Discussion. The reviewed projects <cit.> collectively demonstrate a focused attempt to broaden Bitcoin's functionalities through the uses of UTXO and CSV. RGB embeds cryptographic commitments in UTXOs for asset issuance and management. RGB++ expands on RGB by integrating other UTXO-based blockchains like CKB and Cardano as verification layers, trading off some privacy for increased global verifiability. BiHelix further builds on the RGB protocol, integrating with the Lightning Network to enhance Bitcoin’s interoperability. Bitlight Labs focuses on CSV to manage smart contracts, employing the Simplicity language to enable Turing-complete scripting. Bool Network uses Dynamic Hidden Committees and integrates CSV for cross-chain security. Lastly, Mercury Layer emphasizes statechain technology to facilitate rapid Bitcoin UTXO transfers, relying heavily on CSV for statechain verification.








 §.§ State Channel
 
State channels are designed to facilitate off-chain transactions between parties <cit.>. These channels are particularly useful for frequent transactions, such as micropayments.







    





Working mechanism. The working mechanism of state channels can be broken down into the key steps involved in the opening, operation, and closure of a state channel.
 



  * Opening the channel: To establish a state channel, two or more participants, say Alice and Bob, create a multi-signature address A_multi, which requires signatures from both parties. Each participant deposits a certain amount of Bitcoin, B_Alice and B_Bob, into this address. The transaction T_open marking the channel’s opening is recorded on the blockchain:
T_open = 𝖳𝗑(A_multi, B_Alice + B_Bob).
Once the channel is open, participants can conduct numerous transactions off-chain. These transactions are reflected as state updates S_i, where each update represents a new distribution of the funds held in the channel.


  * Conducting off-chain transactions: During the operation of the state channel, participants exchange signed transactions T_i that update the state of the channel without broadcasting these transactions to the Bitcoin network. These state updates are essentially promises of future transactions that both parties agree upon:
T_i = SignedTx(S_i),
with signatures from Alice and Bob. The most recent state update always supersedes previous ones, ensuring that the latest agreement on the fund distribution is maintained. For example, if Alice and Bob agree on a state update S_2 after initially agreeing on S_1, then:
S_2 ⇒(𝗇𝖾𝗐 𝖽𝗂𝗌𝗍𝗋𝗂𝖻𝗎𝗍𝗂𝗈𝗇: 𝖡_𝖠𝗅𝗂𝖼𝖾^', 𝖡_𝖡𝗈𝖻^').


  * Closing the channel: When the participants decide to close the channel, they create a final transaction T_close reflecting the last agreed-upon state S_final and broadcast this transaction to the Bitcoin blockchain:
T_close = 𝖳𝗑(A_multi, S_final).
This final transaction closes the channel and redistributes the funds according to the last state update. By doing so, the blockchain only records two transactions: T_open to open the channel and T_close to close it, regardless of the number of off-chain transactions conducted within the channel.





Limitations. One challenge is the complexity of managing the multi-sig setup required to open a channel <cit.>. Each transaction within the channel needs to be signed by all parties involved, which introduces delays and coordination issues, particularly when involving more than two participants. Additionally, the mechanism for closing a channel is vulnerable to disputes <cit.>. If a party tries to broadcast an outdated transaction state, it requires timely intervention from the other party to prevent fraud, which necessitates constant monitoring.
zi'xi

Discussion. The projects <cit.> exemplify the technical advancements of state channels. Lightning Network utilizes mechanisms like RSMC for secure updates and HTLC for conditional transactions, enabling off-chain payments through a network of payment channels. OmniBOLT builds on the Lightning Network by facilitating the off-chain circulation of smart assets, adding capabilities such as cross-channel atomic swaps through its Golang-based protocol suite. Lnfi Network extends the state channel concept by integrating Taproot assets with Nostr’s key management. Ark Protocol innovates on state channel by eliminating the need for incoming liquidity, allowing for the seamless conversion of on-chain UTXOs to virtual UTXOs and back.


Others. In addition to the aforementioned solutions, this category of Bitcoin L2 solutions includes a variety of other methods (Appendix <ref>). This includes Tectum <cit.>, which introduces SoftNotes <cit.> for fast, off-chain transactions; Nubit <cit.>, which employs data availability sampling (DAS) for efficient block verification; and HyperAGI <cit.>, designed to support compute-intensive applications for AI. These projects represent the diversity in Bitcoin’s evolving L2 ecosystem.





    0.95
    
    (RQ2) Finding 2: Among the examined Bitcoin L2 projects, 12% embed data into transactions to extend functionality. Furthermore, 81% of the projects utilize off-chain computation to alleviate on-chain congestion, while 72% employ cryptographic proofs, including ZKPs and SPV, for secure state verification.

    












§ SECURITY EVALUATION













 §.§ Security Framework


By examining various vulnerability sources <cit.>, we identified a series threats across the entire lifecycle of asset flow, categorizing them into: unauthorized withdrawals, incorrect transaction verification, manipulation and censorship, fraudulent disputes, data unavailability, and the inability to recover assets during emergencies. 

We accordingly present our structured security evaluation framework (answering RQ3), comprising six critical criteria (denoted by C) as follows. We provide a detailed analysis of each project’s strengths and vulnerabilities as in Table <ref>.














    
  * 




    0.95

    (RQ3) Finding 2: 

    







C1. Withdrawal mechanism (WM) evaluates whether the L2 solution employs robust security measures to safeguard the withdrawal process, ensuring that funds can be securely and correctly transferred back to the Bitcoin mainchain. The primary security threat associated with this criterion is the risk of unauthorized withdrawals, where malicious actors could potentially gain access to funds without proper authorization. Insecure or flawed withdrawal mechanisms could lead to the loss of assets, as attackers might exploit vulnerabilities to initiate fraudulent withdrawals or intercept the process. To mitigate the threat, WM considers security features as below:


    
  ▹ Multi-signature authentication: This involves requiring multiple parties to sign off on a transaction before it can be executed. It adds an additional layer of security, ensuring that no single entity can unilaterally withdraw funds.

    
  ▹ Cryptographic proofs: These are mathematical techniques that allow one party to prove to another that a statement is true without revealing any information beyond the validity of the statement itself. In the context of withdrawals, the proofs are typically used to guarantee that the transaction data is valid without revealing sensitive information.

    
  ▹ Decentralized validators: Using a group of validators to approve transactions can distribute the power to authorize withdrawals across multiple independent entities, reducing the risk of collusion or single points of failure (SPoF).

    
  ▹ Time-locked contracts: They are, in most cases, a pair of smart contracts on both legs that delay the execution of a transaction until a specified amount of time has passed. The contracts can be used to create a buffer period during which any unauthorized withdrawal can be detected and canceled.






C2. State verification (SV) assesses the robustness of the L2 solution’s validation techniques to ensure the correctness of off-chain transactions and their accurate reflection on the mainchain. The primary security threat associated with this criterion is the risk of incorrect transaction verification, where invalid or manipulated off-chain transactions could be improperly validated and recorded on the mainchain. This could lead to incorrect balances, loss of funds, or unauthorized asset transfers. To mitigate this threat, it is crucial that the L2 solution employs stringent state verification mechanisms that can effectively detect and prevent invalid state transitions:




  ▹ Zero-knowledge proofs: These proofs allow validators to confirm the validity of transactions without needing to see the transaction details. This preserves privacy while ensuring that only legitimate transactions are processed.


  ▹ Fraud proofs for Optimistic rollups: These are mechanisms that allow any network participant to challenge and prove a fraudulent transaction. If a transaction is deemed fraudulent, it can be reverted, and the dishonest party penalized.


  ▹ Cryptographic commitments: This technique involves creating a cryptographic hash of transaction data, which can later be used to verify the integrity of the data. It ensures that the data has not been tampered with.


  ▹ Periodic state commitments to mainchain: Regularly committing the state of off-chain transactions to the mainchain creates a verifiable and immutable record. This helps maintain the integrity of the Bitcoin blockchain.




C3. Anti-censorship measures (ACM) evaluate the L2 solution’s ability to prevent any single entity from controlling or censoring transactions within the network. The primary security threat associated with this criterion is the potential for manipulation and censorship, where a powerful entity or group could selectively block or reorder transactions to their advantage, undermining the fairness and neutrality of the network. This threat can lead to scenarios where certain transactions are unfairly delayed or never processed. To mitigate the threat, ACM should consider the following aspects:



  ▹ Decentralized sequencers: Sequencers are responsible for ordering transactions in a decentralized manner, preventing any single party from manipulating the transaction order.


  ▹ Governance models: These models distribute decision-making power across a broad range of stakeholders, preventing any single entity from having undue influence.


  ▹ Distribution of power: Ensuring that power is distributed among multiple participants reduces the risk of censorship and promotes a more democratic system.


  ▹ Mitigation of manipulation risks: Measures to detect and prevent manipulation of the transaction process help ensure that all transactions are processed fairly.




C4. Dispute resolution (DR) examines the mechanisms that an L2 solution employs to resolve conflicts, particularly those involving fraudulent activities or disputes. If disputes are not resolved efficiently, it could lead to manipulation of the network, where malicious actors might take advantage of unresolved conflicts, further leading to network instability, loss of user funds, and reduced trust in the system.  






  ▹ Fraud proofs: These proofs allow network participants to challenge and prove fraudulent transactions, ensuring that any dishonest activities are promptly addressed.


  ▹Efficiency of dispute resolution process: The speed and effectiveness with which disputes are resolved are critical to maintaining trust in the system. Efficient processes ensure that issues are addressed quickly and fairly.


  ▹Role of validators/arbitrators: Validators or arbitrators play a crucial role in resolving disputes. Their impartiality is essential for a fair dispute-resolution process.


  ▹Incentives and penalties: A system of rewards and penalties encourages honest behavior and discourages fraud. This includes rewarding participants who detect and report fraud and penalizing those who attempt to commit fraud.





C5. Data availability (DA) assesses the strategies implemented by an L2 solution to ensure that all transaction data is available for verification at all times. The primary concern here is to prevent scenarios where crucial transaction data becomes inaccessible, leading to potential validation failures or network manipulation. Data unavailability poses a severe security threat, as it could allow malicious actors to hide or manipulate transaction details, undermining the integrity of the verification process. Without guaranteed data availability, the network risks losing the ability to detect fraudulent activities, making it vulnerable to exploitation. 





  ▹ Decentralized data availability: The metric involves using distributed nodes within the network to serve transaction data, ensuring no SPoF can compromise data availability.


  ▹ Data availability sampling: This technique involves checking random samples of data to ensure that the entire dataset is available and has not been tampered with.


  ▹ Erasure coding: This is a data protection method that breaks data into fragments, encodes them, and distributes them across multiple locations. It ensures that data can be reconstructed even if some fragments are lost or corrupted.


  ▹ Off-chain storage with periodic on-chain commitments: Storing data off-chain reduces the burden on the mainchain, while periodic on-chain commitments provide a verifiable record that the data has not been tampered with.




C6. Emergency asset recovery (EAR) focuses on evaluating the effectiveness of the mechanisms to allow users to reclaim their assets during emergencies, such as network failures, breaches, or unexpected shutdowns. The corresponding security threat in this context is the potential loss of assets due to system failures or malicious attacks that prevent users from recovering assets. This criterion examines whether the L2 solution provides robust methods to initiate and complete asset recovery, ensuring that users have a fallback plan. 






  ▹Force-close transactions: These transactions allow users to close their positions and recover their assets even if the network is experiencing issues (e.g., asynchrony).


  ▹Time-locked exit transactions: These transactions provide a delayed period during which users can exit the system securely. Assets can be protected against immediate threats.


  ▹Exit windows: These are specified periods during which users can exit the system, providing regular opportunities for asset recovery.


  ▹Monitoring by validators and watchtowers: Validators and watchtowers continuously monitor the network for issues and ensure that exit transactions are processed correctly.







 §.§ Case Study


We select a representative project (Bitlayer <cit.>) as a case study. We examine each criterion with a scale of low, medium, and high to show the security performance.

















Multi-sig authentication. The process begins with participants like Alice and Bob creating an off-chain fund transaction on Bitlayer. Each locks a certain amount of Bitcoin into a 2-of-2 multi-sig address, ensuring that funds can only be moved with both parties’ consent. This setup directly addresses the WM criterion by preventing unauthorized access to the locked funds through multi-sig authentication. The pre-signed nature of these transactions ensures that funds are securely committed without immediate blockchain involvement. Consequently, BitLayer’s multi-sig authentication is effective in securing funds, thus rating this aspect as high.

Creation of CETs. Next, Alice and Bob pre-sign various CETs representing all potential outcomes of their contract. These CETs include conditions to distribute the funds based on an oracle’s outcome announcement. This process aligns with state verification by employing cryptographic commitments to ensure data integrity and tamper-proof records of off-chain states. The CETs are designed to execute based on ZKPs, ensuring that the transaction details remain private while validating the outcome. Therefore, the robust creation and use of CETs in BitLayer provide strong state verification capabilities, making this criterion rate high.

Time-locked contracts. Oracles play a crucial role in determining the outcome by signing the corresponding CET based on real-world events. To ensure security, time-locked contracts are used so that if the oracle does not provide a signature within a specified period, the locked funds are returned to the participants. This ensures that funds are not indefinitely locked, satisfying the criteria of EAR by providing a secure exit strategy. Consequently, rating this aspect as high.

Broadcasting the fund transaction. After all CETs are pre-signed, the fund transaction is broadcasted, locking the funds in the multi-signature address. Upon receiving the oracle’s signed outcome, the appropriate CET is executed to redistribute the funds. If an incorrect CET is broadcasted, BitLayer’s fraud-proof mechanism enables participants to challenge the transaction, ensuring disputes are resolved fairly. This dispute resolution process effectively meets the DR criterion, resulting in a high rating for BitLayer.



Decentralized validators. BitLayer employs decentralized validators to validate transactions, preventing any single entity from manipulating the process. This measure fulfills the ACM criterion by distributing power and ensuring unbiased transaction sequencing. Furthermore, the CETs and fund transactions are stored off-chain, with only necessary data being committed on-chain when required. This hybrid storage approach ensures that data is always accessible for validation purposes while maintaining transparency. Thus, BitLayer’s use of decentralized validators and a hybrid storage approach provides strong ACM and DA, rating these two criteria high.








    






























































    0.95

    (RQ3) Finding 3: Most projects (85%) exhibit strong withdrawal mechanisms, particularly through MSA and TLC. State verification is robustly supported by cryptographic proofs like ZKPs among projects (72%). Anti-censorship measures (55%) vary, with decentralized sequencers and governance models ensuring fair transaction processing in some projects. Dispute resolution mechanisms (78%) are generally effective, with fraud-proof implementations and the role of validators playing key roles. However, data availability (42%) and emergency asset recovery (37%) are less consistently implemented, with only a subset of projects offering comprehensive solutions.

    





















§ FURTHER DISCUSSION
 













More evaluated properties (last five columns in Table <ref>). We also assess the selected projects using a broader set of criteria (i.e., properties from existing studies) at three levels (high, medium, and low) to provide extended references.




Limitations of DLC. One issue is the contract’s funding guarantee. For example, Alice and Bob can use a DLC to hedge against Bitcoin price volatility by agreeing on a future price for Bitcoin, settled in USD. Since funds are pre-committed, the contract can only handle limited price fluctuations. If the price of Bitcoin falls below a certain threshold, the pre-committed funds may not cover the contract’s value, locking the funds inefficiently. Increasing the amount of committed funds could mitigate this, but it also means locking up more capital. Another challenge is the extensive number of signatures required for every possible contract outcome. This can become unmanageable in scenarios with many potential outcomes, like forward contracts with varied price points. A proposed solution <cit.> involves breaking down values into fractional parts, reducing the number of signatures needed for a wide range of values, but this solution has yet to be verified. 












Centralization of indexers.

Bitcoin indexers are crucial for enabling off-chain computations. For example, B²nodes <cit.> are equipped with indexers to parse and index inscriptions. These indexers work by scanning the blockchain, extracting necessary data, and maintaining states. However, the reliance on centralized indexers (i.e. UniSat <cit.>) introduces several security risks. Centralized indexers can become SPoF, susceptible to attacks that could manipulate data. For instance, a malicious indexer could provide incorrect transaction histories or balances. Additionally, the concentration of indexing power raises concerns about the potential for Sybil attacks. To mitigate risks, some works <cit.> utilize decentralized indexing solutions, but they are still in infancy.








Congested mempool. The popularity of Bitcoin inscriptions has introduced significant congestion to mempool. Additionally, the proposal of BitVM facilitates more complex smart contracts on Bitcoin, which further increases network congestion. The mempool serves as a staging area for valid but unconfirmed transactions, and its size reflects the network’s congestion level <cit.>. A congested mempool indicates a high volume of transactions waiting to be processed, which inherently leads to longer confirmation times and increased transaction fees. For miners, this congestion can be beneficial as it increases the fees they earn per block mined. However, for regular users, this translates into higher costs and delays, making Bitcoin less efficient for everyday transactions. Therefore, optimizing Bitcoin’s network efficiency while preserving its programming functionality is a critical challenge. Researchers could investigate more efficient transaction validation methods or develop new smart contract frameworks that minimize on-chain data storage to manage mempool congestion.





























§ CONCLUSION





We present the first systematic study of Bitcoin L2 solutions by collecting and evaluating existing projects. We further propose and apply a security reference framework to assess the identified design patterns within each selected project. We conclude that L2 brings Bitcoin functionalities but also introduces increased complexity and additional attack vectors.


















unsrt











§ TECHNICAL COMPONENTS




 §.§ UTXO Model


A Unspent Transaction Output (UTXO) represents a specific amount of Bitcoin that has been received but not yet spent by the owner. Essentially, it is the cryptocurrency equivalent of cash in hand, where each UTXO can be thought of as an individual bill or coin.

UTXO represents a discrete amount of Bitcoin that remains constant until it is spent. The association with a Bitcoin address denotes ownership and the right to spend, while the transaction ID provides a traceable history, linking the UTXO back to its origin in the blockchain.


Working mechanism. The process of creating and spending UTXOs is fundamental to how Bitcoin transactions are structured. The model allows the miners to verify transactions without tracking account balances. Instead, miners check whether UTXOs being spent are valid and unspent. 



  * Creation of UTXOs: UTXOs are generated through Bitcoin transactions. When a sender A sends an amount x BTC to a recipient B, this amount x becomes a UTXO associated with B’s address. Mathematically, if the transaction T is made, then:
𝖴_𝖡 = T_𝖠 → 𝖡(x),
where 𝖴_𝖡 is the new UTXO for recipient B.


  * Spending UTXOs: To create a new transaction, a sender's wallet selects (via certain coin selection algorithms <cit.>) one or more UTXOs as inputs to cover the transaction amount y. If the total value of the selected UTXOs (∑𝖴_𝗂) exceeds the amount y, the excess amount z = ∑𝖴_𝗂 - y is sent back to the sender as a new UTXO, often referred to as "change". This can be expressed as:
𝖭𝖾𝗐 𝖴_𝖼𝗁𝖺𝗇𝗀𝖾 = T_𝖡 → 𝖡(z),
where T_𝖡 → 𝖡 is the transaction from the sender back to themselves.


  * Transaction inputs & outputs: A Bitcoin transaction consists of inputs and outputs, where inputs I are UTXOs being spent, and outputs O create new UTXOs for the recipients. If a transaction T consumes n inputs to produce m outputs, it can be represented as:
T(I_1, I_2, …, I_n) → (O_1, O_2, …, O_m),
where I_n are the UTXOs used as inputs and O_m are the new UTXOs created. This cycle of consuming old UTXOs to create new ones continues with each transaction.















 §.§ Merkle Tree

A Merkle tree, also known as a hash tree, is a cryptographic concept employed in Bitcoin to ensure data integrity. It organizes data into a binary tree structure, where each leaf node represents the hash of transaction data, and each non-leaf node is the hash of its immediate child nodes. 





Cryptographic hash functions. SHA-256 (Secure Hash Algorithm 256-bit) <cit.> is the hash function used to generate transaction hashes and block hashes in Bitcoin. It produces a 256-bit (32-byte) hash value, typically rendered as a hexadecimal number, 64 digits long. In addition to SHA-256, Bitcoin uses the RIPEMD-160 <cit.> hash function as part of the process to create Bitcoin addresses. After a public key is generated from a private key, it is hashed using SHA-256, and then the result is hashed again using RIPEMD-160. This produces a shorter hash used, along with a network byte and a checksum, to form the Bitcoin address. 




Binding and hiding. The binding property of a Merkle tree is rooted in the cryptographic hash functions used to generate the tree. Specifically, altering any single transaction T_i in the block will change its corresponding hash 𝖧(T_i), thereby altering the hashes of all parent nodes up to the Merkle root R. This property can be expressed as:
R = 𝖧(𝖧(… 𝖧(𝖧(T_1) 𝖧(T_2)) 𝖧(𝖧(T_3) 𝖧(T_4))) …),
where 𝖧(·) represents the cryptographic hash function, and  denotes concatenation. This recursive hashing ensures that the Merkle root R is a binding commitment to the exact set and order of transactions in the block.

Although the Merkle root and the associated Merkle path can be used to verify the inclusion of a transaction T_i, they do not reveal the specifics of the transaction. For example, to prove the inclusion of a transaction T_1 in the block, we provide the hash of T_1 and the necessary hashes in the Merkle path, such as 𝖧(T_2), 𝖧(𝖧(T_3) 𝖧(T_4)), and 𝖧(𝖧(𝖧(T_5) 𝖧(T_6)) 𝖧(𝖧(T_7) 𝖧(T_8))), which allows us to reconstruct the Merkle root. If the reconstructed Merkle root matches the known Merkle root R, we can confirm that T_1 is part of the block without knowing all transactions.




 §.§ Segregated Witness (SegWit)

The Bitcoin network consistently verifies a new block approximately every 10 to 15 minutes, with each block encompassing a specific number of transactions. Consequently, the size of these blocks directly influences the number of transactions that can be confirmed within each block. SegWit, representing one of the key protocol upgrades <cit.>, was proposed to address the scalability issue by changing the way transaction data is structured and stored in the blocks. 




[caption=Transaction Details, basicstyle=, breaklines=true]
# Input:
- Previous tx: fd9...b33a
- Index: 0
- scriptSig: 304...8932
# Output:
- Value: 5000000000
- scriptPubKey: ... OP_CHECKSIG

——-after Segwit——-

# Input:
- Previous tx: fd9...b33a
- Index: 0
- scriptSig: (empty)
# Output:
- Value: 5000000000
- scriptPubKey: ... OP_CHECKSIG
# Witness Data:
- Input 0
- ScriptSig: 304...8932






    language=,
    basicstyle=,
    keywordstyle=, 
    morekeywords=scriptSig, 
    morekeywords=[2]scriptPubKey, 
    keywordstyle=[2], 



SegWit separates signatures  from the transaction data. A SegWit transaction (above listing) consists of two main components: the original transaction structure without the signature (i.e., 𝖲𝖼𝗋𝗂𝗉𝗍𝖲𝗂𝗀) and a separate witness section containing the signatures and scripts. The witness information is still transmitted and stored in the blockchain but is no longer a part of the transaction's txid calculation. The txid is now calculated without including the witness data. The change means that the txid remains constant even if the signature data is altered (i.e., fixing transaction malleability <cit.>). Secondly, SegWit introduces a new concept called block weight, which is a blend of the block's size with and without the witness data. The maximum block weight is set to 4MB, while the size of the non-witness data is still capped at 1MB.







 §.§ Taproot Upgrade


The Taproot upgrade cover three BIPs: Schnorr signatures (BIP340), Taproot (BIP341) and Tapscript (BIP342). The core idea of upgrade centers around BIP341 <cit.>, which is to combine the strengths of Merkelized abstract syntax trees (MAST) and Schnorr signatures by committing a single Schnorr public key in the output that can represent both a single public key spend and a complex script spend. It introduces a new Taproot output (SegWit version 1) that includes a signature, a control block, and a script path. Moreover, it also specifies the rules for spending the Taproot output, which can be either a key-path spend (using a single signature) or a script-path spend (using the scripts committed to in the MAST structure).

To further illustrate the working principle of Taproot, we consider a situation where a Bitcoin address is controlled by three parties: A, B, and C. We created a Taproot output address that allows for spending conditions. The spending conditions are as follows: (i)
any two of the three parties (A, B, C) can jointly spend the funds; and (ii) if the funds are not moved for a year, party A can unilaterally spend them (a time-lock condition). 

Initially, the parties aggregate their individual public keys (pk_A, pk_B, pk_C) to form a single Schnorr aggregated public key P. This aggregate key, alongside the Merkle root derived from two hashed scripts: Script1 adds up the valid signatures (ensuring that at least two signatures are provided); Script2 uses 𝖮𝖯_𝖢𝗁𝖾𝖼𝗄𝖲𝖾𝗊𝗎𝖾𝗇𝖼𝖾𝖵𝖾𝗋𝗂𝖿𝗒 to enforce the time-lock (guaranteeing that the script can only be executed after a year). Then, it checks the signature from A, and forms the Taproot output. When it's time to spend, the parties can opt for a key-path spend using P for a private transaction, or a script-path spend, revealing the chosen script and its corresponding Merkle proof to fulfill specific conditions. 





§ COMPENDIUM OF PROJECTS



 §.§ Statistical Websites and Our Results



We source the projects from four major statistical websites that extensively catalog a large number of registered projects. 




  * Rootdata <cit.> provides a comprehensive ecosystem map that categorizes various projects within the Bitcoin Layer 2 space. It offers detailed listings, including projects in different stages of development, such as testnet and upcoming. 


  * BTCEden <cit.> compiles active and upcoming Bitcoin L2 projects. It presents data in a tabular format, highlighting the project's name, the type of L2 solution (e.g., ZK Rollup, Side Chain), its purpose, and the total capitalization. 


  * L2.watch <cit.> offers a detailed overview of L2 projects, including those in pre-testnet, testnet, and mainnet stages. 


  * EdgeIn.io[To ensure a comprehensive search on EdgeIn.io, we employed a set of targeted keywords that are pivotal to our research. We utilized the search functionality with the keyword "Bitcoin" combined with various terms related to Layer 2 technologies, such as "layer2, l2, sidechain, bitvm, client-side, rollup, state channel". This strategic approach yielded 139 companies that align with our research focus, providing a broad spectrum of L2-related projects within the Bitcoin ecosystem.] <cit.> is a platform that provides business data and knowledge for the Web3 industry, connecting users with a vast network of Web3 organizations. 






Following the data collection method, we obtained an initial list of 335 projects (the second column in Table <ref>). We then conducted a deduplication process, refining our dataset to a list of 126 unique Bitcoin L2 projects. This dataset was divided according to the projects’ developmental and fundraising stages (illustrated in Fig. <ref>). 

In the Mainnet Stage, there were 33 projects, of which 18 received funding and 25 had complete documentation. The Testnet Stage included 25 projects, with 11 securing funding and 14 having comprehensive documentation. In the Pre-testnet Stage, 48 projects were identified, 8 of which obtained funding, while 10 had complete documentation. Lastly, the Initiated Stage consisted of 20 projects, with 2 receiving funding and only 1 having complete documentation.





While applying our second round of filtering process, we finally reported 40 projects by removing projects that lacked sufficient documentation, community engagement, or a clear path to Mainnet deployment.








    0.95
(RQ1) Finding 1 (State-of-the-art projects): Mainnet Stage (33 projects): Among these, 18 projects received funding, and 25 had complete documentation. Testnet Stage (25 projects): Within this group, 11 projects were funded, and 14 had comprehensive documentation. Pre-testnet Stage (48 projects): 8 projects obtained funding, and 10 had complete documentation. Initiated Stage (20 projects): 2 projects obtained funding, and 1 project had complete documentation.
    
    




















 §.§ BitVM-based Solutions



(1) Bitlayer: Building on the foundation of BitVM (also using NAND gates, see Fig. <ref>), BitLayer <cit.> extends the Turing completeness of smart contracts on Bitcoin by introducing enhanced architectural components. Specifically, BitLayer incorporates a more sophisticated state management system that allows for the execution of complex logic without altering the core Bitcoin protocol. This is achieved through an implementation of Taproot and Schnorr signatures, which enables more efficient execution of multi-party contracts and off-chain computations. 



(2) ZKByte <cit.> builds upon the principles of BitVM by integrating ZKPs into the Bitcoin L2. It introduces a ZKP-enabled validator that verifies the state transitions of the blockchain without exposing sensitive data. This validator leverages the UTXO model to track and manage states across the main network and L2 network. Additionally, ZKByte incorporates a trusted oracle system, which validates the correctness of UTXO inputs and outputs and ensures that script execution adheres to the L2 protocol.


(3) Bitstake <cit.> leverages the BitVM for implementing PoS protocols. Embedding Permissioned Optimistic Bridge, Bitstake enables dynamic participation through staking, where stakeholders can actively engage in verifying and managing transactions over the bridge. Bitstake also enhances BitVM's security model by implementing a challengeable operator environment. In this setup, validators can dispute potentially fraudulent transactions within predefined challenge periods.



(4) Citrea <cit.> extends the functionality of BitVM by implementing a ZK Rollup architecture on the Bitcoin network. Technically, Citrea has introduced the concept of execution slices, where thousands of transactions are batch-processed and validated on the Bitcoin mainchain using a compact ZKP. Additionally, Citrea introduces a bi-directional anchoring mechanism that allows seamless interaction between Bitcoin as a settlement layer and its L2 environment, where more complex smart contracts can be executed.




(5) SataoshiVM <cit.> advances the BitVM framework by adopting the Bristol format for its logical gate circuit structure, which simplifies the circuit’s complexity. While BitVM requires multiple rounds of interaction to identify specific data discrepancies, SatoshiVM introduces a more streamlined approach with a single round of non-interactive on-chain verification. This method allows validators to observe commitment values and verify the corresponding off-chain data without continuous interaction. If any discrepancies are detected, validators can immediately identify these errors and penalize the proposer by transferring their Bitcoin UTXO.







 §.§ Rollups



∙ Zero-knowledge rollups




(1) B² Network <cit.> has implemented a hybrid model resembling a blend of zk and optimistic features. This network architecture is structured into two distinct layers: the rollup layer and the data availability layer. The Rollup layer employs the zkEVM system, responsible for sorting, packaging transactions, and generating zero-knowledge proofs. Meanwhile, the DA layer offers a decentralized storage solution, where off-chain storage nodes conduct zk validations and inscribe Rollup data into Bitcoin’s Ordinals script. Given that Bitcoin L1 lacks native smart contract validation, B² Network has introduced a fraud-proof challenge mechanism akin to Optimistic Rollups. This mechanism allows challengers to challenge the commitment to zkp verification within a specified period. If a challenge is upheld, the Rollup reverts the transactions, and the challenger is rewarded with assets locked by the node. Conversely, if no challenge occurs or the challenge fails, the Rollup receives final confirmation.


(2) Bison <cit.> employs the ZK-STARK rollup on Bitcoin, conceptualized to operate as a sovereign rollup. Bison introduces a Bison OS system composed of the sequencer and the prover. The Sequencer is responsible for collecting and ordering user transactions, while the Prover leverages STARK technology to generate ZKPs. A key improvement in Bison’s approach is its support for client-side verification, where users can directly download and verify ZK proofs independently.



(3) Tuna Chain <cit.> leverages zk-Rollups to bundle multiple transactions into single batches that are validated on the Bitcoin main network. It employs ZK proofs for off-chain computations and uses Taproot and Bitcoin Script to verify contracts on-chain without altering Bitcoin's consensus rules. Additionally, it uses native BTC as gas for EVM transactions, integrating Bitcoin's value anchoring with Ethereum's programmability to enable application development.


(4) BL2 <cit.> builds on zk rollup technology to enhance Bitcoin’s scalability, implementing a dual-layer architecture. The Rollup Layer processes transactions off-chain using a zkEVM system, which aggregates these transactions and generates ZPKs for validation. Unlike traditional rollups, BL2 introduces the Celestia Data Availability Layer, where batch data and zk proofs are stored across decentralized nodes. This setup allows zk-proof verifiers and Bitcoin committers within the BL2 network to validate transactions before committing them to the Bitcoin blockchain.



(5) Sovryn: <cit.> introduces an architecture that combines BOB (Bitcoin Optimistic Bridge) with zk-rollup technology through BitcoinOS. BOB enables the seamless interaction between Bitcoin and Sovryn’s sidechain, operating on Rootstock by locking BTC on the Bitcoin main chain and releasing RBTC on the sidechain. Sovryn leverages zk-rollups to aggregate and process transactions off-chain. These transactions are then compressed into zk-proofs and periodically settled on the Bitcoin mainnet.


(6) Melin Chain: Building on the zk-rollup foundation, Merlin Chain <cit.> compresses multiple transaction proofs into compact batches that are submitted to the Bitcoin network as a single transaction. Beyond the standard zk-rollup process, Merlin Chain integrates a decentralized oracle network, which serves to validate off-chain data and ensure its accuracy before inclusion in the rollup. 



(7) LumiBit <cit.> utilizes the ZK scheme of Halo2 to explore a L2 scaling solution for Bitcoin. As a ZK-rollup, LumiBit leverages Bitcoin as its Data Availability layer. ZK proofs are inscribed on the Bitcoin network and verified by open-source clients, allowing users to access and verify the latest off-chain states. Unlike other ZK-rollups, LumiBit's prime feature lies in the distinctive use of Halo2 scheme and KZG commitments to reduce verification costs. Additionally, LumiBit is building a Type 2 ZK-EVM with its universal circuit design, ensuring compatibility with the Ethereum ecosystem. This PoS-based security model requires participants to stake BIOP tokens, which incentivizes proper block generation and validation.



∙  Optimistic rollups



(1) Biop <cit.> integrates the Optimistic Rollup protocol with a PoS consensus algorithm, creating a system known as BiopOS. In this setup, Sequencers are tasked with aggregating and packaging transactions into blocks, which are then submitted to the Bitcoin mainnet for verification. Validators are responsible for monitoring the Sequencers’ actions and can submit fault proofs if discrepancies are detected.



(2) Rollux <cit.> is a L2 scaling protocol built on Bitcoin and Syscoin, leveraging Optimism Bedrock to provide EVM equivalence. It uses optimistic rollups, batching transactions off-chain, and then submitting them to Syscoin for finality. Key components include the Canonical Transaction Chain (CTC) for transaction ordering, the State Commitment Chain (SCC) for state root proposals, and Bridge contracts for L1-L2 communication. The current system relies on a centralized sequencer but plans to decentralize this role.


(3) BOB <cit.> employs EVM to facilitate smart contract execution, leveraging Optimistic Rollup to batch process transactions off-chain before submitting them to Ethereum for final settlement. BOB’s integration of Bitcoin’s Rust libraries via the RISC Zero zkVM allows for off-chain execution of Rust programs. These off-chain computations are then verified through zk-proofs, which are validated within EVM contracts.


(4) BeL2 <cit.> integrates Bitcoin with Elastos SmartWeb technology to enhance scalability and programmability. Utilizing optimistic rollup technology, BeL2 batches transactions off-chain and periodically submits them to the Bitcoin mainnet, leveraging Elastos’ merged mining for security. Additionally, a relayer mechanism is used for fraud prevention, staking deposits as collateral. 



(5) Hacash.com <cit.> is designed to support real-time settlement using a multi-layered architecture for Bitcoin. It includes three layers: Layer 1 features ASIC-resistant mining and support for multi-signature transactions; Layer 2 operates as a channel chain settlement network enabling high transaction throughput by allowing multiple off-chain transactions with only final balances submitted on-chain; and Layer 3 serves as an application ecosystem scaling layer, supporting rollup technology and multi-chain protocols.


(6) Rollkit  <cit.> is a modular framework for sovereign rollups that utilizes Bitcoin for data availability. Rollup sequencer nodes aggregate transactions into blocks and post them to a data availability layer like Celestia for ordering and finalization. Full nodes execute and verify these blocks, and propagate fraud proofs in optimistic rollup setups, while light clients verify proofs and authenticate state queries. Rollkit integrates with Cosmos SDK via an enhanced Application BlockChain Interface and utilizes Taproot transactions on Bitcoin for DA. 





 §.§ Sidechains



∙ Federated consensus sidechains



(1) Liquid Network <cit.> introduces a Federated Sidechain Consensus (FSC) model, which uses a consortium of blocksigners and watchmen instead of Bitcoin’s traditional PoW. The network employs a two-way peg system, allowing the transfer of Bitcoin to and from the sidechain, where Bitcoin is converted into Liquid Bitcoin. Additionally, it uses Confidential Transactions to encrypt transaction details and a one-minute block time to reduce confirmation delays.

∙ Merged-Mined sidechains




(1) Rootstock (RSK) <cit.> is designed to bring Ethereum-compatible smart contracts to the Bitcoin ecosystem. It uses RBTC, a token pegged 1:1 to BTC, generated through merged mining. RSK employs a two-way peg system facilitated by Powpeg, an autonomous multi-signature management bridge that involves reputable companies like Xapo, Bitpay, and BitGo. This bridge allows seamless transfer of BTC between the main chain and the RSK sidechain.  




∙ PoX-based sidechains



(1) MAP Protocol <cit.> operates similarly to PoX-based sidechains as it integrates a mechanism for verifying cross-chain transactions. However, instead of relying on traditional PoX, it utilizes a combination of ZK-proof technology and light clients to achieve decentralized interoperability across multiple blockchain networks.


(2) Stacks <cit.> extends Bitcoin’s functionality by enabling Proof of Transfer while leveraging Bitcoin’s security. It ties the security of Stacks directly to Bitcoin by anchoring each Stack block to a Bitcoin block. Miners are rewarded in Stacks’ native token for their BTC commitments.


(3) Mintlayer <cit.> utilizes a PoS consensus mechanism, where participants stake ML tokens to become validators and block producers. Each Mintlayer block references a Bitcoin block, using the Bitcoin block hashes as a source of randomness to select block producers. The network also employs a Dynamic Slot Allotment system to randomly select block signers who validate and sign new blocks.


(4) BounceBit <cit.>’s PoS-based sidechain mechanism involves validators staking both BTC and BounceBit’s native token BB. This staking process secures the network and enables validators to produce new blocks. Users can convert BTC to BBTC and stake it on the BounceBit platform to earn rewards. The system integrates both CeFi and DeFi elements, allowing for funding rate arbitrage and the creation of on-chain certificates for restaking and mining. 


(5) Libre <cit.> operates using a Delegated proof-of-stake (DPoS) consensus mechanism. It integrates with Bitcoin via non-custodial wrapping (pegged assets) and the Lightning Network, providing seamless on-and-off ramps for Bitcoin users. This design allows Libre to process over 4,000 transactions per second with zero transaction fees.


(6) BitReXe <cit.> operates as a PoS-based sidechain. It uses a unique approach by incorporating the PREDA programming model to scale out general smart contracts within multi-VM blockchain systems. Validators on the BitReXe network stake RXBTC (a token pegged to Bitcoin) to validate transactions and produce new blocks.


(7) BEVM <cit.> is an EVM-compatible sidechain solution that integrates the Taproot consensus mechanism. The Taproot consensus is a cornerstone of BEVM's architecture, combining Musig2 for secure multi-signature schemes, a BFT PoS network of Bitcoin SPVs for decentralized verification, and the Signal Protocol for encrypted, secure communication between nodes. Additionally, by using native BTC as gas, BEVM lowers barriers for Bitcoin holders to participate in L2 transactions, while its full EVM compatibility invites developers to leverage existing tools and languages.




 §.§ Client Side + UTXO



(1) RGB <cit.> leverages CSV and the UTXO model to create a scalable method for issuing and managing assets on the Bitcoin network. It initiates with an asset issuer creating a new asset and generating a unique one-time seal along with a cryptographic commitment on their client. This commitment is then embedded within a transaction's UTXO, anchoring the asset to the blockchain. Recipients verify the asset's legitimacy by examining the commitment against the one-time seal. Upon transfer, the old seal is invalidated, and a new set of seal, commitment, and transaction data are recorded on the Bitcoin network, ensuring an immutable transaction history.



(2) RGB++ <cit.> combines the RGB protocol with UTXO-based public blockchains such as CKB, Cardano, and Fuel, utilizing these platforms as verification and data storage layers for RGB assets. This approach shifts data validation tasks from the user to the third-party platforms, replacing client-side validation with decentralized platform verification, provided users trust these blockchains. The protocol achieves compatibility with the original RGB through the concept of “isomorphic binding” where the extended UTXOs on chains like CKB or Cardano act as containers for RGB asset data, directly reflecting asset parameters on the blockchain. For instance, if Alice wants to transfer 30 out of her 100 RGB tokens to Bob, she generates a commitment and spends her UTXO on Bitcoin, while consuming the corresponding UTXO container on CKB, creating new containers for both Alice and Bob. This transaction is validated by the consensus mechanisms of CKB/Cardano, without Bob’s direct involvement. While this setup improves global verifiability and DeFi applications, it sacrifices privacy, requiring a trade-off between security and usability. If users prioritize privacy, they can revert to the traditional RGB mode. RGB++ also assumes trust in the reliability of the CKB/Cardano networks. Users can operate their RGB assets on these UTXO chains directly using their Bitcoin accounts, linking UTXO conditions to Bitcoin addresses, and can use “transaction folding” to reduce costs by batching multiple transfers into a single commitment.



(3) BiHelix <cit.> functions as a Bitcoin-native infrastructure that amplifies the capabilities of the Bitcoin network through several key mechanisms. It integrates the RGB protocol, which facilitates private and efficient transactions by allowing parties to reach consensus without the need for on-chain contract recording, thus keeping individual transaction histories and status data off-chain. The SLR (Security-Lighting-RGB) Protocol enhances interoperability by building upon the migration of Core Lightning's functionality to rust-lightning, thereby reinforcing the synergy between the RGB protocol and the Lightning Network. Additionally, BiHelix employs a set of socially consensus-driven nodes on the sidechain, using native economic incentives to draw in node service providers. 



(4) Bitlight Labs <cit.> develops infrastructure based on the RGB protocol and deploys a suite of applications on Lightning Network, including Bitswap (asset exchange) and the Bitlight (wallet). The project is featured for managing smart contracts with privacy and security through client-side validation, where data is controlled by “state owner” rather than being publicly accessible. It operates on Bitcoin transactions, potentially using the Lightning Network's off-chain capabilities, and allows for scripting with Blockstream's formally verified Simplicity language (claimed to be Turing complete).











(5) Bool Network <cit.> is a Bitcoin Verification Layer that integrates client-side verification within its L2 solution. The protocol designs a client-side verification process where transaction validation is performed collectively by distributed key management systems without relying on a central authority. Its Dynamic Hidden Committees (DHC) act as security guardians, ensuring cross-chain message integrity, while its public blockchain, Bool Chain, serves as an EVM-compatible ledger for recording committee activities and supporting future application development. Bool Network's client-side verification is secured by Ring VRF <cit.> (where a user generates a unique pseudorandom output and a proof of its correctness using their private key and a set of public keys, i.e., the “ring”). 




(6) Mercury Layer <cit.> represents an implementation of client-side verification within the Bitcoin ecosystem, focusing on statechain technology to enable efficient asset transfers. At its core, Mercury Layer operates through a system of blind co-signing and key updates, allowing for the instantaneous and cost-free transfer of Bitcoin UTXOs. The protocol emphasizes client-side verification by leveraging client software to perform all transaction operations and statechain validations, ensuring that the server remains unaware of transaction details and UTXO identities. This approach requires clients to actively verify partial signatures, manage backup transactions, and oversee key updates, thereby upholding the security of the statechain without relying on server-side control.







 §.§ State Channel (Fig.<ref>)
 


(1) Lightning Network <cit.> is a L2 scaling solution for Bitcoin that addresses the blockchain's limitations in transaction throughput and confirmation times by moving the majority of transactions off-chain. It operates through a network of payment channels, utilizing two primary smart contract mechanisms: the Recoverable Sequence Maturity Contract (RSMC), which facilitates secure allocation updates and dispute resolution, and HTLC, which enables the creation of timed, conditional transactions across multiple parties.

        




(2) OmniBOLT <cit.> extends Lightning Network's capabilities to facilitate smart asset transactions. Built on the BTC/OmniLayer network, OmniBOLT enables the circulation of OmniLayer assets through lightning channels, providing instant payments, cross-channel atomic swaps, and decentralized exchange functionalities. Its protocol suite, written in Golang, includes implementations for basic HTLC payments, atomic swaps of multiple currencies, and an automatic market maker with a liquidity pool for DEX. 



(3) Lnfi Network (formerly NostrAssets) <cit.> integrates Taproot assets and Satoshis, allowing users to send and receive these assets using Nostr’s public and private keys. Leveraging Lightning Network for settlement and security, NAP ensures high transaction throughput, minimal latency, and low fees through off-chain transactions. This integration enables near-instantaneous asset transfers, crucial for applications like micro-payments and real-time trading. 



(4) Ark Protocol <cit.> is designed to address the scalability limitations of Lightning Network. It allows users to send and receive payments without the need for incoming liquidity. Ark does not require the recipient to be online or interactive for the transaction to be completed. The protocol's lifting mechanism allows users to convert on-chain UTXOs into virtual UTXOs without reliance on third parties, and the redemption function allows to move funds back to the base layer.






 §.§ More




(1) Tectum <cit.> introduces SoftNotes, a L2 solution that enhances Bitcoin's scalability. SoftNotes are digital banknotes representing Bitcoin wallet ownership, facilitated by Tectum blockchain. Technically, SoftNotes operates on a bearer instrument model, allowing for off-chain transactions that are untraceable and anonymous, with cryptographic finality. Tectum's also includes a hybrid mode for transactions, a smart contract-based security model for handling BTC private keys, and the capability to represent and transfer NFTs.




(2) Nubit <cit.>, a Bitcoin data availability layer, introduces DAS solution to address the scalability challenge by allowing nodes to verify block data availability through random sampling rather than downloading entire blocks. DAS employs two protocols: the sampling protocol for verifying data availability through random chunk requests, and the decoding protocol for reconstructing the full block from verified chunks. The system involves three types of participants: validators who run the sampling protocol and sign block headers upon successful verification; full storage nodes that maintain the entire block and respond to chunk requests; and light clients who initiate sampling to ensure data availability.





(3) HyperAGI <cit.>, a Bitcoin L2 solution, focuses on decentralized, compute-intensive applications, particularly for Artificial General Intelligence (AGI) and metaverse integration. HyperAGI claims to support complex, high-demand tasks such as 3D rendering and AI computations. It achieves this by integrating a 3D pipeline-based Pinpoint protocol, which achieves computation verification in a decentralized manner. Additionally, HyperAGI employs a HyperTrust consensus algorithm that operates with the Graph Virtual Machine.



§ BITCOIN IMPROVEMENT PROPOSALS (BIPS)


We reviewed all existing BIPs (cf. Table <ref>) and captured the major ones (focusing on the final stage, as of Aug. 2024) for Bitcoin's basic design and development lineage.

This work references the following BIPs: 174/370/371 (PSBT), 141/144 (SegWit), and 340-343 (Taproot).































































































































