
BTC ecosystem is transitioning from memes to new infrastructure: L2s opportunity analysis
TechFlow Selected TechFlow Selected

BTC ecosystem is transitioning from memes to new infrastructure: L2s opportunity analysis
BTC L2 is essentially no different from ETH L2, as both fundamentally consist of decentralized cross-chain interoperability plus a high-performance smart contract network.
Author: PeterG
1. Bitcoin ecosystem assets led by Sats represent the first wave, sparking a wealth myth of fair launch, community-driven and equitable wealth creation. 2. The second wave consists of new infrastructure—BTC L2—built specifically to develop the Bitcoin ecosystem. BTC L1 has limited functionality; high-performance, scalable BTC L2 solutions are essential for ecosystem growth. 3. The third wave involves a surge of BTC-based applications built on BTC L2. We are currently transitioning from phase one to phase two.
This article avoids complex technical jargon and formulas as much as possible, aiming to clearly and accessibly outline the full picture of Bitcoin’s Layer2 ecosystem. Additionally, the author analyzes from a practical deployment perspective: what types of BTC Layer2 are more likely to succeed? First, what exactly is BTC Layer2, and what key success factors should a deployable BTC Layer2 possess?
The Essence and Design Principles of BTC L2
In essence, BTC L2 is no different from ETH L2—it fundamentally combines decentralized cross-chain bridging with a high-performance smart contract network. Its core significance lies in enabling high-performance scenarios and applications that cannot be realized on L1 to instead run on L2. Therefore, a deployable BTC L2 essentially comprises two parts: (1) Decentralized cross-chain transfer of BTC from Bitcoin L1 to L2, and (2) enabling BTC on L2 to support a wide range of complex smart contract applications.
Looking at mainstream ETH L2s—whether ARB, OP, or ZKsync—they all follow this same design principle, and BTC L2 should be no exception. Based on this consensus, we can further conclude that a successful BTC L2 must adhere to the following design principles:
1. Is BTC bridged to L2 in a decentralized manner?
2. Can the BTC L2 gain consensus and support from the L1 mainnet user base?
3. Is the BTC L2 sufficiently user- and developer-friendly?
1. Is BTC Bridged to L2 in a Decentralized Manner?
The first step for users adopting an L2 is transferring assets from L1 to L2. Whether this process is decentralized and secure determines the scale—and ultimately the survival—of the L2. Before Bitcoin’s Taproot upgrade, truly decentralized cross-chain transfers were not feasible on Bitcoin. Most BTC tokens operating on other chains used centralized minting or multisig schemes.
For example, RenBTC used a multisig approach (later halted due to team issues), while WBTC relied on BitGo for custodial backing. Pre-2021 so-called BTC L2s failed to achieve true decentralized bridging, which is why the BTC L2 ecosystem never took off.
However, Bitcoin’s 2021 Taproot upgrade introduced Schnorr signatures and MuSig2 aggregate signature technology, laying the technical foundation for decentralized BTC bridging.
2. Can BTC L2 Gain Consensus and Support from L1 Mainnet Users?
Since L2 extends L1, it exists dependent on L1 while also feeding value back into it. Whether the L2 network uses the L1 native token as gas is almost the sole criterion for judging whether it genuinely benefits L1. If the Layer2 network merely uses L1 as a data availability layer, and its economic system and gas fees provide no benefit to L1, it will inevitably fail to gain L1 support.
This would make it no different from building a new L1 from scratch—success would be extremely difficult. Currently, mainstream Ethereum Layer2s all use ETH as gas, whereas certain projects claiming to be BTC Layer2s do not use BTC as gas, and thus have failed to gain traction.
Therefore, whether a BTC Layer2 uses BTC as gas directly determines if it can earn consensus and support from the Bitcoin community.
3. Is BTC L2 User- and Developer-Friendly?
The core purpose of L2 is to extend L1’s application scope and enable functionalities that are impractical on L1 to be implemented easily on L2. Therefore, the programming language and entry barrier of an L2 should be as accessible as possible to developers and users.
If an L2's design is overly complex or imposes high barriers to entry, it will struggle to deliver real expansion value.
It is widely known that nearly all smart contract developers in the crypto space have grown up in the EVM ecosystem. Public data shows that in 2022, there were about 400,000 smart contract developers globally, over 80% of whom were EVM developers. This explains why most successful L1s and L2s adopt EVM compatibility to bootstrap their ecosystems, while non-EVM-compatible L1s often struggle with slow growth due to high migration costs for developers and users.
Thus, for both Bitcoin and Ethereum Layer2s, EVM compatibility is not just a choice of programming language—it's a strategic decision determining whether a Layer2 can truly foster ecosystem prosperity. A Layer2 should prioritize rapid adoption by developers and users, focusing on practicality and real-world deployment rather than chasing "native" purity or technical showmanship.
Most successful Ethereum L2s adopted EVM compatibility, while many Bitcoin L2s tout “Bitcoin fundamentalism” or “orthodoxy” and reject EVM compatibility, opting instead for niche programming languages and development environments. This is one of the key reasons why Bitcoin L2s have yet to take off.
Based on these BTC L2 design principles, let’s review some major existing BTC L2 projects and compare their strengths and weaknesses.
Overview of Major BTC L2 Projects and Their Pros and Cons
Stacks
Stacks positions itself as the smart contract layer for Bitcoin, launching its mainnet in 2018. It uses a “pegging” mechanism to bridge BTC, issuing sBTC on the Stacks network—a method that is essentially a centralized mapping. The network uses its native STX token for gas, not BTC. Miners on the Stacks network mine STX by staking BTC, consuming their BTC holdings in the process.
This design not only fails to win support from Bitcoin users but often provokes strong backlash. Furthermore, its use of the niche Clarity programming language severely limits developer adoption. Despite five years of development, most projects in its ecosystem have seen little traction or remain stagnant. Total Value Locked (TVL) in the ecosystem remains under $25 million.
Summary: According to the three BTC Layer2 design principles, Stacks still relies on a centralized BTC bridging method; it does not use BTC for gas, providing almost no benefit to Bitcoin L1, making it unlikely to gain community support; and its use of the obscure Clarity language hinders developer onboarding. After five years, its ecosystem has not scaled significantly. This proves that Stacks’ design direction is not an ideal BTC Layer2 solution.
Lightning Network
The Lightning Network is the most “orthodox” Bitcoin Layer2, aiming to enable Bitcoin as a “global payment” system. Its core goal is to allow fast, low-cost micropayments on a second-layer network. However, Lightning does not support smart contracts, meaning it cannot host Bitcoin-based ecosystem applications.
Currently, around 4,000 BTC are secured within the Lightning Network. Perhaps inspired by the success of the Ordinals protocol, the Lightning team recently proposed Taproot Assets, a protocol for issuing assets on Bitcoin. Even if assets can be issued via Taproot Assets and circulated quickly on Lightning, this combination only enables asset issuance and transfer—not complex applications.
Summary: The Lightning Network is undoubtedly the most “orthodox” BTC Layer2, but its lack of smart contract support means its purpose is strictly to enhance Bitcoin’s payment capabilities, so it is not a typical Bitcoin Layer2.
Currently, 4,000 BTC (~$140 million) are secured in the Lightning Network. Despite three years of operation, its ecosystem remains in early stages.
RSK
RSK aims to be a smart contract-enabled Bitcoin L2. It uses hash locks to bridge BTC from the mainnet to RSK. However, hash locks are still a centralized method, failing to earn trust from Bitcoin users—hence, very few BTC have been bridged via RSK. Additionally, RSK still uses Proof-of-Work (PoW) as its consensus mechanism. For a Layer2, using a low-performance PoW system severely limits scalability and ecosystem growth.
Although launched in 2018, RSK’s ecosystem has barely developed. Once hailed as one of the “Top Ten King-Level Projects,” it has gradually faded into obscurity.
Summary: According to the three BTC Layer2 design principles, RSK’s BTC bridging method is centralized; its poor network performance results in negligible ecosystem growth. This proves RSK is not an ideal BTC Layer2 solution.
Liquid
Liquid is a Bitcoin L2 launched by Blockstream. In essence, Liquid is a Bitcoin sidechain primarily serving institutions and asset issuers, offering B2B asset issuance and circulation services on a Bitcoin-adjacent chain. Thus, Liquid’s BTC bridging mechanism is relatively centralized, relying on 11 certified multisig nodes to custody BTC—making it functionally similar to a permissioned consortium chain.
Given its focus on institutional financial asset issuance, Liquid prioritizes security and privacy, resulting in a permissioned, consortium-chain model. While Liquid serves a valid niche for B2B clients with high demands for security and privacy, for broader adoption among Bitcoin communities and crypto users, decentralized and permissionless BTC L2s offer far greater long-term potential.
Summary: Liquid is a Bitcoin sidechain designed for institutional clients—an access-controlled consortium chain primarily serving traditional institutions and asset issuers requiring high security and privacy. Its main functions center on asset issuance and trading, with limited support for complex smart contracts. Therefore, Liquid’s service scope is inherently limited and fundamentally different from mainstream decentralized BTC L2s.
RGB
RGB is a BTC L2 built on BTC UTXO and the Lightning Network. Proposed in 2018, RGB has progressed slowly due to multiple unresolved technical challenges. Its core design includes three elements: UTXO state compression and encapsulation, client-side validation, and running non-shared smart contracts bridged via the Lightning Network. RGB is praised for its “orthodoxy”: core data from RGB is compressed and embedded into every Bitcoin UTXO.
That is, RGB’s critical data rides on Bitcoin’s blockchain via UTXOs, leveraging Bitcoin’s security. Yet this feature remains unrealized. Even if achieved, two major problems persist: during client-side validation, users must trace back through every upstream UTXO of an asset—the more transfers, the higher the verification cost and complexity.
Even if verifiable, RGB’s smart contracts don’t truly run on-chain. Each contract is isolated and non-interactive. For example, swapping two tokens issued on RGB cannot be done directly like on EVM chains. Instead, they must be moved to the Lightning Network for interaction—adding significant complexity.
Summary: According to the three BTC L2 design principles:
Layer2 must fulfill the mission of high performance, ease of development, and user-friendliness. BTC Layer2 must serve real applications and users—not remain confined to theoretically “cool” designs. In this regard, RGB’s architecture clearly violates the three BTC L2 principles. Unproven UTXO state encapsulation, client-side validation, and non-shared smart contracts running on Lightning all impose massive entry barriers for developers and users.
Building Bitcoin applications on such a Layer2 would result in poor user experience. Since its 2018 proposal, RGB’s slow progress reflects its extreme complexity and high implementation difficulty—foreshadowing similarly high barriers for future developers and users.
BEVM
@BTClayer2 is a BTC-based, EVM-compatible Bitcoin L2 that uses BTC as gas. BEVM’s core design leverages Bitcoin’s 2021 Taproot upgrade, using MuSig2 aggregate signatures to enable decentralized BTC bridging. MuSig2, introduced in Taproot, allows 1,000 Bitcoin light nodes to form a decentralized asset network that processes BTC transfers securely for BTC L2.
Additionally, BEVM uses BTC as gas—every application on BEVM pays fees in BTC. Crucially, BEVM is fully EVM-compatible, allowing DeFi, GameFi, and other EVM-native applications to seamlessly migrate to Bitcoin Layer2. Users can access BEVM dApps directly via mainstream wallets like MetaMask and OK Wallet. In the future, BEVM plans to bridge BTC and BTC-based assets to additional non-EVM L1 networks, maximizing the expansion of the Bitcoin ecosystem.
Currently, BEVM’s testnet is live with nearly 10 applications deployed—for example, users can trade on a fully decentralized BTC DEX, deposit BTC/Sats as LP assets, and earn DEX yields.
Summary: BEVM achieves decentralized BTC bridging via MuSig2, gains community support by using BTC as gas, and lowers entry barriers via EVM compatibility—making it a practical and compliant solution under the three BTC Layer2 design principles. However, unlike BTC L2s emphasizing “orthodoxy,” BEVM appears less “pure.” Instead of modifying Bitcoin’s limited block space or constrained UTXO model,BEVM chooses to bring BTC—via decentralized bridging—into the mature EVM ecosystem, reducing the difficulty of expanding Bitcoin’s reach. This is BEVM’s key innovation, though it may draw criticism from Bitcoin purists for lacking “authenticity.” Still, in the BTC Layer2 race, market forces will ultimately decide whether “orthodoxy” or developer/user experience matters more.
BitVM
BitVM is a BTC L2 solution proposed in 2023 and remains theoretical. BitVM draws attention for its “hardcore” technical approach. Its core idea is running optimistic rollup-style fraud proofs within Bitcoin scripts. Fraud proofs allow users to challenge suspicious transactions; if misconduct is proven, the dishonest party’s assets are slashed. Valid challenges must occur within a 7-day window (similar to a “7-day return policy”). Challenges after 7 days are invalid—even erroneous transactions become permanently settled on-chain. BitVM runs smart contracts off-chain, with each contract maintaining isolated states. BTC bridging uses traditional hash locks, failing to achieve truly decentralized BTC bridging.
Summary: BitVM’s innovation lies in abstracting complex off-chain smart contracts into fraud proofs, then executing them on Bitcoin via Bitcoin opcodes. Whether this is feasible remains debated within the Bitcoin community. But against the three BTC L2 design principles: BitVM still relies on outdated hash locks for BTC bridging, posing centralization risks. With no public testnet yet available, its development language remains unknown. Given its key innovation is still theoretical, BitVM remains in observation mode.
Conclusion

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














