Bitcoin Layer2: Scaling Solutions, Challenges, and Future Outlook
TechFlow Selected TechFlow Selected
Bitcoin Layer2: Scaling Solutions, Challenges, and Future Outlook
This article delves into the development prospects of Bitcoin L2 technology and its potential impact on the market.
Navigating Web3 tides with focused insightsAuthor: BlockPunk@Researcher of Trustless Labs
1. Introduction
As the Bitcoin network grows and inscription technology flourishes, the BTC ecosystem stands at a critical turning point. Demand for scaling solutions is rising, especially as inscriptions intensify competition for network resources and drive up transaction fees—issues that urgently need resolution. This report dives deep into the development prospects of Bitcoin L2 technologies and their potential market impact, with particular focus on how L2s can onboard BTC assets and enhance security. We analyze various BTC L2 implementations—including sidechains, rollups, and data availability (DA) layers—and assess their ability to attract deposits of native BTC and create new asset types.
Meanwhile, after inscriptions established a new wave of asset distribution, we now face fresh challenges and opportunities. The market cap ceilings achievable through fair launches or meme narratives highlight the urgent need to build further infrastructure to break through these limits. In this process, functional capabilities and the definition of base-layer assets become increasingly important. Inscription-based sidechains not only lower user entry barriers but also introduce novel applications such as DeFi, SocialFi, and GameFi by offering full smart contract functionality. The concept of programming for indexers presents a new paradigm rooted in the native properties of inscriptions—enabling feature and business expansion while reducing server load and potentially leading to an entirely new inscription chain.
Four Waves of Impact
The Bitcoin ecosystem is undergoing a series of transformative shocks that are shaping community consensus and accelerating technological and cultural evolution. From consensus around fair distribution to a cultural renaissance driven by BTC, followed by an explosion of "inscription-based" scaling solutions, and ultimately the pursuit of more robust scalability frameworks, the BTC ecosystem is rapidly evolving.
The first wave was the community's consensus on fair distribution. BRC20 created a completely new type of asset distinct from both fungible tokens (FTs) and NFTs—an innovation grounded in blockchain fundamentals and symbolic of the rise of grassroots culture.
We are currently experiencing the second wave—the cultural renaissance of BTC, where large capital players and exchanges have joined the consensus. More developers are entering the inscription space, launching innovative protocols that spill over onto other chains. BTC’s culture is becoming dominant, though this dominance has also triggered certain issues.
The third wave may be the breakout of "inscription-based" scaling solutions. The rapid growth during the second wave fueled prosperity across the BTC ecosystem but intensified conflict with BTC’s conservative faction due to resource competition. Additionally, poor user experience hindered broader adoption. Therefore, scaling inscriptions themselves (rather than scaling BTC directly) becomes urgent and necessary. However, building native BTC Layer 2 solutions like BitVM remains technically difficult and time-consuming. Compromise solutions will likely come first—in the next six months, we may see numerous new BTC sidechains using inscriptions as native assets (unlike STX), bridging mainchain inscriptions via cross-chain mechanisms.
The fourth wave represents the full maturity of “BTC-native” scaling solutions, featuring complete smart contract capabilities, improved performance, and strong security shared with BTC. High-value inscription assets demand higher security standards, making more native, orthodox, and secure Layer 2 scaling essential. These L2s would use BTC as a DA layer, upload proofs, and even allow verification within the BTC network itself—such as BitVM and Atomicals’ AVM protocol. With strong orthodoxy assured, BTC will increasingly flow into the inscription ecosystem.
Ultimately, we could achieve an experience nearly indistinguishable from Ethereum and its L2s in terms of performance and smart contract functionality—but backed by Bitcoin’s massive community and capital, centered around the core cultural value of “fair distribution,” and powered by “inscriptions” as native assets.
Challenges and Opportunities Coexist
The rapid development of inscriptions has boosted the BTC ecosystem but intensified competition for BTC network resources. Rising fee costs, coupled with the foreseeable increase in BTC’s price, continue to raise the barrier to entry for participants. This has sparked widespread discussion about BTC scaling and attracted significant attention from investors and the community. Notably, there is broad agreement to avoid direct upgrades to BTC L1. Even the most radical discussions center only on unblocking certain OP scripts and exploring remaining potential under Taproot (e.g., CTV and CAT).
Inspired by Ethereum’s rollup and modular architecture advancements, BTC Layer 2 has become the dominant topic in scalability debates—the fastest path to tangible results. The first projects are expected to launch in the coming two to three months, setting the narrative for speculation. Due to BTC’s highly decentralized governance—with no central authority guiding the community—L2 designs are diverse and experimental. This report examines representative BTC L2 projects and related protocols to explore possible paths forward.
Here, I broadly categorize BTC L2s into sidechains, rollups, DA layers, and decentralized indexing approaches, grouping similar projects together. No single entity holds authority over BTC scaling definitions, so my classification is informal and pragmatic.
This analysis focuses primarily on implementation-level details, many of which remain theoretical. In the competition among L2 assets, technology and security define the floor—technology is the ticket, whether first-class, economy, or even a standing pass. But from an asset perspective, two factors matter most: one is the L2’s ability to generate assets—whether by importing inscriptions or creating its own momentum—which cannot be assessed purely technologically; the other is its ability to attract deposits of native BTC, a core competitive advantage heavily dependent on bridge security. After all, “not your keys, not your coins” remains a fundamental tenet, closely tied to system design.
Could BTC ecosystem adoption surpass Ethereum in the future? This report might offer some clues.
Before diving into technical analysis of BTC L2s, it’s essential to understand the foundational upgrades introduced by Taproot:
-
Schnorr signatures enable multi-signature schemes with up to 1,000 participants—forming the basis for many L2 bridge implementations;
-
MAST allows multiple UTXO scripts to be combined via Merkle trees, enabling more complex logic and paving the way for proof systems on L2;
-
Tapscript enhances Bitcoin scripting by allowing a sequence of scripts to determine whether a UTXO can be spent—enabling operations like withdrawals and slashing on L2.
2. Overview of BTC L2 Technologies
Sidechains
Sidechains scale by creating parallel chains with independent consensus and block production rules, connected to the BTC mainchain via cross-chain bridges for asset interoperability.
Functionality above all—being usable is everything. Sidechains offer fast deployment, prioritizing rapid development of business logic. Their security depends solely on the sidechain network itself—a mere “hanging ticket” on the train of BTC security. The only critical link is the BTC bridge.
1. @BTClayer2 BEVM
Most BTC L2s follow the same sidechain model pioneered in ETH scaling, just like BEVM. BEVM deploys a multi-sig address on BTC L1 via Taproot capabilities and runs an EVM sidechain. On this EVM, it hosts a smart contract that accepts BTC withdrawal requests. BEVM uses bridged BTC as gas. When depositing, 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, a BTC withdrawal transaction is broadcast—enabling asset interoperability between the sidechain and BTC.
Unlike traditional solutions like $RSK or $STX, BEVM leverages Taproot-enabled BTC multisig for threshold signatures, allowing theoretically more managers and enhancing fault tolerance and decentralization. However, BEVM does not inherit any security from BTC—it merely enables asset transfer. Its nodes run internal consensus and EVM independently, without submitting proofs to BTC, nor leveraging L1 DA. Transaction censorship resistance relies entirely on the sidechain’s own network—if nodes refuse to include your BTC withdrawal, you lose access to funds on L1, posing a real risk.
The benefit lies in speed and verifiability. BEVM’s custom Taproot multisig improves bridge security and makes it one of the few BTC sidechains already live on mainnet.
2. @MapProtocol Map Protocol
Map is another EVM-architected inscription sidechain, designed to bridge BRC20 tokens from BTC L1 to EVM for low-cost operations. Map operates an enhanced BRC20 indexer. To bridge BRC20 from BTC, users send a new transaction embedding target chain and address info in JSON, which Map indexes to reflect on the sidechain. Withdrawals are initiated via multi-sig BTC transactions by a signing committee under Map’s PoS mechanism. The BRC20 ledger effectively runs on the indexer, with BTC L1 serving as a data source.
Leveraging lower fees, Map supports tools like LessGas for BRC20 minting, the SATSAT inscription marketplace, and Roup for BRC20 bridging. Its inscription-centric approach has attracted a dedicated user base. Using classic PoS consensus, Map uploads checkpoints to BTC L1 to strengthen security and prevent long-range attacks.
3. @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 compared to Taproot-upgraded BTC multisig, resulting in slightly weaker security, though MPC itself is battle-tested.
Merlin integrates Particle Network’s account abstraction, enabling users to interact with the sidechain using familiar Bitcoin wallets and addresses—an excellent UX decision. In contrast, forcing Bitcoin users back to Metamask feels lazy and crude.
With BRC420 and Bitmap already popular, Merlin has built a solid user base. It continues focusing on inscriptions, supporting diverse inscription assets bridged from L1 and offering new inscription minting services on the sidechain.
4. @dfinity ckBTC
ckBTC is a purely cryptographic integration of BTC into ICP, requiring no third-party bridges or custodians. ICP is an independent L1 blockchain whose consensus relies on its unique BLS threshold signature scheme. The ChainKey technology, tightly bound to ICP’s consensus, allows the entire network to jointly manage a BTC threshold signature address—receiving BTC and controlling it via aggregated signatures under consensus—to facilitate withdrawals. ICP also reconstructs BTC’s full UTXO set using an account model, enabling smart contracts on ICP to read BTC state—as if running a full BTC node within ICP.
Because this threshold signature is tightly coupled with ICP’s consensus, ckBTC’s security depends only on ICP and BTC networks, introducing no additional trust assumptions. Thus, ICP’s ChainKey-based threshold signature represents the most secure BTC bridge design today. However, if the IC network fails or rejects transactions, users cannot forcibly withdraw from BTC L1. Moreover, as an independent L1, ICP’s security is self-contained and unrelated to BTC.
Data Availability (DA) Layers
DA layers store data on the BTC chain while offloading computation to off-chain or other chains, aiming to leverage BTC’s security while improving throughput.
Bitcoin is the world’s most reliable trusted data source—period. Using BTC as a source of truth is therefore natural. With theoretical foundations laid by @CelestiaOrg, despite BTC’s high storage cost, there is growing consensus on its role as a DA layer. Indeed, Ordinals and the entire inscription ecosystem already use BTC as DA. Almost all “BTC L2” projects send data to BTC—though often symbolically, representing aspirational visions. Below are some distinctive designs.
1. @nubit_org Nubit
Nubit is a DA protocol extending BTC’s data availability use cases, gaining attention due to backing from Bounce Finance and Domo. Simply put, Nubit operates a POS-consensus chain similar to Celestia and periodically anchors its own DA data—such as block headers and transaction Merkle roots—onto BTC L1. Thus, Nubit’s DA is secured by BTC L1, while Nubit sells its own storage capacity as DA to users and other rollups (“DA inception”). Nubit lacks smart contract capabilities and requires rollups to build atop it. Users upload data to Nubit’s DA layer, which enters “soft confirmation” after POS consensus. Later, Nubit anchors the data root to BTC L1. Only after BTC transaction finality does the original user data reach finality. Then, users must separately tag data on BTC L1 to enable lookup in Nubit’s full-node Merkle tree.
In early stages, Nubit’s POS consensus is supported by Babylon’s BTC staking (to be discussed later). Users pay storage fees in BTC via Lightning Network, avoiding bridge risks—users can exit urgently by closing channels without interacting with Nubit’s POS network. Nubit appears to be a Bitcoin-native version of Celestia: minimalist, no complex smart contracts, relying on the trustless Lightning Network for payments. While Lightning is trust-minimized, UX is subpar and unsuitable for large fund movements (channel exhaustion issues). Nubit’s relationship with BTC L1 is thin—its security isn’t guaranteed by BTC, and BTC-stored data is only verified by Nubit’s node clients.
Why should rollups or inscription data go through Nubit instead of writing directly to BTC? This is perhaps Nubit’s biggest question. Low cost alone may not suffice as a driver. Its key advantage over direct BTC DA might be support for light-node data sampling (DAS)—impossible on BTC itself—meaning users don’t need to download a full BTC node to verify DA. Can non-fully-on-Bitcoin inscriptions gain community consensus? Nubit attempts to replace BTC L1 DA with its own chain’s DA—not facing technical skepticism so much as immense community consensus hurdles. Of course, that also means enormous opportunity.
2. @Veda_bitcoin Veda
Veda reads specific Ordinal inscriptions on BTC L1 and treats them as transaction requests executed in an EVM beneath the BTC chain. Users sign an EVM-compliant transaction with their BTC private key, then mint it as an inscription on BTC. Veda’s EVM nodes scan BTC blocks; once confirmed, the EVM executes the request, changing state. Effectively, BTC acts as Veda EVM’s mempool. However, since BTC’s performance lags far behind ETH’s EVM and data written per block is limited, Veda EVM can always process all uploaded EVM requests.
BTC serves as the sole source of all Veda states. Anyone can reconstruct the full EVM state by scanning all Veda-related BTC blocks. This enables optimistic trust in Veda EVM with minimal security assumptions. Yet, Veda cannot scale BTC’s performance. Think of it as an Ethereum network with 10-minute block intervals, ~5 TPS, but tens of thousands of nodes and massive PoW hashpower. It extends BTC’s functionality by adding smart contracts—but doesn’t solve resource contention.
3. @babylon_chain Babylon
Babylon is a protocol helping other blockchains share BTC’s security, consisting of two parts: Bitcoin staking service and Bitcoin timestamping service. It enables BTC staking to provide economic security for PoS chains (similar to ETH restaking), operating entirely via cryptography—no third-party bridges or custodians needed.
BTC stakers send a transaction with two UTXO outputs to stake: one contains a timelocked script allowing the staker to reclaim BTC after expiry; the other sends BTC to a temporary address whose key pair meets the cryptographic standard of “extractable one-time signatures (EOTS).” When a staker runs a PoS chain validator node, they sign the unique valid block using the EOTS private key.
If the staker (also a validator) remains honest—signing only one valid block—they earn rewards from the PoS chain. If malicious—signing two blocks at the same height—their EOTS private key can be reverse-engineered, allowing anyone to claim and transfer their staked BTC, enforcing slashing. This incentivizes honesty. Babylon also offers timestamping—anchoring checkpoints of any blockchain into BTC’s op_return—for added security.
Nubit plans to use Babylon’s staking service for enhanced security. Babylon’s pure-cryptographic approach to deposits, withdrawals, and slashing offers high security. But for chains using the staking service, this creates economic constraints rather than full verifiability—falling short of ETH-style rollup models. Timestamping uploads L2 data to BTC, but verifying requires downloading the full BTC node—high barrier. Plus, BTC L1 lacks smart contracts to validate data correctness.
Rollups
Rollups store state and transaction data on BTC’s data layer but process computation and state changes off-chain, submitting proofs or state diffs back to BTC L1 to ensure security.
The core challenge for BTC rollups is verification. Through Ordinals, Bitcoin can store arbitrary data—making it a highly secure database. Uploading rollup proofs to BTC ensures immutability, but not the validity or correctness of internal transactions. Most BTC rollups may opt for sovereign rollups (client-side validation): validators sync all rollup data off-chain and verify independently. But this fails to harness Bitcoin’s greatest strength—PoW consensus across hundreds of thousands of nodes—to secure rollups. Ideally, BTC network would actively verify rollup proofs like Ethereum does, rejecting invalid blocks. Also crucial is ensuring assets can be trustlessly withdrawn from rollups to BTC—even if rollup nodes/orderers fail or censor transactions—via secure escape hatches. For BTC, which lacks smart contracts and supports only script execution, MAST might enable combining scripts into verifiable logic circuits. Though difficult, this aligns with BTC’s most native approach.
1. @ZeroSync_ BitVM
BitVM is the most watched BTC scaling protocol—a kind of Optimistic Rollup on BTC. It innovatively introduces fraud challenge mechanisms on BTC: provers and challengers deposit equal amounts of BTC into a single transaction (as inputs), whose output contains a logic circuit. BTC scripts act like basic logic gates—the fundamental units of computing. When arranged in tree-like structures, these gates form circuits encoding specific logic (imagine the human CPU from *Three Body Problem*).
BitVM embeds a fraud proof within a massive circuit composed of BTC scripts, structured based on the rollup sequencer’s batched transactions. Challengers repeatedly submit hashes to this fraud-proof circuit, while verifiers execute corresponding scripts and reveal outputs to confirm correctness. Through successive transactions, challengers can progressively challenge provers until every gate is proven correct. Thus, BTC network completes rollup validation, and the prover reclaims funds. Otherwise, the challenger wins the prover’s staked BTC. Put simply, BitVM relates to BTC much like OP does to ETH—offering the highest security among all scaling solutions. However, BitVM generates vast numbers of expensive transactions 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, it offers the strongest available security for BTC L2: DA published, L1 verifies rollup data validity, trust-minimized BTC bridge—only missing an “emergency escape hatch.” Implementation seems distant, but recent community discussions about unblocking op_cat could accelerate progress. op_cat concatenates two strings (up to 520 bytes), enabling more complex computations on BTC. For example, BitVM could chain hundreds of logic gates in one script, drastically reducing transaction count and boosting efficiency by orders of magnitude. BitVM’s intricate script composition has inspired many L2 teams to develop new “fraud proof” challenges on BTC.
2. @Bison_Labs Bison Network
Bison Network is a ZK-STARK sovereign rollup built on Bitcoin. Sovereign rollups treat L1 as a data availability board (DA), not validating rollup transaction correctness—validation handled by rollup’s own nodes. Bison submits its ZK proofs to BTC Ordinals. Users can download proofs from BTC and run local clients to verify rollup transactions. Full state verification requires syncing a full node.
Bison’s standout feature is its BTC L1 bridge design. When a user deposits BTC to Bison Rollup, the BTC is split across multiple multi-sig wallets containing BTC. These wallets support DLC (Discreet Log Contracts)—simple logic contracts based on Taproot, leveraging BTC multisig and timelock scripts. Upon deposit, users co-sign future execution transactions with the Bison network for scenarios: a) transferring to others; b) withdrawing back to BTC mainnet; c) reclaiming after prolonged inactivity. These transactions aren’t broadcast—they’re triggered by oracles. Control of the multisig wallet rests with three parties: user, Bison Rollup, and oracle—any two signatures control the funds.
DLC acts like an “if-then” statement on Bitcoin. The oracle provides the condition (the “if”), triggering execution (the “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 to someone, the oracle broadcasts transaction a); if withdrawal requested, transaction b) executes, transferring control to user; if silent too long, timelock expires, returning control to user. This creates a simple escape mechanism from the rollup. However, the weak point is the oracle—if it feeds false data, user assets are lost. Decentralized alternatives like Chainlink could help. DLC-based “trustless bridges” unlock BTC script potential—http://DLC.link uses it to bridge BTC to ETH and STX. While Bison achieves a basic escape path via a third party, it still doesn’t enable BTC L1 to verify rollup proofs.
3. @BsquaredNetwork B² Network
B² Network is a hybrid ZK Rollup on BTC incorporating “commitment-challenge” mechanics. The network has two layers: Rollup and DA. The Rollup layer uses zkEVM to run smart contracts, handling transaction intake, sequencing, packaging, ZK proof generation, account abstraction for BTC addresses, and syncing BTC L1 data (BTC and BRC20 balances). The DA layer stores rollup data—nodes perform off-chain zk verification. After validation, DA nodes write rollup data into BTC Ordinals inscriptions, including DA location, transaction Merkle root, ZK proof, and hash of the previous BTC proof inscription.
Proof verification is key. On ETH, bridge contracts directly verify ZK proofs on L1. BTC lacks smart contracts, and ZK verification logic is too complex to implement via BTC script circuits (prohibitively costly, possibly exceeding block limits). So B² moves more computation off-chain, transforming direct ZK verification into an Optimistic-style “fraud proof” challenge. B² decomposes ZK proofs into different scripts, layered into a MAST binary tree. B² nodes send BTC in this transaction as a reward for successful challenges.
Once the challenge transaction is confirmed on BTC L1, challengers download raw data from the DA layer and execute scripts off-chain. If final output mismatches B² node submissions, the node is deemed malicious, and the challenger gains control of BTC locked in the script root—all rollup transactions rollback. If no challenge occurs within the lock period, the node reclaims BTC, and the rollup achieves finality.
In B² Network, the initial BTC transaction confirms ZK proof immutability. Although BTC still cannot directly verify ZK proofs, the secondary “fraud proof” challenge indirectly achieves L1 verification, ensuring transaction validity and enhancing security—an impressive innovation. B²’s inclusion of account abstraction lets users interact with the rollup using BTC wallets seamlessly—a major UX win. However, BTC withdrawals still rely on multisig bridge methods, lacking an “escape hatch.”
4. @SatoshiVM SatoshiVM
SatoshiVM is another BTC-based ZK Rollup, logically similar to B² Network: after generating zk proofs in the rollup, the prover uploads proof data to BTC, then sends a “fraud proof” challenge containing BTC—successful challengers earn the BTC reward. The difference is SatoshiVM adds two timelocks in the challenge: one for start time, one for end time. By comparing how many blocks elapsed before BTC transfer, one can easily determine whether the ZK proof was valid. Its bridge implementation uses standard multisig—nothing notable.
5. @chainway_xyz Chainway
Chainway is a ZK sovereign rollup on BTC—not only using Bitcoin as a data publishing layer but also sourcing BTC data to generate ZK proofs. Provers must scan every BTC block exhaustively. They read the block header, the previous zk proof, and “forced transactions” inscribed in the block to produce a complete ZK proof. In each BTC block, Chainway submits a transaction inscribing a ZK proof—creating recursive proofs.
“Forced transactions” inscribed in BTC blocks 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 recent tweets, Chainway claimed inspiration from BitVM, saying they’ve found a way to verify ZK proofs on Bitcoin to achieve BTC L1 settlement. Clearly, current Chainway design relies on sovereign rollup client-side validation. While “forced transactions” partially address node censorship of rollup transactions, true BTC L1 asset settlement remains unrealized.
6. @QEDProtocol QED Protocol
QED Protocol is a ZK rollup on BTC, running on zkEVM. Unlike other ZK rollups, 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 transaction ZK proofs directly on BTC L1. These circuits involve up to 1,000 UTXOs—achieving direct verification at enormous cost.
3. Inscription L2 — Re-Thinking BTC Scaling
After the dramatic wave of new asset distribution, the primary narrative of inscriptions has been established—we now face new opportunities and challenges. Relying solely on fair launches or meme stories, a $200 million market cap seems to be a ceiling. Without continued foundational work, breaking through this limit will be hard (“the end of fair launch is PUA”). During this return to rationality, utility becomes paramount—either offering more functionality or becoming a base-layer asset.
“Inscription-based” sidechains may represent the next major step. We call them sidechains, not L2s, because these “L2s” do not leverage BTC’s security. But like Polygon relative to ETH, inscription L2s can effectively lower user entry barriers and strike compromises with BTC’s conservative camp. Most importantly, full smart contract capabilities open new gameplay possibilities for inscriptions—DeFi, SocialFi, GameFi, etc.
BRC20 and its derivatives write token information into human-readable JSON, offering extreme flexibility—tokens can be split arbitrarily via the “amt” field. This flexibility suits interaction with inscription L2s well: once the L2 reads JSON and reconstructs BRC20 state, subsequent DeFi and other services become easy to deploy. As a new asset class distinct from NFTs and FTs, inscription L2s can build businesses around inscriptions themselves—with native assets ideally being inscriptions. If an inscription L2 merely bridges inscriptions, splits them into FTs, and copies Ethereum DeFi patterns, it will lack appeal—given today’s traders already find FT trading low-value. Since BRC20 indexing itself forms a ledger, reading the index and launching an EVM chain preserves inscription traits. Continuous innovation in non-FT DeFi paradigms is key.
Programming for Indexers
Must BRC20 and JSON-based inscription sidechains necessarily follow ETH’s model? Actually, EVM sounds boring—we don’t need to reinvent L2s from scratch. Perhaps starting from inscriptions’ native properties to expand functionality and business models would be more interesting.
BRC20 is an on-chain record system using BTC as storage. For scaling such systems, perhaps more business logic can be added directly into off-chain indexer servers. For example, introducing new primitives beyond “mint,” “deploy,” and “transfer” in the JSON “op” field—enabling listing, collateralization, burning, authorization, etc. Combinations of these “op” fields could evolve into swap, lending, and other Inscription-Fi (Inscription Finance), even complex SocialFi and GameFi. This is essentially programming for indexers—akin to Web2 API server programming. It’s easier to implement, can start from a single indexer, yet yield significant impact. UniSat’s swap features, along with protocols like BRC100, ORC20, and Tap, are pioneers in this JSON-scaling school—poised to bring rapid change. Adding cryptographic primitives is exciting, but decentralization remains crucial. Programming for indexers inevitably increases server load, making community operation harder. Complex business logic demands consistent consensus, eventually pushing toward smart contract platform development. Could decentralizing the indexer’s ledger itself spawn a new inscription chain?
Indeed, @unisat_wallet's follow-up services based on $sats follow this idea—swap and pool functions run on its indexer. To achieve consensus on fund safety, decentralization is inevitable. There are also projects like @RoochNetwork—read-only L2s that don’t source assets from L1 but run indexers and full BTC nodes, providing data for on-chain smart contracts.
More Native Approaches
BTC L1 issuance falls into two main schools: the JSON-based approach described above, and Atomicals’ unique UTXO-based model (Rune’s definition remains fuzzy, so excluded). ARC20 tokens under Atomicals are directly represented by BTC UTXOs—no JSON updates required. Direct manipulation of UTXOs enables powerful features—like swapping arc20 tokens with BTC, consuming arc20 to mint new arc20, etc. Controlling transaction inputs and outputs can even enable simple DeFi functions, though this raises developer complexity. The benefits are clear: all logic processed directly by BTC network, sharing maximum security and consensus. Seamless BTC asset integration avoids reliance on third-party bridges—adhering to “not your keys, not your coins.”
Clearly, ARC20 isn’t Turing-complete. Hence, Atomicals, inspired by BitVM, proposed AVM—a BTC L2 where proofs are submitted and verified by BTC script logic circuits on L1. ARC20, as UTXO-backed assets, naturally serve as collateral for fraud proofs in AVM. This represents the ultimate BTC scaling narrative: achieving smart contract functionality while sharing BTC’s security via DA. Likely arriving in Wave Four, AVM may progress faster than expected—recent updates from Atomicals developer @wizzwallet suggest promising developments.
4. Conclusion and Outlook
The industry evolves rapidly—one new BTC L2 emerges every second—but the trend toward L2 adoption in the BTC ecosystem remains inevitable. BTC is a train everyone wants to ride. Sidechains are passengers with hanging tickets—connected only via bridges, but earliest to use. DA projects aim to build BTC versions of Celestia and Eigenlayer—strong on branding, viable amid broad modularity consensus. Rollups upload DA and use BTC scripts to implement basic on-chain mechanisms (mostly borrowing BitVM’s bit commitment ideas), barely stepping half a foot into BTC’s security carriage. Who says sovereign rollups relying on self-validation aren’t real rollups? (Credit goes to Celestia for long-term CX of sovereign rollups.) The crown jewel of BTC L2s is using BTC script logic to verify rollup proofs—only BitVM and Atomicals’ AVM attempt this, approaching ETH-rollup security relationships. Currently seeming distant, unlocking op_cat and similar opcodes could accelerate progress—BitVM may arrive sooner than expected.
Through in-depth analysis of BTC L2 technologies, we recognize that despite challenges, the BTC ecosystem’s future holds infinite possibilities. From consensus on fair distribution to inscription-based scaling, to mature solutions sharing BTC’s robust security, Bitcoin undergoes historic transformation. These technologies promise to significantly enhance BTC’s scalability and efficiency, introduce new asset types and transaction models, and unlock unprecedented opportunities for users and developers. Yet success demands collective effort—community consensus, technical maturity, and real-world validation. Throughout the search for optimal L2 solutions, security, decentralization, and user experience remain paramount. Looking ahead, with technological advances and community collaboration, BTC L2s may unleash new potential in the Bitcoin ecosystem, bringing greater innovation and value to the crypto world.
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
@TrustlessLabs
