Rewriting the BTC L2 Story: A Rollup-Centric Design Principle
TechFlow Selected TechFlow Selected
Rewriting the BTC L2 Story: A Rollup-Centric Design Principle
The Bitcoin-centric rollup approach focuses on ensuring that BTC's value and security can be extended to the rollup.
Navigating Web3 tides with focused insightsAuthor: Zuoye
Bitcoin's scaling path ≠ BTC L2.
At the beginning of the year, I summarized the technical roadmap for BTC L2, mainly divided into two parts: the security and value appreciation of BTC itself, and the downstream transaction execution and result settlement on L2. In just under three months, the number of BTC L2 projects has already reached nearly one hundred. However, some fundamental issues remain unclear, with definition being the top priority.
In Bitcoin’s development history, there have long been three practical approaches to scaling: at the most fundamental level, mainnet upgrades such as SegWit and Taproot; secondly, off-chain scaling solutions like client-side validation, Lightning Network, and sidechains; and finally, direct forks such as Dogecoin, BSV, and BCH.
Bitcoin Scaling Path Options
With so many complex options from inside out, there is widespread disagreement about what exactly constitutes a BTC L2. Drawing lessons from Ethereum’s evolution, I propose two key criteria:
-
An L2 must first be a standalone chain capable of independently handling computation and transactions, ultimately settling results on Bitcoin;
-
The security of the L2 must be fully guaranteed by L1, its underlying value supported by BTC, and its native token should not interfere with BTC’s core functionality.
By these standards, mainnet upgrades and hard forks are unrelated to the concept of L2. The focus lies in how to categorize off-chain scaling efforts—Lightning Network, for example, is a special kind of "channel" and hardly qualifies as a public blockchain, while sidechains have their own consensus and operational models but cannot strictly match Bitcoin’s security level. Yet, the true BTC L2 likely resides somewhere within this spectrum—so let’s further subdivide.
BTC L2 = Lightning Network + Sidechains.
Based on the above criteria, BTC L2 should be a hybrid of Lightning Network and sidechains—fully dependent on Bitcoin’s mainnet like Lightning, yet operating “independently” like a sidechain, taking the best from both while avoiding their weaknesses.
Thus, existing BTC L2 schemes need further development, especially considering the inherent incompatibility between Bitcoin’s UTXO model and the smart contract mechanisms required by Layer 2s—Bitcoin cannot natively roll back past transactions, requiring L2s to solve this themselves or introduce external update or indexing mechanisms.
Secondly, L2 independence can go too far—for instance, merely storing Bitcoin block headers as synchronization proofs from L2 to L1, or only recording settlement data in Bitcoin scripts as a DA solution, without addressing subsequent retrieval and verification.
The current state of BTC L2 is vulnerable to bad actors, leading to potential security and trust crises. I believe we must shift from an L2-centric approach to a Rollup-centric paradigm—one that fully leverages Bitcoin’s security while solving large-scale computation challenges.
BTC L2 ≠ Rollup.
-
Build a PoS system on BTC to provide security, using permissionless participation and burn mechanisms instead of current wrapped asset models.
-
Staking rewards should be denominated entirely in BTC, and project tokens must not conflict functionally with BTC.
-
The Rollup computation layer must support both high throughput and privacy needs, using cryptographic techniques to resist centralization.
-
Rollup must not build an additional DA layer—it must strictly use Bitcoin as its DA solution.
To summarize, the ideal Rollup would use BTC as native gas fee and staking reward, leverage a two-way peg (2WP) mechanism for cross-chain circulation, circulate 1:1 pegged xBTC assets across BTC L2 and inter-L2 bridges, integrate privacy-preserving computation with ZK proofs to ensure full anonymity and privacy for Bitcoin users from origin to outcome, and allow project tokens to participate in Rollup operations without conflicting roles with BTC.
Rollup: Like a Bridge, Like a Chain, Like an L2
BTC Rollup Operation Flow
First, we must解放思想 (embrace new thinking): PoW base layer + PoS upper layer is currently the optimal combination. Staking yield depends on underlying value support, engineering composition replaces pure technological innovation, and debating ZK vs OP is no longer meaningful. Result storage is not DA. Also, don’t over-focus on centralized vs decentralized design—no solution matches Bitcoin’s decentralization, not even ETH OP, whose actual fraud proof and recovery mechanisms remain theoretical or aspirational. In practice, project teams still retain control in the short to medium term.
Therefore, more reasonable mechanism design focuses on minimizing human intervention through technical means and ensuring long-term stable operation. In ETH L2s, this is known as forced withdrawals and escape hatches—ensuring user funds remain safe even if the project halts. For BTC Rollup, the challenge lies in how to return pegged assets to the Bitcoin mainnet during failures, and how to protect privacy during Rollup computation, especially before achieving full decentralization.
Let’s start with the first point: BTC’s pegged assets, such as decentralized versions of WBTC. While circulating on Rollup, they must maintain security—on one hand, BTC deposits must support Rollup’s value foundation; on the other, Rollup BTC must be redeemable back to the mainnet when failures occur.
Current solutions are mostly variations of cross-chain bridges, differing only in whether they’re message bridges, asset bridges, or centralized bridges. At this point, it seems unlikely new bridge designs will emerge. Bridging assets is the first step toward building a PoS system.
However, staking and staking rewards still offer room for innovation—for example, skipping Lido-style development and directly adopting DVT technology to build a fully decentralized staking system, or creating a hybrid staking system based on re-staked BTC derived from BTC, WBTC, or BounceBit via exchange-based structures, reducing systemic risk during crises.
After bridging and implementing DVT/hybrid staking, Rollup computation remains largely overlooked. The issue here is that Rollup itself must handle four stages of public chain operation: data throughput, state updates, result storage, and data distribution. This can be broken down into two aspects: efficiency and privacy.
-
Efficiency is straightforward—using parallel or concurrent processing. After the initial FOMO phase, Bitcoin Rollups must compete with ETH Rollups on performance, and speed has already been proven effective by Solana.
-
Privacy has long been neglected. Bitcoin’s PoW makes it nearly censorship-resistant, but early-stage Rollups may face similar issues to post-merge ETH PoS—certain nodes may succumb to or comply with censorship. Decentralized design alone cannot resolve this, as no alternative matches BTC PoW’s resistance. Privacy-preserving computation must therefore play a key role.
Finally, there’s the DA issue. Referring to the standard distinguishing ETH L2s and Rollups, any solution not using the mainnet for DA cannot truly be called a Rollup—it breaks the final security commitment. If an L2/Rollup voluntarily gives up L1 security guarantees, it should be excluded. Given BTC’s unique mechanics, additional design considerations are necessary.
DA Mechanism
-
Hybrid optimistic and ZK verification is becoming mainstream—transactions on Rollup are ultimately confirmed by the mainnet. Fraud proofs use optimistic logic: confirm first, dispute later, and finalize after timeout. Meanwhile, ZK proofs can drastically compress data, which is especially important for BTC Rollup due to Bitcoin’s high data costs.
-
Inscriptions can play a greater role in transaction mechanisms. On ETH Rollup, if a fraud proof is challenged and accepted by Ethereum, the submitter’s stake is slashed on-chain. But on BTC Rollup, slashing must occur off-chain because once written into Bitcoin’s script, data cannot be altered—only updated by writing new information into subsequent blocks. That is, you can only Update, never Overwrite.
-
Indexer networks must bear the critical responsibility of transaction updates and must themselves be decentralized.
Ultimately, we can complete the full mechanism design for BTC Rollup, structured in four steps: xBTC → Staking → Computation → DA. Key challenges lie in the design principles of the staking system and pegged assets, privacy in on-chain computation, and the final DA architecture.
Additionally, following the principle that project tokens must not conflict with BTC, they should serve internal Rollup functions—such as supporting DVT systems, maintaining decentralized indexers, and facilitating ecosystem growth and governance.
Broad Landscape: Horizontal and Vertical Review of BTC L2
Architecture Overview
If we apply my defined Rollup standard strictly, many existing projects would fall outside the scope. So to broaden the discussion, I’ll include those exhibiting relevant characteristics.
Following the four-step framework, we can briefly compare current mainstream technical approaches. Note that each step builds upon the previous one, so earlier assumptions (e.g., bridging exists) won't be reiterated later (e.g., when discussing staking).
Starting with asset bridging, ZetaChain and Zeus Network best meet the criteria, connecting Bitcoin with EVM and Solana ecosystems respectively. Their implementations differ slightly.
ZetaChain introduces ZRC-20, analogous to ERC-20, allowing BTC to be 1:1 mapped into zBTC. To emphasize its omnichain Omni vision, zBTC uses an internal swap mechanism rather than physically transferring across chains, making it a so-called omnichain asset. However, this requires robust mechanism design. ZetaChain achieves interoperability with non-smart-contract blockchains like Bitcoin using observers and signers to monitor on-chain events and reach consensus on ZetaChain.
Theoretically, ZetaChain is a full-chain bridge—not limited to Bitcoin-EVM interaction—but highlights how non-smart-contract chains can connect to EVM environments. Notably, ZetaChain functions as both a message and asset bridge.
Zeus Network, by contrast, positions itself as a communication layer rather than a bridge. It provides a standardized interface enabling different blockchains to exchange information and value.
For example, BTC can be locked in a specific Bitcoin address, releasing equivalent assets on Solana. This allows actual BTC transfer and enables smart contract actions on Solana to influence behavior on Bitcoin.
This feels somewhat semantic—while theoretically you don’t need to move assets between chains, in reality you still can’t truly bring BTC onto Solana. Whether bridging assets or messages, third parties are inevitably involved to facilitate calls and communication—the difference lies only in the degree of involvement.
Once assets are bridged, staking systems emerge. Staking mimics Ethereum’s security model, seen in Stake, LSDFi, Restake, and LRTFi—each relying on staking to secure the network and issuing liquid derivatives for DeFi yield, varying mainly in levels of composability ("matryoshka doll" depth).
In Bitcoin’s context, Merlin Chain represents the staking model, while BounceBit exemplifies LRTFi. Both aim to keep assets within their ecosystems—not just passive yield generation, but expanding utility and ecosystem boundaries, marking the dawn of the usability era.
Beyond aggressive marketing, Merlin Chain focuses on ecosystem development through L1 BTC multisig and L2 smart contracts, building use cases like Merlin Swap and Merlin Starter. Among current Layer 2s, it’s arguably the most active. Sharing roots with ETH L2 ZKFair under Lumoz, and partnering with Cobo on L2 asset management, it boasts a TVL of $3.6 billion—the highest tier today.
BounceBit goes further—or perhaps regresses.
Its advancement lies in generating re-staked assets via exchanges—users deposit BTC on Binance, receive wrapped assets on BNB Chain, and engage in CeFi and DeFi activities. Using custody tech, BounceBit issues LRTfi tokens while safeguarding BTC, building an EVM-compatible system linking to the broader on-chain world.
CEXs and custodians form the operational backbone. BounceBit’s uniqueness lies in re-liquifying locked BTC, injecting it into value-creation cycles. With a TVL of $700 million, it allows staking of BTC or its native token, generally adopting more centralized measures to reduce BTC operational risks.
The regression? It’s essentially a slightly improved version of WBTC—untested over time, possibly less secure than WBTC’s established track record.
Next comes on-chain computation, involving two key issues: sequencer design and sequencer decentralization, followed by compatibility and computational efficiency.
Sequencer centralization is a chronic problem in ETH L2s. Centralized sequencers greatly improve L2 efficiency, mitigate MEV attacks, and enhance user experience. But they also create severe centralization risks, making project teams de facto operators.
B² Network attempts to build a decentralized sequencer network using its BSQ token—an incentive layer requiring multiple roles (submitters, provers, challengers) to maintain operations, trading governance complexity for reduced centralization.
Compatibility with EVM or SVM is relatively easy, but cross-L2 interoperability is more complex. Computational efficiency requires widespread adoption of parallelism or concurrency—currently lacking clear frontrunners.
Regarding privacy in on-chain computation, although ZK-Rollup solutions exist, they’re primarily used for data compression—especially in DA data publishing. Dedicated privacy-preserving computation frameworks remain underdeveloped.
Finally, data availability (DA) publication methods must be discussed alongside ZK mechanisms. Unlike ETH L2s, BTC L2s use ZK mainly for data compression—Bitlayer being a prime example.
Bitlayer uses optimistic verification to reduce complexity, applies ZK for data compression, and writes data in inscription-like formats. Specifically, it assumes transaction batches are valid by default unless proven otherwise. Transactions are processed off-chain and submitted in compressed form to Bitcoin, reducing load and cost. If fraud is detected, participants can challenge it, triggering state rollback and penalizing malicious actors to ensure system security.
However, implementing state rollback on Bitcoin may not be simple and will require long-term exploration.
Conclusion
Starting from Bitcoin’s scaling options, this article attempts to outline what a Rollup-centric Bitcoin ecosystem might look like. The core lies in ensuring BTC’s value and security can be extended to Rollups, clearly differentiating from existing wrapped asset models. In practice, bridged assets and staking systems have become common starting points. However, how to ensure decentralization and properly balance the roles of BTC and project-native tokens remains ambiguous.
Nevertheless, the Rollup-centric approach remains the most comprehensive and mature path forward—more advanced than UTXO-based or client-side validation models. In the intermediate on-chain stages, privacy-preserving computation and sequencer decentralization are critical. For final DA, inscriptions offer valuable reference points. The only major hurdle remains cost.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@zuoyeweb3
