The first shot of the bull market: BTC L2 will crown the alpha king

2024.01.22

The first shot of the bull market: BTC L2 will crown the alpha king

This article reviews the implementation approaches of mainstream BTC L2 solutions in the market, and how they integrate BTC assets and ensure security.

2024.01.22 - 09:22:21

Navigating Web3 tides with focused insights

This article reviews the implementation approaches of mainstream BTC L2 solutions in the market, and how they integrate BTC assets and ensure security.

Author: blockpunk

As mentioned in the previous long thread, the rapid development of "inscriptions" has boosted the prosperity of the BTC ecosystem, but it has also intensified competition for network resources. High fee costs, coupled with the foreseeable rise in BTC prices, continue to raise the barrier to entry for participants in the BTC ecosystem.

This has prompted growing attention and discussion around BTC scaling solutions, attracting interest from both the community and investors.

Naturally, there's been a tacit consensus around directly upgrading BTC L1. The most radical discussions involve lifting restrictions on certain OP scripts and further tapping into BTC's latent potential under Taproot (e.g., discussions around CTV and CAT).
Inspired by Ethereum’s rollup advancements and theoretical progress, BTC Layer 2 has become the mainstream topic in scaling debates—the fastest path forward. Mass-market projects are expected to launch within the next two to three months, likely dominating the narrative and speculation cycles.

Due to BTC's highly decentralized governance—lacking a central "church" to guide the community—L2 designs are flourishing in diverse directions. This article explores representative BTC L2s and related protocols to examine the possibilities of BTC scaling.

Here, BTC L2s are broadly categorized into sidechains, rollups, DA layers, and decentralized indexing approaches, grouping similar projects together. Note that BTC scaling solutions remain ill-defined, and my classification is not rigorous.

This article focuses on implementation-oriented analysis, acknowledging many designs are still at the conceptual stage. When it comes to asset competition at the L2 level, technology and security define the project's floor. Technology is the ticket—first class, economy, or even a standing pass—but for asset speculation, reaching a baseline suffices.
From an asset perspective, two key factors matter: first, the L2's ability to generate assets—whether through inscriptions or self-driven value creation—which cannot be assessed purely from a technical standpoint; second, its capacity to attract deposits of native BTC from L1, which will be the core differentiator. This heavily depends on bridge security, as “not your keys, not your coins” remains a foundational principle closely tied to design choices.

Could BTC’s ecosystem adoption surpass ETH’s in the future? Perhaps this provides some insight.

First, let’s introduce the prerequisite tech: two changes brought by the Taproot upgrade:

Schnorr signatures enable multi-signature setups with up to 1,000 participants on BTC—a foundational element for many L2 bridges;
MAST allows complex UTXO scripts to be structured via Merkle trees, enabling more sophisticated logic and making proof systems on L2 feasible;
Tapscript upgrades Bitcoin scripting, allowing a series of validation scripts to determine whether a UTXO can be spent—enabling withdrawals, slashing, and other operations on L2.

I. Sidechains

The advantage of sidechains lies in fast deployment and rapid business logic execution. Their security is primarily dependent only on their own networks, functioning like a "hanging ticket" on the train of BTC security. The most critical component is the BTC cross-chain bridge—the sole connection point.

BEVM

In fact, most BTC L2s follow the same sidechain philosophy popularized during ETH's scaling era, just like BEVM.

BEVM leverages Taproot to deploy a multi-signature address on BTC L1 and runs an EVM-based sidechain. An EVM smart contract handles BTC withdrawal requests, and BEVM uses bridged BTC as gas.

During deposit, bridge operators sync BTC data and notify the sidechain. BEVM nodes run light clients to verify deposits by syncing BTC block headers. For withdrawals, custodians sign transactions, and once a threshold number of signatures is collected, the BTC withdrawal transaction is broadcasted—enabling asset interoperability between the sidechain and BTC.

Unlike traditional approaches like $RSK or $STX, BEVM uses Taproot-based multi-sig to implement threshold signatures. This allows for potentially more bridge managers, increasing fault tolerance and decentralization for BTC bridging.

However, BEVM does not inherit any BTC security—it only enables asset transfer. Its nodes operate internal consensus and EVM independently, without posting proofs to BTC L1, so there’s no L1 data availability (DA).

Transaction censorship resistance relies solely on the sidechain itself. If nodes refuse to include your BTC withdrawal request, you cannot retrieve your BTC from L1—an inherent risk.

The benefit is rapid implementation and validation. BEVM’s use of Taproot multi-sig improves bridge security, making it one of the few BTC sidechains already live on mainnet.

Map Protocol

Map is an EVM-architected inscription sidechain that maps BRC20 tokens from BTC L1 to EVM for basic application use.

Map runs an enhanced BRC20 indexer. Users send a new BTC transaction embedding target chain and address info in JSON format, allowing Map to index and reflect the token on the sidechain. Withdrawals are signed by a PoS committee using Map’s PoS mechanism.

Effectively, BRC20 accounting runs off-chain via indexing, with BTC L1 serving merely as a data source.

Leveraging low fees, Map hosts tools like LessGas for BRC20 minting, SATSAT marketplace, and Roup for BRC20 bridging—centered around inscriptions, gaining notable traction.

Map uses classic PoS consensus and uploads checkpoints to BTC L1 to enhance security. But beyond defending against long-range attacks, Map doesn’t leverage BTC’s security for censorship-resistant withdrawals, state validation, or data reliability.

BitmapTech Merlin Chain

A BTC sidechain launched by Brc420. Merlin Chain uses Cobo Wallet’s MPC solution for BTC bridging—a relatively conservative choice. MPC involves fewer signers, so while less secure than post-Taproot BTC multi-sig, it benefits from being battle-tested.

Merlin integrates Particle Network’s account abstraction, allowing users to interact with the sidechain using familiar Bitcoin wallets and addresses—a UX win. In contrast, forcing Bitcoin users back into MetaMask feels lazy and brute-force.

Brc420 and Bitmap have strong momentum and user base. Merlin builds around inscriptions, supporting cross-chain transfers of various L1 inscription assets and offering new inscription minting services on the sidechain.

ckBTC

ckBTC is ICP’s pure cryptographic integration of BTC, operating without third-party bridges or custodians.

ICP is an independent L1 blockchain secured by its unique BLS threshold signature scheme. The ChainKey technology, tightly bound to ICP’s consensus algorithm, allows the entire ICP network to jointly manage a threshold-signature BTC address—receiving BTC and controlling funds via aggregated signatures for withdrawals.

ICP replicates BTC’s full UTXO set using an account model. Smart contracts on ICP can read BTC’s state—equivalent to running a full BTC node within ICP’s network.

Since this threshold signature is tightly coupled with ICP’s consensus, ckBTC’s security depends only on ICP and BTC networks—no additional trust assumptions.

Thus, ICP’s ChainKey threshold signature represents the most secure BTC bridge concept today. However, if the ICP network fails or rejects transactions, users cannot forcibly withdraw BTC from L1. Additionally, as an independent L1, ICP’s security is self-sovereign and unrelated to BTC.

II. Data Availability (DA)

BTC is the world’s most robust trusted data source. Therefore, leveraging BTC as a primary source of trustworthy data is perfectly logical.

Similarly, inspired by Celestia’s DA theory, despite BTC’s expensive storage, it has laid a foundation for DA-layer consensus.

At its core, ordinals and the entire inscription ecosystem already use BTC as a DA layer. Almost all “BTC L2s” submit data to BTC, though often symbolically—representing aspirational goals. Here are some distinctive designs:

Nubit

Nubit is a DA protocol extending BTC’s data availability use cases, drawing attention due to backing from Bounce Finance and Domo.

Simply put, Nubit operates a POS-consensus DA chain similar to Celestia, periodically anchoring its own DA data—like block headers and transaction Merkle roots—onto BTC L1.

Thus, Nubit secures its DA via BTC L1, while selling its own storage space as DA to users and other rollups (DA inception). Nubit lacks smart contract functionality and requires rollups to be built atop its DA layer.

Users upload data to Nubit’s DA layer. After confirmation via Nubit’s POS consensus, data enters a “soft confirmed” state. Later, Nubit anchors the data root to BTC L1. Only after BTC transaction finality does the original data achieve finality. Then, users must also anchor a tag on BTC L1 to allow full nodes to query raw data via Merkle tree lookup.

Nubit’s early POS consensus is supported by Babylon’s BTC staking (discussed later). Users pay storage fees in BTC via Lightning Network, avoiding state bridge issues—emergency withdrawals can be done by closing channels without interacting with Nubit’s POS network.

Nubit resembles a Bitcoin-native version of Celestia—minimalist, no complex smart contracts, using trust-minimized Lightning for BTC payments. While Lightning is sufficiently trustless, UX suffers, especially for large fund movements (state channel elder problem).

Nubit’s link to BTC is thin: its chain security isn’t guaranteed by BTC, and BTC-stored data is only verified by Nubit’s client nodes. Why should rollups or inscription data go through Nubit instead of writing directly to BTC? This is Nubit’s biggest unanswered question—cost alone may not be enough motivation.

Its main edge over direct BTC DA is support for light-node data sampling (DAS), impossible on BTC itself. This means DA verification no longer requires downloading a full BTC node.

Can non-BTC-native inscriptions gain community consensus? Nubit attempts to replace BTC L1’s DA with its own—facing not just technical skepticism, but a massive challenge in community alignment. Of course, that also presents a huge opportunity.

VedaVeda

VedaVeda reads specific Ordinal inscriptions on BTC L1, treating them as transaction requests executed in an EVM beneath the BTC chain. Users sign an EVM-compatible transaction with their BTC private key, then mint it as an inscription on BTC.

Veda’s EVM nodes scan BTC blocks. Once confirmed on BTC, the EVM executes the request, changing state. Effectively, BTC acts as Veda EVM’s pending transaction pool. However, due to BTC’s far lower performance compared to ETH’s EVM and limited data per block, Veda EVM can always process all uploaded EVM requests.

BTC serves as the complete data source for all Veda states. Anyone can reconstruct the full EVM state by scanning relevant BTC blocks—making Veda EVM optimistically trustable, without complex security assumptions.

However, Veda cannot scale BTC’s performance. Think of it as an Ethereum-like network with 10-minute block intervals, ~5 TPS, but backed by tens of thousands of nodes and massive PoW hashpower. It merely extends BTC’s functionality by adding smart contracts—fundamentally not solving resource competition.

Babylon

Babylon is a protocol enabling other blockchains to share BTC’s security, comprising two parts: Bitcoin staking service and Bitcoin timestamping service.

Babylon allows BTC staking to provide economic security for PoS chains (similar to ETH restaking), fully implemented via cryptography—no third-party bridges or custodians needed.

Stakers send a BTC transaction with two UTXO outputs: one locked with a timelock script (unlockable after maturity); the other sent to a temporary BTC address whose key pair meets the cryptographic standard of “Extractable One-Time Signatures (EOTS).”

When a BTC staker runs a PoS chain validator node, they sign the valid block using the EOTS private key. If honest (signing only one valid block per height), they earn rewards. If malicious (double-signing two blocks at same height), their EOTS private key is revealed, allowing anyone to sweep their staked BTC—enabling slashing.

This incentivizes honest behavior. Babylon also offers BTC timestamping—anchoring checkpoints from other blockchains into BTC’s op_return—for added security.

Nubit plans to use Babylon’s staking service for enhanced security. Babylon uses pure cryptography for deposits, withdrawals, and slashing—highly secure. But for chains using staking, it imposes economic constraints and falls short of verifiability compared to ETH rollups. Timestamping uploads L2 data to BTC, but verifying requires downloading full BTC nodes—high barrier. Also, BTC L1 lacks smart contracts to validate data correctness.

III. Rollups

With Ordinals, Bitcoin can store arbitrary data—acting as a highly secure database. Uploading rollup proof data to BTC ensures immutability, but does not guarantee transaction validity or correctness within the rollup.

The core issue for BTC rollups is verification. Most BTC rollups may adopt sovereign rollup (client-side validation), where validators sync full rollup data off-chain and verify independently.

But this fails to leverage Bitcoin’s greatest strength: its vast network of over 100,000 PoW nodes securing rollup safety. Ideally, BTC network would actively verify rollup proofs—like ETH—and reject invalid data. Additionally, assets must be trustlessly withdrawable to BTC even under worst-case scenarios—such as when rollup nodes/orderers fail or censor transactions—via secure escape hatches.

For BTC, which lacks smart contracts and supports only script execution, MAST might be used to compose scripts into logic circuits for verifiable proofs. Though difficult, this aligns with BTC’s most native approach.

BitVM

BitVM is the most discussed BTC scaling protocol—an optimistic rollup on BTC.

BitVM innovatively introduces a fraud-proof challenge mechanism on BTC. Provers and challengers each deposit equal BTC amounts into a transaction (as inputs), with outputs containing a logic circuit. BTC scripts act like simple logic gates—the fundamental building blocks of computers.

When logic gates are combined in a tree structure, they form a circuit with specific logic (imagine the human computer in “The Three-Body Problem”).

BitVM embeds a fraud proof within a massive circuit composed of BTC scripts. The circuit structure reflects the rollup sequencer’s batched transactions. Challengers can repeatedly submit hashes, provers execute corresponding scripts and reveal outputs to prove correctness.

Through a series of transactions, challengers progressively test the prover until every gate is verified. At that point, BTC network completes rollup validation, and the prover reclaims their funds. Otherwise, the challenger claims the prover’s staked BTC. In simpler terms, BitVM relates to BTC much like Optimism does to ETH—offering the highest security among current BTC scaling proposals. However, BitVM generates massive transaction volume, high cost, and requires extensive pre-signing (heavy off-chain computation) before on-chain verification.

Unlike ETH’s optimistic/zk rollups, BitVM lacks an emergency BTC withdrawal channel—requiring at least one honest node on L2 for normal exits.

Still, this represents the strongest security currently possible for BTC L2: DA posted, BTC L1 verifies rollup data validity, trust-minimized BTC bridge—only missing an “emergency escape hatch.”

While implementation seems distant, recent discussions about unblocking the op_cat script could accelerate BitVM’s development. op_cat concatenates two strings (up to 520 bytes), enabling more complex computation on Bitcoin. For example, BitVM could chain hundreds of logic gates in a single script, drastically reducing transaction count and boosting efficiency by nearly 100x. BitVM’s intricate script composition has inspired numerous L2 projects to explore new “fraud proof” challenges on BTC.

Bison Network

Bison Network is a ZK-STARK sovereign rollup based on Bitcoin. Sovereign rollup means L1 acts only as a DA layer—posting rollup block data—without validating transaction correctness. Rollup nodes handle validation themselves.

Bison submits zk proofs to BTC Ordinals. Users download proofs from BTC and run local clients to verify rollup transactions. Full state verification requires syncing a full node.

Bison’s innovation lies in its BTC L1 bridge. When a user deposits BTC to Bison Rollup, the BTC is split across multiple multi-sig wallets. These wallets support DLCs (Discreet Log Contracts)—a simple logic contract built on Taproot, combining BTC multi-sig and time-locked scripts. Upon deposit, users co-sign future execution transactions with Bison Network for scenarios such as:

Transferring to another party
Withdrawing back to BTC mainnet
No withdrawal for extended periods

These transactions aren’t broadcast immediately. Execution requires oracle input. The multi-sig wallet has three controllers: user, Bison Rollup, and oracle. Any two signatures grant control.

DLCs function like if-then statements on Bitcoin. The oracle supplies the condition (“if”), triggering execution (“then”) via one of the pre-signed transactions. The oracle connects to Bison’s bridge contract. If the bridge receives a request to transfer BTC, the oracle broadcasts scenario ①’s transaction, transferring control to Bison for redistribution. For withdrawal requests, it broadcasts ②, transferring control to the user. If idle too long, the timelock expires, returning control to the user.

Thus, Bison implements BTC withdrawals from rollup with a basic escape channel. However, the system’s weak point is the oracle—if it feeds false data, user funds are at risk. A decentralized oracle like Chainlink could mitigate this. DLC-based “trustless bridges” showcase untapped potential of BTC scripting, as seen with http://DLC.link bridging BTC to ETH and STX. While Bison introduces a simple escape path via a third party, it still lacks BTC L1 verification of rollup proofs.

B² Network

B² Network is a hybrid zk rollup on BTC incorporating “commitment-challenge” mechanics. It consists of two layers: Rollup and DA. The rollup layer uses zkEVM to execute smart contracts, including transaction ingestion, sequencing, batching, ZK proof generation, BTC-address account abstraction, and syncing BTC L1 data (BTC and BRC20 balances).

The DA layer stores rollup data. DA nodes perform off-chain zk verification. After verification, DA nodes write rollup data into BTC Ordinals inscriptions—including DA location, transaction Merkle root, ZK proof data, and hash of the previous BTC proof inscription. Proof verification is central.

On ETH, bridge contracts verify ZK proofs directly on L1. BTC lacks smart contracts, and ZK verification logic is too complex to encode via BTC script circuits (prohibitively costly, possibly exceeding block limits). So B² shifts more computation off-chain, transforming direct ZK verification into an Optimistic-style “fraud proof” challenge.

B² decomposes ZK proofs into multiple scripts, layered into a MAST binary tree. B² nodes send a BTC transaction as reward for fraud challenges.

Once a “fraud proof challenge” transaction is confirmed on BTC L1, challengers can download original data from DA layer and execute scripts off-chain. If final output mismatches the submitted proof, the node is proven malicious, and the challenger seizes the node’s locked BTC, rolling back rollup transactions. If no challenge occurs within the lock period, the node reclaims BTC, and rollup achieves finality.

In B² Network, the first BTC transaction confirms zk proof immutability. While BTC still can’t directly verify zk proofs, implementing “fraud proof challenges” in a second transaction indirectly achieves L1-level verification—ensuring transaction validity and enhancing security. This is a standout innovation. B² also adopts account abstraction, enabling seamless interaction with BTC wallets—praiseworthy UX. However, for BTC withdrawals from L2, it still relies on multi-sig bridge—no escape channel included.

SatoshiVM

SatoshiVM is another BTC-based ZK rollup, similar to B² Network: after generating zk proofs, provers upload proof data to BTC, then send a BTC-containing “fraud proof” challenge, with successful challengers earning BTC rewards.

The difference is SatoshiVM adds two timelocks in the “fraud proof” challenge—start and end times. By measuring how many blocks elapsed before BTC transfer, one can easily verify whether the ZK proof was correct and valid. Its bridging mechanism simply uses multi-sig—nothing remarkable.

Chainway

Chainway is a BTC ZK sovereign rollup that not only uses Bitcoin as a data publishing layer but also as the source for generating ZK proofs. Chainway’s provers must scan every BTC block exhaustively. They read the block header, the previous zk proof, and “forced transactions” inscribed in the block to generate a complete ZK proof. In each BTC block, Chainway submits a transaction inscribing a ZK proof—creating recursive proofs.

“Forced transactions” inscribed via Ordinals serve as Chainway’s “anti-censorship transaction mechanism.” If Chainway rollup nodes fail or persistently reject user withdrawal requests, users can directly inscribe their withdrawal request into a BTC block. Nodes must include these “forced transactions” in rollup blocks; otherwise, zk circuit constraints fail and proof generation halts. In a recent tweet, Chainway claimed inspiration from BitVM and said they’ve found a way to verify zk proofs on Bitcoin for BTC L1 settlement. Clearly, Chainway’s current design relies on sovereign rollup client-side validation. While “forced transactions” partially solve anti-censorship, true BTC L1 settlement remains unrealized.

QEDProtocol

QED Protocol is a ZK rollup on BTC, running on zkevm. Unlike others, QED doesn’t generate zk proofs for all rollup transactions—only for withdrawals from rollup to BTC L1. Similar to BitVM, QED composes scripts into logic circuits to verify withdrawal zk proofs directly on BTC L1. These circuits may involve 1,000 UTXOs—achieving direct verification at enormous cost.

IV. Index-Centric Programming

Tracing back, BRC20 is essentially a BTC L2—its transaction data recorded on BTC, while the ledger runs off-chain in indexers. Although current BRC20 ledgers are fully centralized, we rarely worry about security because all transactions are immutably recorded in BTC’s Ordinals. Anyone can scan the BTC network to reconstruct the BRC20 state. But this kind of scaling only adds new features to BTC—not improving performance.

What if we decentralized the indexer’s ledger? Could that create a new inscription chain? Indeed, unisat_wallet’s $sats-based follow-up services follow this idea—swaps and pools run within their indexer. To gain broad security consensus, decentralization is inevitable. Projects like RoochNetwork take it further—no L1 asset bridging, just running indexers and full BTC nodes, providing read-only data access to smart contracts on their chain.

V. Conclusion

Of course, many projects weren’t covered—some due to lack of detail, others due to my limited bandwidth. The industry evolves rapidly—one new BTC L2 emerges every second. Yet one thing remains unchanged: the inevitable trend of BTC’s ecosystem moving toward Layer 2.

BTC is a train everyone wants to board. From a design standpoint, sidechains are passengers with hanging tickets—connected only via cross-chain bridges—but they’re the earliest usable.
DA-type projects aim to build BTC versions of Celestia and EigenLayer—strong in branding, with opportunities amid broad modularity consensus.
Rollups upload DA and use BTC scripts to implement simple on-chain mechanisms (mostly inspired by BitVM’s bit commitment)—barely stepping one foot into BTC’s security carriage. Who says sovereign rollups relying on self-validation aren’t real rollups? (Credit to Celestia for long-term CX around sovereign rollups)
The crown jewel of BTC L2s is using BTC script logic to verify rollup proofs—only BitVM and #Atomicals’ AVM are attempting this, approaching ETH-rollup security levels. Currently seems distant, but unlocking opcodes like op_cat could accelerate progress—BitVM may arrive faster than expected.