How to define Bitcoin L2 and Layer 2 from an inclusive perspective?
TechFlow Selected TechFlow Selected
How to define Bitcoin L2 and Layer 2 from an inclusive perspective?
The market is defined not merely from a technological perspective, but more so from an ecological standpoint.
Navigating Web3 tides with focused insightsAuthor: jolestar
Recently, Bitcoin Magazine's definition of Bitcoin L2 has sparked debate over what truly constitutes a Bitcoin L2—a discussion that Ethereum’s community has previously experienced. So how should we define L2? We can analyze this from both technical and ecosystem perspectives, and I advocate for an inclusive view of L2.
Technical Definition of L2
To define L2 technically, it must clearly distinguish itself from both L1 and centralized solutions. I believe there are two key points:
1. An L2 does not create new blockspace. Technical solutions that generate new blockspace are fundamentally L1s.
2. An L2 must leverage the L1 for data availability and security. Solutions that create independent blockspace are essentially L1s.
However, clearly, the market doesn’t define L2 purely from a technical standpoint—it is more often defined from an ecosystem perspective.
Ecosystem-Based Definition of L2
When defining L2 from an ecosystem perspective, we focus on how L2 leverages or inherits capabilities provided by the L1. Taking Bitcoin as an example, let’s examine the directions in which Bitcoin’s functionality can be inherited and extended.
BTC Assets
This is a story all L2s tell—how to unlock additional use cases for trillions of dollars worth of BTC assets, whether through trading or staking, offering vast potential. To move blockchain assets from one system to another, a bridge is required. The central challenge here is how to make users trust the bridge and ensure asset security.
From this perspective, any solution that creates utility for BTC assets via a bridge can be considered a Bitcoin L2. Even BTC ETFs could be viewed as a form of Bitcoin L2—an entirely centralized custodial bridge secured through legal regulation. Therefore, the core issue isn't decentralization per se, but rather trust. Decentralized solutions reduce users' trust costs and open opportunities for new projects, but constructing secure, decentralized bridges on Bitcoin remains a key challenge. Can L2s leverage other features of Bitcoin to enhance bridge security?
Additionally, with the development of extension protocols on Bitcoin—such as Ordinals and higher-layer protocols (e.g., BRC20), Atomicals, RGB, Taproot Assets, and others—new types of assets on Bitcoin are growing rapidly. Ensuring that bridges are extensible and capable of quickly supporting new asset types presents another major challenge.
Bitcoin Blockspace
As one of the most decentralized blockchain networks, Bitcoin’s blockspace hasn’t yet reached its full value potential. The recent surge in Ordinals inscriptions can be seen as a discovery of Bitcoin’s value as a data availability layer (DA). The Ordinals protocol defines a scalable data format standard, enabling unified parsing, display, and exchange of data inscribed on Bitcoin.
How Bitcoin extension protocols and L2s can effectively utilize Bitcoin’s blockspace remains an important area of exploration.
Programmability of the Bitcoin Network
Bitcoin Script has limited programmability, primarily enabling three types of locks: time locks, hash locks, and private key locks. Taproot elevates the complexity level of Bitcoin Script, making schemes like BitVM possible. However, a key challenge remains: Bitcoin Script is stateless—it cannot read or accumulate Bitcoin’s state and relies solely on inputs. Whether Bitcoin scripts can be used to implement arbitration remains an open question.
Another direction involves cryptographic innovations, such as protocols using key exchange to construct game-theoretic mechanisms for security—like the Lightning Network. Babylon’s “extractable one-time signatures,” while still lacking published implementation details, are already highly anticipated by the market.
Bitcoin State
Bitcoin’s state includes the following elements:
1. Bitcoin’s timestamp
2. Bitcoin’s block nonce (random number)
3. Bitcoin’s UTXO and UTXO ownership
4. Bitcoin blocks, along with new assets and information attached to UTXOs
We can use these aspects to analyze how different Bitcoin extension protocols and L2 projects extend Bitcoin’s capabilities.
How to Extend Bitcoin
Bridge + Programmable Environment
Given Bitcoin’s inherent limitations in programmability, one approach is to transfer Bitcoin assets into environments with stronger programmability, such as EVM-compatible systems, thereby unlocking new use cases for BTC assets. Examples include BEVM and Merlin. The key lies in bridge design: 1. Can the L2 leverage the security provided by the L1? 2. Is the cross-chain solution extensible?
Extending a Smart Contract Layer on Bitcoin
RGB leverages Bitcoin’s property that each UTXO can only be spent once, implementing a one-time seal mechanism, and uses Bitcoin’s blockspace to publish transaction commitments, creating an off-chain programming environment. Its advantage is perfect alignment with the UTXO model, no reliance on global state, and strong privacy guarantees. However, this same feature also limits its programmability. In this space, CKB’s RGB++ makes trade-offs on RGB’s characteristics, offering richer programming models through its cell-based architecture.
Indexer-Mode Off-Chain Computation
The inscription indexer model can be understood as an off-chain computation model: assets are defined on-chain, their validity ensured by off-chain computation, while supporting global state. Inscriptions can be seen as assets sitting between L1 and L2. If the protocol includes built-in mechanisms for transferring assets between L1 and L2, seamless circulation becomes possible. Furthermore, if the logic for generating and verifying inscription assets is itself encoded and inscribed onto Bitcoin—as with bitseed—it represents another way of extending Bitcoin’s programmability.
Stackable L2
By implementing an indexer for Bitcoin extension protocols via smart contracts, parsing all UTXOs and associated states on Bitcoin, and allowing developers to deploy applications within the indexer via smart contracts, we effectively provide Bitcoin with a new smart contract layer—this is Rooch’s approach.
I previously referred to this model as a "smart indexer," but since "indexer" implies read-only access, I now introduce the term "Stackable L2" to describe all L2 expansion schemes that incorporate the full state of the L1. In this model, the L2 fully inherits all L1 states. Applications on the L2 can read all L1 states while also creating new ones, and L1 and L2 assets can be stacked together to form new composite assets. L2 security can be guaranteed through modular designs. I will elaborate further on this concept in a future article.
In fact, the above approaches can be combined synergistically.
An Inclusive View of L2
If we step back from specific implementations and abstractly consider what L2 means, we see it as a continuous spectrum—from centralized exchanges (CEX) at one extreme to L1s at the other—with various intermediate solutions filling the space between. The two ends represent distinct growth models: CEXs grow primarily through product and user focus, while L1s follow longer development cycles driven by vision and blueprints. L2s sit in the middle, adopting hybrid growth strategies.
Adopting an inclusive perspective, we need not obsess over what qualifies as a “true L2.” Industry innovations—including Validium, Plasma, Sovereign rollups, Optimistic/ZK rollups, Modular Execution layers, Decentralized Compute, sidechains, L2/L3 architectures, and more—should all be seen as part of this spectrum. The industry continues exploring infrastructure for new applications through endless combinations and permutations.
Different projects operate under different assumptions about future applications, leading to varied architectural choices and growth trajectories—some leaning closer to L1, others nearer to CEX. The future remains uncertain, and it's too early to predict which models will succeed. But one thing is clear: after years of experimentation, the industry now has large-scale L1s and large-scale CEXs, and it urgently needs large-scale intermediate layers to bridge the gap.
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
@jolestar
