Overview

Bitlayer, a Bitcoin Layer 2 (L2) solution, extends the capabilities of Bitcoin by integrating a Turing-complete computational layer based on the BitVM paradigm. It addresses core challenges such as scalability, smart contract limitations, and transaction costs, thus enabling a more expansive ecosystem for Bitcoin applications.

Bitlayer’s approach combines the value of $BTC with the complex applications that can be built on top of a programmable layer supported by smart contracts.

With Bitlayer, developers can write and deploy complex smart contracts using their preferred language and toolchain. Applications of all kinds can be developed and supported similarly to other Layer 1 (L1) and L2 blockchains, adding more utility to $BTC by expanding the opportunity set and use cases.

Bitlayer Architecture

Bitlayer aims to significantly improve the verification process for L2 transactions by using optimistic execution while retaining the core integrity of Bitcoin. The architecture integrates elements such as transaction processing, verification, and asset bridging, all designed to optimize transaction handling and computational efficiency. Each component is critical in maintaining the transaction’s security and integrity from the L2 handling up to the L1 confirmation, ensuring a seamless and secure transaction lifecycle.

Transaction Processing

Transaction processing in Bitlayer involves a combination of a sequencer and a Layered Virtual Machine (LVM), both of which are integral to handling and executing transactions efficiently.

• Sequencer: The sequencer functions similarly to those in other L2 solutions, where its primary role is to collect cached transactions and sort them accordingly. It acts as the gateway for incoming transactions into the Bitlayer network, ensuring that they are processed in an orderly and efficient manner.
• Layered Virtual Machine: The LVM stands as the computational backbone of Bitlayer, responsible for executing smart contracts and generating the most recent states along with zero-knowledge proofs. These proofs are necessary for the verification process, as challengers use them to dispute the integrity of the execution results.

The unique component in this process is the LVM which offers a versatile and secure environment for executing smart contracts across different blockchain ecosystems. By bridging various frontend and backend technologies, LVM not only increases the platform’s appeal to developers but also boosts its capacity to handle the evolving demands of blockchain technology.

Layered Virtual Machine (LVM)

The LVM technology is designed to improve both the flexibility and security of executing contracts by supporting a variety of frontend smart contract types and backend zero-knowledge proof verifiers.

Frontend Smart Contract Support

LVM technology facilitates the integration of multiple frontend smart contract platforms such as EVM (Ethereum Virtual Machine) and CairoVM. This inclusion broadens the appeal to developers across different blockchain ecosystems, enabling them to utilize familiar tools and programming models for Bitcoin.

• EVM Compatibility: By supporting EVM, developers can seamlessly migrate and execute existing EVM-based smart contracts on Bitlayer. This compatibility allows for the utilization of a well-established ecosystem’s tools and contracts, thereby reducing the learning curve and accelerating adoption.
• CairoVM and Others: Similarly, by accommodating other smart contract environments like CairoVM, LVM extends its capabilities to support a wider range of programming solutions and application scenarios, making it an attractive platform for developers looking for versatility and robustness.

Future developments of this kind of technology will allow for additional integrations with other VMs, enabling all kinds of applications to be deployed on Bitcoin without any limitations. This is important for Bitlayer because it allows the protocol to be flexible for future adaptations and evolving blockchain standards.

Backend Zero-Knowledge Proof Support

On the backend, LVM incorporates various zero-knowledge proof generators such as ZK-STARKs and ZK-SNARKs (including well-known schemes like Groth16 and PLONK). These technologies are key for ensuring the integrity and privacy of computations without revealing underlying data.

• Optimization Opportunities: The inclusion of multiple zero-knowledge-proof technologies provides significant optimization opportunities for transaction verification processes. This aspect is particularly vital in enhancing the dispute resolution mechanisms within Bitlayer, ensuring transactions are not only processed efficiently but also securely.
• Future-Proofing: As blockchain technologies evolve, the need for more efficient and succinct zero-knowledge proofs becomes critical. LVM’s flexible design is prepared to integrate newer and more efficient proof systems as they develop, ensuring Bitlayer remains at the forefront of blockchain technology innovation.

Enhanced Computational Flexibility and Security

The dual approach of supporting diverse frontend contract types and robust backend-proof systems allows LVM to offer computational flexibility and enhanced security measures. This structure ensures that Bitlayer can handle a broad spectrum of applications and use cases, ranging from simple transactions to complex decentralized applications, all while maintaining high security and compliance standards.

Transaction Verification

Transaction verification within Bitlayer is facilitated through a zero-knowledge-based optimistic mechanism that involves both provers and challengers, ensuring that all transactions adhere to network rules and are valid.

• Prover: The Prover’s role is to submit L2 transactions and their corresponding states of execution to the Bitcoin blockchain. In events where the transaction’s integrity is challenged, the Prover is also responsible for revealing the zero-knowledge proofs on-chain to demonstrate the correctness of the transactions.
• Challenger: On the other side of the equation, the Challenger monitors the execution results submitted by the Prover. This involves a thorough examination of the states of execution and the associated zero-knowledge proofs. Suppose any malicious activity or discrepancies are detected. In that case, the Challenger initiates a challenge process to generate and submit fraud proofs, including any invalid zero-knowledge proofs, to the L1 chain for resolution.

The relationship between the Prover and the Challenger has a significant influence on the protocol. Their tasks are interconnected and their interaction immediately affects the verification of transactions.

Asset Bridge

Bitlayer is connected to multiple blockchains including Bitcoin, and EVM chains through multiple bridges. The Bitcoin bridge is built with Coinbase and Sinohope has the key MPC custody platforms. The EVM bridge is built with the Polyhedra team. Bitlayer also supports bridges that connect with centralized exchange (CEX) allowing users to withdraw assets from CEXes directly to Bitlayer wallet addresses.

The use of a dual-channel two-way peg asset bridge includes the OP-DLC (DLC with optimistic mechanism) and BitVM bridge, each tailored to meet different security and operational needs of the users.

Dual-Channel Architecture:

• OP-DLC Bridge: This channel allows users to lock $BTC in a trustless and self-controlled manner. It integrates a novel challenge protocol to address potential collusion issues with oracles in the original DLC protocol, thus ensuring a higher degree of security and user autonomy.
• BitVM Bridge: Operates under a minimally trusted custodian scheme that requires a security level of only 1 of N, making it suitable for users who prioritize flexibility and speed over the stringent security measures of the OP-DLC channel.

The dual-channel approach not only diversifies the security options available to users but also boosts the scalability of the system, ensuring it can perform efficiently even under high demand.

Threat Model

The security model for the asset bridge assumes the solid security of the Bitcoin blockchain as a base layer. However, it acknowledges potential risks within the BitVM Federation nodes, which manage the bridge. The model allows for the scenario where an adversary could compromise up to n−1 of these nodes, with the system’s integrity still being maintainable as long as one node remains secure and operational.

Bridge Technology

The Bitlayer bridge is composed of several key components that satisfy both L1 and L2 users and their needs.

• BitVM Federation: This component provides security and decentralization from its operation. It acts as the verification network ensuring the secure execution of L2 transactions and stable operation of the bridge keeping. Nodes within the federation can join by depositing $BTC and play a dual role, also serving as oracles for the OP-DLC channel.
• DLC Components: These components manage user-controlled asset deposits and withdrawals through DLCs, requiring predefined CETs to handle the amounts involved, thus ensuring precise and flexible transaction management.
• L2 Smart Contracts: Including the bridge and light client smart contracts. The bridge contract is responsible for the issuance and destruction of $BTC assets on L2. The light client contract makes sure that the Bitcoin block header information is up-to-date whereas Bitlayer uses ZKP-based Bitcoin state proofs for that task. In addition, the light contract provides a Verify function to validate Bitcoin transactions through an SPV (Simplified Payment Verification), ensuring all L2 $BTC assets are issued in a trustless manner.
• Relayers: They play a vital role in maintaining the bridge’s operation by monitoring both Bitcoin and Bitlayer networks and updating the state of light client data on L2 with zero-knowledge proofs, ensuring continuous functionality of the asset bridge. When a bridge transaction occurs, the relayer sends it to either a smart contract or a BitVM Federation node for extra processing.

These components are necessary for the correct operation of the bridge. Every single one ensures the smooth execution of transactions and the security of the bridge.

Bridge Protocol

The bridge protocol outlines the lifecycle of transactions as they happen in the bridge including Peg-In and Peg-Out functions.

Peg-In Process: Users can lock $BTC using either the OP-DLC or BitVM bridge channels as seen in the graph below. Each channel supports different user needs in terms of speed and security. The transaction is verified through the latest Bitcoin block information and an SPV proof to confirm the legitimacy of the locking transaction. The process takes approximately 7 blocks to confirm for any user to mint on L2.

Peg-Out Process: Users submit withdrawal requests through their chosen channel. The process involves either direct withdrawals via BitVM or using a combined mechanism in the OP-DLC channel, which handles larger withdrawals and potential changes via BitVM. 

If a user deposited through the OP-DLC channel, then both options for withdrawing are available. If the initial deposit was through the BitVM channel (Option 2 on the graph) or without a Peg-In transaction, then the user is restricted only to withdraw via the BitVM bridge channel.

Specifics of the OP-DLC Peg-Out Channel:

Upon receiving an OP-DLC withdrawal request from a user, the BitVM Federation nodes access the CET’s manager to select an appropriate Conditional Execution Transaction (CET) output that matches the withdrawal request. A quorum of BitVM Federation nodes then collaboratively signs to generate the valid DLC signature for that selected CET.

Once the necessary signatures are broadcasted, the user immediately receives the corresponding $BTC from the selected CET output. The $BTC directed towards the BitVM Federation address is initially placed into a timelock script, safeguarding the funds for the user to challenge in the case of incorrect data. Only after the challenge period is over the $BTC will be transferred to the address. 

Challenges:

• Challenge 1: If the BitVM Federation members involved in generating the oracle signature provide incorrect data, which results in the user receiving less $BTC than entitled to, the user has the right to initiate a challenge. This challenge allows the user to claim the $BTC that was locked by the oracle members.
• Challenge 2: Contrarily, if the BitVM Federation members act in cooperation with the user, enabling them to receive more $BTC than they should, it adversely impacts the integrity of the entire federation. In such instances, the honest members of the BitVM Federation are empowered to initiate a challenge against the conspiring members, to reclaim the improperly allocated $BTC.

Bridge Security

In the context of the Bitlayer asset bridge, security is paramount, ensuring both the safety of transactions and the liveness of the network. This section outlines how the Bitlayer bridge upholds these critical properties, even within the complex threat model previously discussed.

Peg-In Bridge Security

For the Peg-In process, the security of the OP-DLC and BitVM bridge channels is primarily ensured through the integrity of the Light client, which utilizes zero-knowledge proofs to verify transactions. This system ensures that the minting of equivalent $BTC on the Bitlayer network only occurs following the verification of a valid locking transaction on the Bitcoin network.

Peg-Out Bridge Security

For the Peg-Out process, there is a different approach regarding the security of the two bridge channels.

For the OP-DLC Channel: This channel combines the roles of oracle and liquidity management under the BitVM Federation. The safety of the OP-DLC channel during the Peg-Out process is safeguarded by introducing two distinct challenge games:

• Game 1: Targets the scenario where the oracle allocates more assets to Alice than entitled. If Bob is adversely affected by such an allocation, he is incentivized to initiate a challenge to recover his losses, ensuring that the oracle operates correctly.
• Game 2: Addresses potential collusion between Alice and the oracle to allocate more assets to Alice than warranted. An honest federation member can challenge this to protect the federation’s integrity and penalize any fraudulent activity.

These challenge games are integral to maintaining operational integrity and are supported by the novel Challenge Protocol, ensuring an efficient and secure transaction verification process.

For the BitVM Channel: The security for the BitVM channel relies on there being at least one honest node within the BitVM Federation. The scenarios considered include:

• Case 1: An honest bridge operator correctly processes transactions, advancing $BTC to the user and later reclaiming it from the federation’s multi-signature wallet without any discrepancies.
• Case 2: A malicious bridge operator attempts to reclaim more than the advanced amount. An honest node would detect this and initiate a challenge to correct the discrepancy and penalize the malicious behavior.

Both models heavily rely on integrity to secure the operation of the bridge protocol.

Liveness Analysis

Liveness within the Bitlayer bridge is important to ensure that the system remains operational even under potential node failures or other issues:

• Peg-In Process: The liveness of the Peg-In process is maintained as long as at least one relayer, which is part of an open-source and permissionless system, is operational. This ensures that the bridge can continue to process transactions even if parts of the system fail.
• Peg-Out Process: The liveness of the Peg-Out process varies between the two channels:
  • BitVM Bridge Channel: Strong liveness is maintained with just one honest node being operational, capable of acting as both the relayer and the bridge operator.
  • OP-DLC Bridge Channel: Achieves weak liveness, requiring at least t (t ≤ n) honest nodes to be operational. Since the DLC signatures need t nodes for a valid signature, the system’s liveness is dependent on having these t nodes active.

Bitlayer Execution Protocol

In the design of the Bitlayer protocol, advanced mechanisms have been integrated that connect BitVM zero-knowledge proofs with an optimistic mechanism to execute transactions off-chain and validate Bitcoin on the main network without interfering with it at any stage. The essence of this design is the creation of a Turing-complete, L2 smart contract platform that can validate complex computations on the Bitcoin blockchain which is not possible currently, vastly extending its capabilities beyond simple payment functionalities.

Zero-Knowledge & Optimistic Approach

Bitlayer uses a similar optimistic execution mechanism to that used in optimistic rollups such as Arbitrum and Optimism. This mechanism inherently assumes all transactions within a batch are valid unless proven otherwise by a network participant. This presumption allows for swift on-chain processing while maintaining the ability to revert transactions when their invalidity is proved by any participant, which adopts a 1-of-n security model.

By also integrating Zero-Knowledge proofs (ZK-Proofs), Bitlayer further optimizes the challenge process, making it more cost-effective. ZK-Proofs provide a path for Bitlayer to verify the correctness of transactions without revealing any underlying data about those transactions, which improves privacy and security. These proofs allow the network to validate complex operations and state transitions without having to publish the details on-chain, thus preserving bandwidth and maintaining confidentiality. 

This hybrid approach significantly enhances throughput, reduces costs, and preserves the security and decentralization of the blockchain. 

Processing Framework

The optimistic execution mechanism is structured around several core operations in this order:

1. Transaction Batching: Transactions are batched and processed off-chain.
2. Zero-Knowledge Proof Generation: Concurrent with transaction execution, ZK-Proofs are generated to affirm the legitimacy of state transitions.
3. Submission and Challenges: Batches, along with their state and proofs, are submitted to the blockchain in a compressed format to lessen the on-chain footprint. A challenging period follows where participants can submit fraud proofs if discrepancies are detected.
4. State Rollbacks: When fraud proofs are validated, this triggers rollbacks of the state to rectify any errors and impose penalties on the wrongdoers.

Data Availability

The challenge process within the optimistic execution mechanism of Bitlayer depends on the transaction initiator revealing transactions and their current states. For this reason, Bitlayer requires a data availability solution that is not only secure and reliable but also decentralized. As of now, Bitlayer uses Bitcoin’s blockchain, which is recognized for its security, and decentralized consensus, to ensure data availability. To accommodate the specific requirements of Bitcoin’s blockchain, the data submitted is compressed and divided into multiple transactions, structured similarly to Bitcoin inscriptions. These transactions are then processed by validators who identify the inscriptions and reconstruct the original data.

Bitlayer is exploring potential integrations to reduce operational costs by adding different data availability solutions such as Celestia and Data Availability (DA) Committees. These solutions aim to maintain the existing standards of security, reliability, and decentralization in a more cost-efficient manner. 

Rollup Proof Generation

The Bitlayer protocol features a proof generation system composed of five circuits:

• Execution Circuit: Processes transactions and state transitions, and encodes Bitlayer’s state transition logic, providing proof of accuracy for state transitions.
• Aggregation Circuit: Aggregates multiple proofs into a singular batch proof, facilitating batch processing.
• Bitlayer Block Derivation Circuit: Integrates with the Bitcoin chain to derive Bitlayer blocks from Bitcoin block hashes, creating proofs for block derivation.
• Bitcoin Block Finalization Circuit: This circuit takes Bitcoin’s finalized block hash and generates proof of finalization, ensuring the blockchain’s integrity.
• Rollup Circuit: Links proofs from all circuits, producing a comprehensive final proof eligible for challenges using the BitVM.

The five circuits and their operation can be seen on the graph below.

Every transaction or state transition from the Execution Circuits goes through the Aggregation Layer that batches them into one single proof to be pushed to the Bitlayer Rollup Circuit that links all the proofs from all the circuits.

Challenge Protocol

Going deeper into Bitlayer’s architecture there is the Challenge Protocol responsible for the integrity and accuracy of transactions across the BitVM framework. 

In its initial form at earlier stages of the BitVM (BitVM1), the Challenge Protocol employed a binary method for challengers to identify errors in the instructions provided by the Prover. If an error was detected, the Prover would be unable to execute the instruction correctly, nor could they retrieve their staked Bitcoin. Instead, the Challenger had the opportunity to unlock the staked amount after the timelock period ended, ensuring that errors were accountable and stakes were properly managed.

The subsequent iteration, BitVM2, revolutionized the challenge process by enabling the Prover to commit the entire program in segments directly to the leaf nodes. This change significantly enhanced the efficiency and breadth of the verification process. The challenge game of Bitlayer still uses the BitVM2 challenge system but the correctness of a STARK verifier’s execution is challenged by the introduction of a Bitcoin-Friendly FRI, which bypasses the need to simulate MerklePath verification in Tapscript, leveraging the Taptree’s inherent characteristics instead. This adaptation reduced complexity and increased the directness and speed of verifications.

Commitments

Commitments play a foundational role in the data processing of Bitlayer’s Challenge Protocol. These commitments are important in structuring the computing process and are seamlessly integrated into Bitcoin scripts, enhancing the blockchain’s computational capabilities.

There are three types of commitments:

• Bit Commitment: Derived from Lamport signatures, bit commitment involves the use of two hashes, designated as hash0 and hash1, each paired with a corresponding preimage (preimage0 and preimage1). The prover can assert the value of a bit—either “0” or “1”—by revealing the appropriate preimage that matches one of the hashes. This type of commitment allows for setting variable values across various scripts and Unspent Transaction Outputs (UTXOs), thereby extending the functionality of Bitcoin’s VM through the distribution of transaction processing.

• Custom Gate Commitment: This form of commitment pertains to the establishment of custom gates that can emulate any computable function. A custom gate commitment is constructed from any combination of inputs and outputs, anchored by bit commitment, and integrated within any standard Bitcoin script. This versatility allows for the representation and execution of complex computational functions within the blockchain infrastructure.

• Circuit Commitment: Bit Commitment also known as Copy Constraint, can utilize gate and copy constraints to articulate complex computations. For instance, a comprehensive program could be decomposed into sequential operations, each facilitated by a custom gate designed for that specific function. By breaking down these operations, Bitlayer enables the distribution of complex computations across multiple nodes, thereby equipping Bitcoin with enhanced ZK Verifier capabilities.

Challenge Game

The Challenge Game represents a mechanism for verifying the integrity and validity of transactions in an environment that still handles a substantial number of intermediate states through its STARK Verifier. 

Bitlayer continues to employ an optimistic execution approach while aspiring to integrate validity proofs into the Bitcoin blockchain. This approach is segmented into distinct phases, each designed to validate the transactions and protect the assets involved.

• Bet Phase:
  • The Prover initiates the game by sending 3 $BTC to the designated reveal-state address through Transaction 1 (Tx1). This marks the beginning of their claim on the computational process.

• Claim State Phase:
  • The Prover discloses the initial and final states of their claimed computational program by revealing the corresponding Bit Commitment in Transaction 2 (Tx2). Notably, Tx2 splits a 3 $BTC input UTXO into three separate output UTXOs, setting the stage for the subsequent phases.

• Awaiting Finalization Phase:
  • During this phase, the Prover waits for the timelock to expire before they can unlock the transaction. This unlocking also requires signatures from multiple Operators, who verify the Prover’s adherence to the protocol and the honesty of the constructed Taptree. The Operators pre-sign the transaction, ensuring that it is deterministic and linked directly to the Prover’s Pay-to-Public-Key-Hash (P2PKH) address. If any of the output UTXOs from Tx2 are consumed, it prevents the execution of the following transaction (Tx3), providing a method to initiate challenges.

Here’s what happens when a challenge occurs during the last phase.

• Challenge Initiation:
  • If there is any dispute over the state claimed by the Prover, a challenge can be initiated during the Awaiting Finalization Phase. This is done through Transaction 4, which consumes the UTXO required by Tx3, thus preventing its execution. This transaction allows any participant to launch a challenge by deploying 2 $BTC, facilitated by the SIGNHASH=SINGLE|ANYONECANPAY setup.

• Prover’s Response:
  • In response to the challenge, the Prover must reveal all intermediate states in Transaction 5 by consuming the 3 $BTC UTXO. This transparency is key to verifying the Prover’s claims.
• Outcome of the Challenge:
  • Verifier Wins: If discrepancies are found in the intermediate states, the Verifier can locate the corresponding unlock script within the current Taptree. Success in proving the fault allows the Verifier to win the challenge and earn a 1 $BTC reward, resulting from the transaction dynamics (3-2).
  • Prover Wins: If the Prover’s disclosed states are verified as accurate, the Verifier cannot pinpoint any faulty gate logic, allowing the Prover to reclaim their staked 2 $BTC once the timelock expires.

The Challenge Game is a fundamental piece of Bitlayer’s security architecture, designed to maintain transparency, enforce accountability, and ensure the integrity of every transaction within its L2 solution.

Zero-Knowledge Proof Verification

Integrating ZK-Proof Verifiers into the Bitcoin network could evolve its capabilities by allowing for improved transaction introspection and the creation of a ZK aggregation layer. This layer would aggregate verification proofs from various applications within the Bitcoin ecosystem, streamlining the verification process and helping with network congestion.

ZK-Proof systems fall into two main categories, each with unique features and applications.

Elliptic Curve Pairing-based ZK-Proof Systems

These systems, such as the BN254-based Groth16 proof system, utilize elliptic curve technology. They rely on a prime field, typically around 256 bits, making the verification process economical due to optimizations like Ethereum’s implementation of the BN254 precompiled contract. However, integrating such systems into Bitcoin poses challenges, primarily because Bitcoin’s script does not support the OP_MUL opcode, necessary for pairing operations. Strategies to potentially overcome these challenges include:

• Using simpler verification algorithms like FFlonk, which reduces complexity albeit at the expense of increased computational demands on the prover.
• Developing customized, smaller parameter curves specifically tailored for Bitcoin, though this could compromise security levels.

Hash Function-based ZK-Proof Systems

Systems like STARK and its variations offer robust security, including resistance to quantum computing attacks, making them a preferable long-term solution. STARK systems utilize smaller finite fields that are more compatible with Bitcoin’s existing operations, such as using OP_ADD and OP_SUB for basic arithmetic functions. These systems circumvent the need for the OP_MUL opcode by applying alternative methods like the double-and-add algorithm.

Currently, Bitcoin does not support these features because of its scripting language limitations. Bitlayer lays a series of adaptations to implement a hash function-based ZK verifier on Bitcoin. 

• Optimizing Script Size: Strategies need to be explored to minimize the script size, such as employing Bitcoin-friendly hash functions that fit within the constraints of Bitcoin’s script capabilities. For instance, investigating the properties of smaller finite fields could facilitate the implementation of efficient hash functions like Poseidon.
• Winternitz Signature: Optimize it so the state transfer overhead between scripts can be reduced.
• Script Segmentation: To accommodate the extensive scripts required by ZK-Verifiers, the script could be split across multiple transactions, enabling the execution of complex verification algorithms within Bitcoin’s script size limits.
• OP Mechanism: Used only in disputes by adjudicating on-chain, and requiring only one honest participant to ensure correct results at an acceptable cost.
• On-Demand Verification: Introducing an on-demand ZK Fraud proof system, where proofs are generated only during disputes, can significantly reduce the computational load and associated costs.
• Combination of ZK-Proof Systems: Multiple systems can be combined to balance Prover and Verifier costs off and on-chain.

Integrating ZK-Proof Verifiers into the Bitcoin network is an effort to boost its capabilities that will allow improved transaction introspection and the creation of a ZK aggregation layer. This layer would aggregate verification proofs from various applications within the Bitcoin ecosystem, streamlining the verification process and reducing network congestion

Bitcoin Friendly FRI

Briefly mentioned in previous sections, Bitcoin Friendly FRI is designed to address the high costs and complexity involved in traditional verification processes on Bitcoin, especially when a Prover is dealing with a large number of intermediate states as required in STARK verifications with many Merkle paths. This new protocol facilitates the execution of more efficient and cost-effective validations directly on the Bitcoin blockchain.

With the Taproot upgrade, Bitcoin introduced the Taptree structure, which provides an innovative way to manage scripts and signatures on the blockchain. Leveraging this new feature, the Bitcoin Friendly FRI replaces the traditional MerkleTree used in proof verifications with Taptree. This allows for all the evaluations to be committed directly to the polynomial in the Leaf Script of Taptree, significantly reducing the complexity and size of the data required for verifications with Merkle paths.

In the context of the Challenge Game here’s an overview:

• State Revelation: The Prover must disclose all state preimages on the blockchain, which traditionally could become prohibitively expensive with high computation complexity. By integrating Bitcoin Friendly FRI, the Prover’s responsibility is facilitated as the cost to reveal excessive intermediate states is reduced.
• Verifier’s Role: The Verifier benefits as well, gaining the ability to confirm the correctness of the states revealed by the Prover without the need to manage a large number of Merkle paths. This simplified process not only speeds up the verification but also improves the overall efficiency of the system.

The Bitcoin Friendly FRI makes the work easier for both the Prover and Verifier where both parties have to manage fewer tasks. In other words, without it, the process would have been slow and inefficient causing numerous issues in the system.

Multi-Proof Challenge Game

The Multi-Proof Challenge Game represents an advancement in Bitlayer’s security protocols, addressing the complexities and inherent challenges of implementing ZK-Proof verifiers based on Bitcoin scripts. Given the difficulty in achieving completely bug-free systems, this approach leverages the diversity of client architectures in blockchain technology to improve verification robustness and security.

Bitlayer integrates multiple ZK-Proof systems, including both ZK-SNARKs (Groth16) and Bitcoin-friendly ZK-STARKs, to construct a diversified and resilient verification framework. This multi-proof approach is inspired by the blockchain principle of using diverse clients to ensure network integrity and fault tolerance.

The operational principle of Bitlayer’s Multi-Proof Challenge Game is designed to mitigate the risks associated with relying on a single-proof verifier. Here’s how it functions:

• Multiple Fund Transactions: The Bitlayer Prover initiates multiple transactions on the Bitcoin blockchain. Each transaction is designed to test a different type of ZK Proof verifier, creating a broad challenge spectrum.
• Diverse Verification Challenges: These transactions target various ZK Proof verifier programs. By spreading out the verification processes across different systems, Bitlayer ensures that potential weaknesses or bugs in one verifier do not compromise the overall system’s integrity.
• Rewards for Successful Challenges: Verifiers participating in this system are incentivized with rewards for successfully challenging the proof verifiers.

Similar to the use of diverse client software in traditional blockchains, having multiple proofs and verification systems increases the fault tolerance of the network. This approach helps to ensure that even if one part of the system fails, others can still function correctly, preserving network integrity and continuity.

BitVM

The Bitlayer network is heavily based on BitVM in combination with other technical components. The BitVM allows Bitlayer to develop a turing-complete computation layer on the Bitcoin stack, which can handle any program or calculation without interfering with the Bitcoin protocol and its consensus rules.

If a system or programming language can solve any computational problem, it is considered Turing complete. Solidity is a Turing complete system that can run almost any program, including zero-knowledge proof verifiers, DeFi protocols, and many others. This makes it possible to directly implement these applications on Ethereum. Bitcoin lacks this capability since Script is not Turing complete.

Think of Script as a typical calculator handling some basic functions whereas Solidity is your smartphone, capable of handling any program or application.

BitVM changes that and facilitates the expression of complex Bitcoin contracts through a system where a prover claims a specific function’s output for given inputs, and a verifier can contest these claims with clear fraud proofs. This mechanism minimizes the on-chain footprint by handling extensive computations and communications off-chain, engaging the blockchain only during disputes.

Bitcoin’s inherent smart contract capabilities are generally limited to basic functionalities like signatures, timelocks, and hashlocks. BitVM expands these capabilities, enabling more expressive contracts and complex off-chain computations. Potential applications of BitVM vary, ranging from strategic games and prediction markets to bridging $BTC across different blockchains and simulating novel opcodes. This is a promising scenario for the Bitcoin network and its scaling capacities.

Architecture of BitVM

BitVM’s architecture borrows elements from optimistic rollups and the Merkelize All The Things (MATT) proposal, focusing on fraud proofs and a challenge-response protocol without necessitating changes to Bitcoin’s consensus rules. It relies on simple underlying primitives like hashlocks, timelocks, and Taproot trees. The prover and verifier engage in a pre-signed sequence of transactions that facilitate a challenge-response game to resolve disputes, illustrating the potential for universal computations on Bitcoin using this model. As long as both parties are cooperative, they can jointly settle any contract.

The Challenge Protocol is analyzed in detail in the corresponding section above.

Some words and notions are familiar since they were discussed previously under the Bitlayer architecture which adopts the BitVM technology.

Bit Value Commitment

This component allows the prover to set a bit’s value to ‘0’ or ‘1’ across different Scripts and UTXOs, improving Bitcoin’s VM runtime by distributing execution across multiple transactions. The commitment mechanism, based on Lamport signatures, involves two hashes (hash0, hash1) where revealing the correct preimage sets the bit’s value. If the prover provides a preimage of hash1, `1` is pushed onto the stack. If the prover provides a preimage of hash0, `0`’ is pushed onto the stack. If at any time the prover reveals both preimages then the verifier can claim a fraud-proof and take the deposit of the prover. This process is called ‘equivocation’.

This setup not only secures the commitment but also incorporates timelocks to enforce timely decisions to the prover.

Below is an implementation for a 1-bit commitment where the prover reveals hash1 by setting the bit’s value to ‘1’, thus unlocking the script.

We refer to these opcode sets as “OP_BIT_COMMITMENT”. The opcode will place a bit value on the stack based on which hash is matched by the preimage.

Logic Gate Commitment

Every computable function can be broken down into a series of Boolean circuits, with the NAND gate serving as a universal component. Common elements found in logic circuits consist of AND gates, OR gates, NOT gates, and NAND gates. NAND gates are referred to as “universal gates” because they can construct all other types of gates.

BitVM’s method involves simple commitments for NAND gates, where each gate’s input and output are secured through bit commitments. Specifically, a NAND gate contains two bit commitments which represent two inputs and a third bit commitment for the output. The Script will compute the NAND value of the two inputs that must match the output bit.

Binary Circuit Commitment

The commitment to a binary circuit extends the logic gate commitment by allowing the prover to execute any gate within the circuit as committed in a Tapleaf. These commitments are aggregated into a single Taproot address, which, despite potentially containing a vast number of Tapleaf Scripts up to a billion, maintains a minimal on-chain footprint.

The prover’s Taproot address contains a leaf script for each gate. The leaf scripts have a corresponding gate commitment as seen above.

Challenges and Responses

Challenge and Response are initiated when the Verifier disagrees that the Prover’s statement is correct. If the statement’s inconsistencies are identified, the Verifier is entitled to seize the funds of the Prover.

This is facilitated by pre-signed transactions that link challenges to responses. If one party disengages, the other can claim victory after a timeout, ensuring that disputes are resolved fairly and deposits are secured against fraudulent claims.

To understand this concept better here’s an example with simpler terms:

Imagine you and your friend are playing a game where you both have a box of blocks. Each block can be a different shape like a circle, square, or triangle. You claim that all the blocks in your box are circles. Your friend, who doesn’t believe you, can ask you to show a few blocks from the box to check if you’re telling the truth.

If your friend asks to see a block and it’s a circle, you keep playing. But, if one day your friend picks a block and it turns out to be a square, then you weren’t telling the truth about only having circles, and your friend wins the game and gets to keep some of your blocks. The same happens when you decide not to reveal the block’s shape.

In this game, your friend is the Verifier, who checks if you, the Prover, are telling the truth. The blocks are like the gates in a circuit, and each time your friend picks a block to see, it’s like opening a gate to check if the input (what goes into the gate) and the output (what comes out of the gate) match what you claimed.

Below is also a visual illustration where the Verifier asks the Prover to open specific gates as part of the challenge.

Inputs & Outputs

Inputs are set by revealing the corresponding bit commitments, ideally off-chain to minimize blockchain load. In opposing conditions, the verifier can make on-chain revelations. BitVM also supports multi-party inputs, allowing gates to integrate commitments from multiple parties.

Discreet Log Contract (DLC)

Along with BitVM and various XVMs, Bitlayer incorporates the DLC model. It contributes to the security of the protocol and the efficiency of cross-chain interactions. 

In summary, DLC is a contract execution framework that allows two parties to engage in contracts based on external conditions verified by an Oracle. A DLC enables the execution of conditional Bitcoin transactions directly on the blockchain. These contracts allow the parties to set and agree on the outcomes of predefined conditions, and when these conditions are met, as certified by the Oracle, the corresponding transactions are automatically executed.

DLC Components

• Contract Setup:

DLCs start with two parties agreeing on the terms of a contract, including the possible outcomes and their respective payouts. These outcomes are contingent on a specific event whose result will be provided by an oracle.

• Oracle Role:

The oracle is a third party that provides a digital signature on the outcome of the event being bet upon. This signature is crucial as it is used to unlock the transaction in favor of the winning party. Importantly, the oracle does not need to be aware of the existence of the contract itself; it only signs the outcome of an event.

• Transaction Execution:

Each potential outcome of the event is tied to a unique set of cryptographic conditions in the contract. Depending on the outcome, the corresponding transaction is executed. These transactions are pre-signed before the outcome is known and are only broadcasted to the Bitcoin network once the oracle has provided the necessary signature.

• Privacy and Security:

Since the contract details are not stored on the blockchain and the transactions are only broadcasted when the outcome is confirmed, DLCs offer enhanced privacy compared to traditional on-chain contracts. The oracle’s signature is the only part that links the outcome of the event to the blockchain transaction.

Below is a visual representation of a DLC. Alice and Bob agree to form a contract and agree on predefined terms. They lock 2 $BTC each in a 2-of-2 multi-signature output (1 key for each) and pre-sign. Their pre-signatures will be used to execute the payments after the Oracle broadcasts the results.

A contract of this type can look like this: Alice bets on Team A to win, while Bob thinks Team B will win. The payoffs look like this: If Team A wins, Alice gets 3 $BTC and Bob 1 $BTC. If Team B wins, Bob gets 3 $BTC and Alice 1 $BTC.

DLC on Bitlayer

The primary purpose of integrating DLC into Bitlayer’s architecture is to improve the security and control that users have over their assets while enabling complex financial contracts directly on the Bitcoin network. The DLC helps in overcoming the inherent limitations of Bitcoin’s design that does not support complex, state-dependent computations. This integration along with its other features allows Bitlayer to leverage the strong security measures of Bitcoin while enabling more complex transaction types and smart contract functionalities such as the Asset Bridge discussed earlier.

There are several benefits for why Bitlayer chose to incorporate DLC:

• Security: By using DLC, Bitlayer ensures that asset control and security are comparable to that of Bitcoin’s main chain. No single entity holds excessive control over the funds, which aligns with the decentralized nature of blockchain.
• User Control and Trust Minimization: DLCs allow users to maintain control over their assets throughout the transaction process. This setup minimizes the trust required in any central authority, as the contract terms are enforced by blockchain technology itself based on the Oracle’s data.
• Flexibility and Efficiency: DLCs do not require the maintenance of payment channels and are efficient in handling complex contracts directly on the blockchain. This reduces the overhead associated with channel management and enhances the scalability of financial applications on Bitcoin.
• Reduced Counterparty Risk: Funds in a DLC are locked in multi-signature contracts and are only transferred based on the Oracle’s confirmation of predetermined conditions. This significantly lowers the risk associated with breach of contract or counterparty failure.

Adding DLC enhances Bitlayer’s operation by enabling a solid asset bridge model that operates with increased independence from external validators. This model is important for Bitlayer’s rollup-equivalent framework, which aims to combine the security and simplicity of Bitcoin with the versatility and functionality of a Turing-complete programming layer. DLC, combined with BitVM, allows Bitlayer to support a wide range of applications, from simple transfers to complex DeFi solutions, thereby expanding the utility and applicability of Bitcoin.

Why the Project was Created

Because of its intrinsic technical constraints and lack of support for Turing-complete smart contracts, the growth of the Bitcoin ecosystem has trailed behind that of other L1 blockchain ecosystems like Ethereum. Stacks, Lighting Network, and other initiatives have helped to shape the Bitcoin ecosystem and are becoming increasingly important as the sector strives to get past the limitations imposed by Bitcoin’s original design. Transaction capacity and on-chain congestion are the main causes of the issue.

Bitlayer aims to improve the scalability and functionality of Bitcoin by enabling the execution of complex, stateful smart contracts directly on the Bitcoin network without altering its underlying consensus rules.

Protocol Value Proposition

The core value proposition of Bitlayer centers around extending Bitcoin’s utility beyond simple currency transactions, enabling it to support a broader range of dApps, including those in DeFi that require complex smart contracts. As a L2 solution, Bitlayer provides a Turing-complete toolbox and advanced smart contract capabilities similar to EVM blockchains that solve the limitations of Bitcoin as a platform for complex applications. This structure aligns with the one found on Ethereum L2s.

Bitlayer standout feature that’s substantially important is the security component that follows the standards of the Bitcoin network while improving scalability and user experience. By being the first protocol to leverage the capabilities of BitVM, Bitlayer offers developers the ability to write and deploy smart contracts using familiar tools used for the development of dApps on EVM chains. This lowers barriers for developers from other blockchain ecosystems looking to take advantage of the growing Bitcoin L2 landscape.

Roadmap

The development of Bitlayer is structured into a phased rollout of its mainnet, each designed to progressively improve the platform’s capabilities, improve user experience, and integrate solid security measures aligned with Bitcoin’s consensus mechanisms and onchain activities.

First Stage: Bitlayer PoS

In the first stage, Bitlayer adopts a superior security model combining PoS and Multisig. This phase integrates with multiple MPC custody platforms within a 100% EVM-Compatible environment, easing the way for users and developers to transition seamlessly. 

Bitlayer PoS facilitates cross-chain movements among BTC, EVM, and other blockchains, significantly enhancing the ecosystem’s value. 

The focus during this initial phase is on delivering a fully EVM-compatible development kit and ecosystem support. This setup allows developers to rapidly develop, test, and deploy applications, offering the early adopters benefits like lower gas fees and a versatile Bitcoin framework.

Second Stage: Bitcoin Friendly Finality-V1

Moving forward, the second stage introduces a rollup-equivalent model that includes a BitVM component for committing to and challenging state transitions, thus enabling L1 verification capabilities. 

Bitlayer continues to uphold the highest security standards by leveraging Bitcoin’s extensive network and security features, which provide users with greater flexibility and an enriched on-chain experience via continual network upgrades.

Third Stage: Bitcoin Finality-V2

The culmination of Bitlayer’s roadmap is marked by the third stage, aiming to implement a trustless bridge based on L1 verification capabilities. The successful completion of this stage will see the full deployment of Bitlayer’s final mainnet, achieving its foundational goals of providing Bitcoin-equivalent security alongside Turing completeness. 

This final version is anticipated to raise the security benchmarks for Bitcoin L2 solutions to unparalleled standards.

Sector Outlook

The Bitcoin ecosystem is undergoing significant evolution, marked by the introduction of new technologies that collectively expand its utility beyond a mere store of value. Recently, the approval of Bitcoin spot ETFs has catalyzed a wave of institutional interest. In addition, Ordinals, BRC20s, and Runes show that there is a demand to enable more productive use cases for $BTC. This trend is complemented by technical innovations within Bitcoin’s infrastructure, particularly through L2 solutions like Bitlayer and BitVM, which aim to improve Bitcoin’s functionality and scalability.

Projects such as the Lightning Network, Stacks, and others have led the efforts to scale Bitcoin over the past few years. The Lightning Network addresses transaction speed and cost, making Bitcoin feasible for microtransactions and payments. Stacks extends Bitcoin’s utility by enabling smart contracts and decentralized applications directly atop its blockchain, pushing the limits of Bitcoin’s original capabilities. Other L2 solutions have been entering the market since the publication of the BitVM whitepaper in 2023, inspiring the development of new efforts to scale Bitcoin with additional features and capabilities. 

Bitlayer and BitVM push further this technological evolution by integrating advanced computational features and Turing completeness without compromising the decentralized principle of Bitcoin. This bridges a huge gap between the EVM and the Bitcoin ecosystem. All these L2 technologies not only improve transaction throughput but also expand Bitcoin’s use cases into sectors like DeFi, NFTs, and beyond.

However, these initiatives also bring challenges. The inherent limitations of Bitcoin’s script, which is not Turing complete, mean that complex operations and applications that are feasible on platforms like Ethereum require innovative solutions to work on Bitcoin. BitVM, for example, addresses these by enabling off-chain computation with on-chain verification, similar to how optimistic rollups function. This approach maintains Bitcoin’s security and decentralization while allowing for more complex functions and applications. As more solutions develop and the space grows, the impact of past limitations will be mitigated to a point where Bitcoin can support every DeFi application.

The demand for Bitcoin-based applications is rising, driven by the broader acceptance of Bitcoin as a viable foundation for more than just financial transactions. This demand is further increased by the halving events, which, while reducing miner rewards, potentially increase transaction fees as a necessary compensation, thus highlighting the need for more efficient transaction processing solutions. As these Layer 2 solutions mature, they promise to unlock a new era of functionality and efficiency for Bitcoin.

Potential Adoption

Bitcoin is considered the most popular blockchain in the world, as demonstrated by $BTC having the largest market cap. Some understand Bitcoin as a means of payment and some consider it as digital gold used to protect wealth against inflation. While these cases are true, Bitcoin can also be a layer where applications are built on top of or around it just as other L1s.  Up until now, this has not been possible due to the limitations of the underlying L1, which is not Turing complete. However, L2s like Bitlayer are solving this problem by extending the functionality of Bitcoin while inheriting its security. Unlike Ethereum, where L2s are used for scalability, Bitcoin L2s are an extension of the base layer, adding functionality that is not possible at the L1 level. 

There is a lot of demand for protocols whose mission and vision is to support and scale Bitcoin. For comparison, look at the growth Ethereum had with the introduction of L2s and how it was able to solve some of the problems it had similar to Bitcoin. Apart from Ethereum, L2s like Arbitrum and Optimism saw significant growth and adoption by users attracting billions of capital into the protocols. In a similar case for Bitcoin where a L2 space similar to Ethereum emerged, the growth may be substantially bigger due to the current adoption and larger market size. 

Suppose Bitlayer can overcome the limitations of Bitcoin’s infrastructure for smart contracts and provide a solid solution for applications on Bitcoin. In that case, the protocol can attract many users and significant capital from various types of investors who want to interact with Bitcoin in a more complex and sophisticated way. 

What differentiates Bitlayer from other projects on Bitcoin is its compatibility with EVM tools. Unlike purely payment-focused solutions like the Lightning Network or Turing-incomplete smart contract platforms such as Stacks, Bitlayer integrates a comprehensive approach using the BitVM framework, which allows for the execution and verification of complex, Turing-complete contracts directly on Bitcoin. This not only expands Bitcoin’s use cases to include decentralized applications similar to those found on other chains but does so while being secured by Bitcoin’s security.

The bridge is also a component of the network that contributes significantly to the possible adoption of the protocol. It offers a secure and direct getaway from EVM chains to Bitlayer and the Bitcoin ecosystem.

Using the Protocol

How to Get Started

To start using the Bitlayer network users must follow and complete some required steps before interacting with the protocol.

Adding the Network

• 1. Head over to chainlist.
• 2. This is how the page will look.

• 3. Click ‘Connect Wallet’. Depending on your wallet a pop-up will appear prompting you to approve.

• 4. Click ‘Approve’ to add the Bitlayer Mainnet to your wallet.
• 5. Bitlayer will be on your ‘Networks’ tab.

Wallet Setup

Now it’s time to set up a wallet that supports the Bitlayer network. Users can access Bitlayer through three main sources: Bitcoin, Ethereum, and Other EVM Chains.

For Bitcoin

• 1. These are the available wallets:

• 2. Choose the wallet of your choice and click on it. For this example, we will use the OKX BTC Wallet.
• 3. After clicking the option you’ll be redirected to the OKX webpage. There you want to download and install the Chrome extension.

• 4. Click ‘Add to Chrome’ and follow all the steps.

• 5. When the download and installation are finished a window will pop up. On this window click ‘Create wallet’ and choose the option ‘Seed phrase’. If you want to connect your hardware wallet then choose that option and follow the steps.

• 6. Set up your password and back up your seed phrase as prompted.
• 7. After following these steps you’ll be landed on the main page of the wallet.

• 8. Before moving on to fund the wallet make sure to pin the OKX wallet on the extension bar for easy access.

Funding the Wallet

To use the Bitlayer network you need $BTC for gas. The easiest way to send $BTC to your wallet is through a CEX. Use your preferred CEX (Coinbase, Binance, etc) to buy $BTC and transfer it over to your wallet. 

• 1. Copy the address from your wallet. Be careful and choose the correct one. In this case, the address is under the Taptoor option.

• 2. Paste the address on the CEX and withdraw your $BTC. Pay attention to the network you are withdrawing. Some CEXs will automatically match the network to your address but if not make sure it is the Bitcoin network.
• 3. Wait for the confirmations and head over to your wallet. Your funds should be there.

• 4. Your wallet is ready.

Bitlayer Bridge

• 1. Head over to the Bitlayer bridge here.
• 2. Connect your wallet in the top right corner and select the OKX BTC wallet.

• 3. After connecting your wallet enter the amount you want to bridge over to Bitlayer. Note, that there are some requirements about your $BTC balance:
  • The minimum amount set by Bitlayer for crossing is currently 0.0005 $BTC. 
  • The reserved cross-chain fee is 0.00015 $BTC but can vary. Typically, the Balance minus Amount should be greater than 0.00015 $BTC.

• 4. The next step is to connect the EVM wallet we want to send the funds. Choose one of the options available. In this example, we will use the Metamask wallet. Click ‘Connect’ when prompted.

• 5. Make sure that your EVM address is shown on the interface.

• 6. Now everything is ready. Click ‘Transfer’ and confirm the transaction on your OKX wallet.
• 7. After confirming, the transaction will be “Pending” as seen on the page. The duration of this process depends on the congestion level of the blockchain. When “Completed” appears, it means that the cross-chain transaction is completed and your funds are on the Bitlayer network. 

• 8. You have successfully bridged to Bitlayer.

From Ethereum

The process of bridging to Bitlayer from Ethereum is pretty straightforward.

• 1. Again, head over to the bridge page here. 
• 2. This time we want to choose the Ethereum option on the ‘From’ tab.

• 3. Click ‘Connect Wallet’ and connect your Metamask. The recipient address is the same so it will automatically fill.
• 4. You can bridge these assets from Ethereum to Bitlayer: $ETH, $USDT, and $USDC. For this example, we will transfer $ETH.
• 5. Select the amount of $ETH you want to bridge and click ‘Transfer’. Pay attention to the fees and the total amount.

• 6. Confirm in your wallet and wait for the transaction to be completed.
• 7. You have now bridged to Bitlayer from Ethereum.

From other EVM Chains

If you want to transfer from other EVM chains, Bitlayer supports these third-party bridges:

Get Gas on Bitlayer

If you don’t have any $BTC on Bitlayer but have $USDT or $USDC you can still get gas through the network.

• 1. Head over to the “Get Gas” page
• 2. Choose $USDT or $USDC depending on what you have.

• 3. Select the amount you want to convert into gas and click ‘Swap’. Note that there is a 2 $USDT/$USDC fee.

• 4. Click ‘Confirm’ and sign on your wallet. This process doesn’t cost any gas.

• 5. After the swap is completed the $BTC will be in your wallet.

Using a dApp on Bitlayer

Many projects are available on Bitlayer offering a variety of products and services to users.

In this example, we will conduct a simple swap of $USDC to $BTC on one of the available DEXs, Macaron.

• 1. Go to the Macaron app page here.
• 2. Connect your wallet in the upper right corner. 

• 3. Click the ‘Swap’ option from the tab. Set up your pair from $USDC to $BTC. If you are swapping for the first time you need to ‘Approve’ the token first. Click ‘Approve USDC’ and do the same in your wallet. After approving the token, choose the amount you want to swap and click ‘Swap’. 

• 4. Confirm the transaction in your wallet.
• 5. You have successfully performed a swap in the Bitlayer network.

Business Model

Bitlayer operates as a L2 solution on Bitcoin, serving as a bridge between the security and reliability of Bitcoin and the flexibility needed for more complex applications. By utilizing BitVM technology, Bitlayer enables developers to build and deploy applications that require more computational complexity than Bitcoin’s base layer can support. This integration facilitates the creation of dApps such as DeFi protocols of all kinds, directly taking advantage of Bitcoin’s underlying security without compromising on scalability or functionality.

The business model of Bitlayer is structured around providing value to the cryptocurrency ecosystem by expanding Bitcoin’s utility. It captures value through the network effects generated by increased activity on the network. As more applications are built and run on Bitlayer, the demand for Bitcoin and Bitlayer’s native functionalities increases, potentially raising the value of the network. Additionally, by making Bitcoin more versatile and capable of supporting a wider range of applications, Bitlayer attracts new users and developers to the ecosystem, which in turn can lead to increased adoption and usage of Bitcoin itself.

Bitlayer’s role as a facilitator for new applications creates value not just by expanding the usability of Bitcoin but also by improving its economic value proposition. As transactions and smart contracts run on Bitlayer, they contribute to the overall activity on Bitcoin’s blockchain, indirectly impacting transaction fee dynamics and the security of the network through increased demand for block space. This model also opens avenues for future revenue besides transaction fees through potential layer-specific tokens, services, or different transaction fee mechanisms that could be introduced as the ecosystem matures. Thus, Bitlayer not only broadens the capabilities of Bitcoin but also contributes to its longevity by increasing the amount of miner revenue that comes from transaction fees, which is especially important as we go through more halving events that reduce mining rewards. 

Fee Breakdown

Users of the Bitlayer network incur fees for various types of transactions, which include but are not limited to:

• Smart Contract Execution: As Bitlayer is designed to support Turing-complete smart contracts, executing these contracts requires computational resources. The fees for these operations are calculated based on the complexity and the computational power required.
• Cross-Chain Transfers: Fees are also applicable for operations that involve the movement of assets between the Bitcoin mainnet, EVM chains, and Bitlayer. These fees compensate for the computational and network resources used to secure these transactions.
• L2 to L1 Settlements: When disputes arise or when finality on the Bitcoin blockchain is required, the resulting transactions must be settled on the Bitcoin mainnet. This involves broadcasting proof to the mainnet, which incurs fees.

Below is a fee table with the approximate values for each one.

Fee Type	Description	Value
Minimum Transfer Amount	The minimum amount of $BTC allowed for a single transfer.	0.0005 $BTC
Transfer Fee	Fee charged for transferring assets.	~0.00008 $BTC
Gas Swap Fee	Fee charged for swapping $USDT or $USDC for gas on Bitlayer	2 $USDT/$USDC
Minimum Tip (Mainnet/Testnet)	Minimum tip required for transactions.	0.1 gwei
Gas Price for Legacy Transactions	Gas price typically used for legacy transactions.	0.11 gwei
Max Priority Fee per Gas	Maximum priority fee per gas for transactions.	0.1 gwei
Max Fee per Gas	Sufficiently high fee per gas set to ensure transaction processing.	Depends on network conditions. (see Gas Parameters sections on how to set).

L1 Fees

While Bitlayer operates largely independently of the Bitcoin mainnet, certain interactions, especially those related to dispute resolution or final settlements, require the use of the Bitcoin network. In these cases, standard Bitcoin network fees apply. These fees ensure that the transactions are processed by miners on the Bitcoin blockchain and are necessary to secure the finality and immutability of these transactions. In addition, there is also the security fee paid by the Bitlayer network.

Tokenomics

$BTR

The $BTR token is officially announced by the team and the TGE (Token Generation Event) will happen some time soon.

Holders of $BTR will have the option to stake their tokens and be part of Bitlayer’s governance. The incentives and other information about staking will be announced when the staking system takes place.

Governance

Governance is a huge part of every protocol. It is the process where the protocol becomes decentralized and allows the community to influence the development and management of the project. Bitlayer’s vision is committed to decentralization and a governance structure is planned after the $BTR token launch.

However, Bitlayer has already launched some initiatives that are directed to future protocol governance. 

For example, Bitlayer announced the launch of its first official NFT “Lucky Helmet”. This was an initiative after the launch of Mainnet-V1 to incentivize part of the community. A total of 5,000 Lucky Helmets were distributed through a whitelist to the community of Bitlayer. Amongst the many incentives that this NFT offers, holders will benefit from priority governance rights within the ecosystem when governance is implemented in the protocol.

Risks

As with any other protocol in crypto, Bitlayer faces some risks related to the technologies supporting the network and its operations. L2s are often more complex than a single dApp because their infrastructure contains various components tied together and every single piece works in synergy with the other. For that reason, the risk profile increases, introducing numerous factors that need to be addressed.

Here’s an overview of the possible risks associated with Bitlayer:

Security Risks: While L2 solutions aim to inherit the security of their underlying L1 blockchains (like Bitcoin for Bitlayer and Ethereum for others), they can introduce new vulnerabilities, especially at the bridging level. Bitlayer leverages technologies such as BitVM and DLC, and as a result, still relies heavily on the correct implementation and security of these additional technologies. There’s always a risk of bugs or vulnerabilities in the smart contracts or the Layer 2 protocol itself, which could be exploited maliciously.

Liquidity and Bridging Risks: L2 solutions often rely on bridges for transferring assets between the L1 and L2 networks. These bridges can be complex and are frequent targets for hackers. Bitlayer’s use of a multi-signature or DLC approach to asset bridging can mitigate some risks but still needs robust implementation to prevent exploits.

Economic Risks: L2 solutions must design effective economic incentives to ensure security and participation. This includes the design of transaction fees, staking rewards, and other financial incentives. Poorly designed economic models could lead to security vulnerabilities or fail to attract enough participants to the network. Tokenomics could also play a part and impact the protocol, where a poor design can hurt the economics despite the fundamentals of the protocol being solid.

Security

Audits

Bitlayer has gone through rigorous audits for its smart contracts and code, placing significant emphasis on the security aspect. The audits were conducted by third-party audit firms, Hacken and SlowMist.

Bitlayer has had the following audits done:

Smart Contract Code Review And Security Analysis Report – April 22, 2024 – Hacken

• Total Findings: 2 (1 Medium, 1 Low) – Solved – Audit Score: 8.1

Smart Contract Code Review And Security Analysis Report – April 8, 2024 – Hacken

• Total Findings: 5 (1 Medium, 3 Low, 1 Mitigated) – 3 Solved, 1 Accepted – Audit Score: 9

Smart Contract Code Review And Security Analysis Report – April 1, 2024 – Hacken

• Total Findings: 4 (1 High, 3 Low) – 3 Fixed, 1 Accepted – Audit Score: 7.8

Blockchain Protocol Security Analysis Report – March 27, 2024 – Hacken

• Total Findings: 2 (No severity) – 1 Fixed, 1 Mitigated – Audit Score: 9.7

Blockchain Security Audit Report – February 27, 2024 – SlowMist

• Total Findings: 4 (1 Low, 3 Suggestions) – 1 Fixed, 1 Ignored – Audit Result: Low Risk

Smart Contract Security Audit Report – February 27, 2024 – SlowMist

• Total Findings: 9 (1 High, 2 Medium, 5 Low, 1 Suggestion) – 1 Fixed, 8 Acknowledged – Vulnerabilities Found: 10 – 6 Fixed, 4 Acknowledged – Audit Result: Medium Risk

Team

The Bitlayer team is composed of individuals with many years in the crypto space and valuable contributions to the ecosystem.

Some of the core team members include:

• Charlie Yechuan Hu – Co-Founder

Charlie Yechuan Hu is an active figure in the Web3 space, currently serving as a co-founder of Bitlayer. His career is marked by extensive experience in community building, ecosystem development, and growth marketing, particularly within the cryptocurrency sector. Charlie has held significant roles, including managing partner at LucidBlue Ventures and Head of China & South East Asia at Polygon, where he drove substantial growth by supporting hundreds of projects in community engagement and ecosystem development. Additionally, Charlie has contributed to the Polkadot community as an ecosystem builder and co-founder of the PolkaBase Community.

• Kevin He – Co-Founder

Kevin is another important figure for the team, notably recognized for his leadership as the co-founder of Bitlayer and his extensive work with BitVM. He has a strong background in Web3 technologies, having served as the Web3 tech head at Huobi Global. During his tenure, he successfully launched three EVM chains, two ZK-Rollups, and a non-custodial platform, collectively managing billions in total value locked. Other significant contributions include leading the product and R&D teams at New Huo Tech and driving major advancements in digital asset custody solutions. Additionally, Kevin played a crucial role in establishing and scaling the Huobi Eco Chain, impacting its transaction volume and TVL.

• Dr. Lyndell – Cryptography Lead at Huobi Global.

A PHD in cryptography, published over 10 international papers and holds more than 20 invention patents. currently, his primary research focuses on zero-knowledge proofs, ecdsa threshold signatures, and fully homomorphic encryption.

• Daniel Zhou – Chief Architect

Daniel Zhou is a former Chief Architect at @Antchain, a former staff engineer at Intel and Alibaba Cloud. A seasoned software architect with a background in cryptography / distributed systems and years of experience in cloud computing / blockchain technology. He excels at building strong teams and bootstrapping complex software projects. Notably led a team that delivered Antchain’s state-of-the-art blockchain system, achieving a certified throughput of 200,000 TPS and serving more than 60M end users. Published 4 top-tier journal papers in blockchain field.

• Oxhhh – Core ZKP Developer

Core developer at EthStorage, delivered 2 of the most important modules of EthStorage chain – storage node and cross-chain bridge. Core developer at EigenLabs, delivered the kernel of eigen-zkVM – ZKP prover and aggregator.

• Allen Joseph – Head of Developer Relations

Allen Joseph is a seasoned Developer Relations Engineer with a robust background in blockchain technology. Currently, he leads developer relations at Bitlayer, focusing on enhancing the blockchain ecosystem’s growth by improving developer onboarding experiences and fostering community relationships. He has worked across various platforms, including Binance, StarkNet, Ethereum, NEAR, and Aurora, where he supported development lifecycles and engaged with partner communities. 

Project Investors

Bitlayer has raised $5 million at an $80 million valuation in a seed round led by notable funds, angel investors, and teams.

The funding round was led by blockchain-focused venture firms Framework Ventures and ABCDE Capital, with additional investments from StarkWare, OKX Ventures, Alliance DAO, UTXO Management, Asymmetric Capital, Kenetic Capital, Kestrel, Global Coin Research, Pivot Global, Web3Port, Gate Labs, Mindfulness Capital, Quotient Ventures, Cogitent Ventures, NxGen, C6E Capital, PAKA, Comma3 Ventures, Kronos Ventures, Pragma Ventures, Faculty Group, Rising Capital, Samara Group, DuckDAO, CSP DAO, and DCI.

Renowned angel investors who contributed include Messari CEO Ryan Selkis, Messari co-founder Dan McArdle, Asymmetric Capital Bitcoin educator Dan Held, Hacken CEO Dyma, Sky Mavis CEO Trung and CTO Andy, Kyber Network founder Loi Luu, Coin98 founder Thanh Le, and Blockchain Founders Fund partner Tobias.

The seed round received substantial support from ecosystem partners such as Hacken, AWS Cloud, Ankr, Polyhedra, Babylon, Particle Network, Meson, Nubit, BitSmiley, TokenPocket, Xverse, Flash Protocol, Umoja.xyz, RunesTerminal, Lamina, NFTGO, Giants Planet, Tria, Tonka Finance, Anome, BitLen, Ordimint, and Caliber.

Additional Information

Use Case Ideas

• Decentralized Bitcoin Interest (convert staking rewards of other tokens to Bitcoin).
• Zap Money (fast, micro-transfers).
• Account Abstraction for Bitcoin Wallets.
• Advanced Bitcoin NFTs with Secure Swaps.
• Bridge:
  • Bridging Assets to Bitcoin as BRC20s or
  • Bridging BRC20 from Bitcoin to Other Ecosystems.
• Ordinals Marketplace.
• Bitlayer-Scriptions.
• AI & Bitcoin Integrations.
• ZK Rust smart contracts.
• Bitcoin DEXes, Lending & Derivatives.
• Bitcoin-backed Stablecoins.
• Tokenized Mining & Hashrate Markets.
• DAOs & BitcoinTreasuries.
• GameFi Incorporating $BTC as in-dApp Currency.
• SocialFi.
• Bitcoin for Autonomous Agents.
• Bitcoin for DA & Checkpoints for L2 ChainsFi.

Glossary

• Bitlayer

A L2 solution based on the BitVM technology, designed to enhance Bitcoin’s capabilities by enabling Turing-complete contracts and complex computations directly on or linked to the Bitcoin blockchain.

• BitVM

A virtual machine paradigm that enables the creation of Turing-complete Bitcoin contracts, allowing for complex computations to be verified rather than executed on Bitcoin, using a model similar to optimistic rollups.

• Turing Completeness

A characteristic of a system or programming language that implies it can perform any computation given enough time and resources. Turing-complete systems can execute a wide array of programs, including those found in modern blockchain applications.

• Solidity

Solidity is a high-level programming language designed specifically for developing smart contracts that run on the Ethereum Virtual Machine (EVM).

• Script

Script is a simple, stack-based programming language associated with Bitcoin’s transaction protocol. 

• Optimistic Rollups

A L2 scaling solution that assumes transactions are valid by default and only runs computation, typically in the form of fraud proofs, when a transaction is challenged.

• Discreet Log Contracts (DLC)

Smart contracts for Bitcoin that allow two parties to interact based on conditions agreed upon and signed off by an oracle without revealing the specifics to the blockchain, thus maintaining privacy and reducing blockchain bloat.

• Zero-Knowledge Proofs

Cryptographic methods that allow one party to prove to another that a statement is true without conveying any additional information apart from the fact that the statement is indeed true.

• EVM Compatibility

The ability of a blockchain platform to support and execute contracts written for the Ethereum Virtual Machine (EVM), which is the primary environment for running decentralized applications on Ethereum.

• Taproot

A Bitcoin protocol upgrade that improves the blockchain’s privacy, efficiency, and capability to handle complex smart contracts through Schnorr signatures and MAST (Merkelized Abstract Syntax Trees).

• Taptree

Utilized in BitVM, a Taptree is a form of Merkle tree used to organize different scripts or smart contract clauses efficiently. This structure helps in minimizing the data that needs to be included in a transaction, thereby optimizing transaction space and costs.

• Sequencer

In the context of blockchain L2 solutions, a sequencer orders transactions before they are batched into a single submission to L1, optimizing network efficiency and reducing costs.

• Gas Parameters

Refers to the metrics or costs associated with executing transactions on a blockchain network, including costs tied to computation and storage.

• Layer 2 (L2)

Solutions or technologies developed to scale applications by handling transactions off the main blockchain (Layer 1) while maintaining the decentralized security model of the underlying network.

• Multi-Party Computation (MPC)

A cryptographic protocol that distributes computation across multiple parties where no individual party can see the other’s data, enhancing privacy and security.

• Threshold Signature Scheme (TSS)

A cryptographic method for distributing control over a single private key among multiple parties, any subset of which can cooperate to perform a cryptographic operation.

• Schnorr Signatures

A signature algorithm that allows for more complex signature types, offering advantages in scalability and privacy in Bitcoin transactions.

• Oracle

An entity in blockchain protocols that provides external data (e.g., price feeds, event outcomes) to smart contracts that cannot access off-chain data independently.

FAQ

What is Bitlayer?

Bitlayer is a L2 scaling solution for Bitcoin that enhances Bitcoin’s capabilities by allowing for the execution of more complex applications directly on top of the Bitcoin network.

How does Bitlayer work with Bitcoin?

Bitlayer operates on top of the Bitcoin network, utilizing a technology called BitVM to facilitate complex computations without altering Bitcoin’s original blockchain or consensus rules.

What is BitVM?

BitVM is a computational layer that enables Turing-complete smart contracts and complex applications to run on top of Bitcoin by using a challenge-response protocol and off-chain computation.

Can Bitlayer handle smart contracts?

Yes, Bitlayer enables smart contract functionality on Bitcoin by providing a platform for developers to build and deploy decentralized applications using complex computations that are not natively possible on Bitcoin’s base layer.

What types of applications can be built on Bitlayer?

Developers can build a variety of decentralized applications (dApps) on Bitlayer, including DeFi platforms, NFT marketplaces, games, and more, all benefiting from the security of the underlying Bitcoin blockchain.

Is Bitlayer secure?

Bitlayer inherits the security of the underlying Bitcoin network while adding layers of its own security protocols through the BitVM technology, making it a secure platform for running decentralized applications.

How does Bitlayer affect Bitcoin transaction fees?

Bitlayer aims to provide lower transaction fees for complex operations by handling these transactions off the Bitcoin main chain, thereby reducing the direct fee impact on the Bitcoin network.

What are the gas fees on Bitlayer?

Transactions on Bitlayer require gas fees similar to those on Ethereum, but they are denominated in $BTC with a specific structure to ensure minimal costs and efficient processing.

How can I participate in Bitlayer?

Users can participate by using applications built on Bitlayer, developers can build applications, and validators can participate in the network’s security through various consensus mechanisms proposed by 

Bitlayer.

Does Bitlayer support Ethereum-based applications?

Bitlayer is designed to be EVM-compatible, allowing developers to easily port existing Ethereum applications onto Bitlayer, leveraging lower transaction costs and the security of the Bitcoin network.

Where can I learn more about developing on Bitlayer?

Developers interested in building on Bitlayer can access documentation, developer tools, and community support through the official Bitlayer website and developer portals.

Why are Bitcoin’s capabilities for complex computations limited? 

Satoshi originally designed Bitcoin to operate like this to solidify the core principles: Decentralization and Security.

Community Links

• Website
• Bitlayer Bridge
• Docs
• Medium
• Whitepaper
• Twitter
• LinkedIn
• Discord
• Telegram
• GitHub
• DefiLlama