- Fierce competition among EVM L2s/side chains with indistinguishable value propositions: The competition shifted from "who's the most trustless" to who can 1. execute the most sophisticated airdrop game, and 2. access the deepest liquidity via BTC "whales." This shift also explains the geographic concentration of L2s emerging from APAC.
- Intensified fragmentation across
- Liquidity & scaling solutions: Over 80 sidechains/rollups, along with 5+ metaprotocols.
- Token standards: A duopoly exists between BRC20 and RUNE, followed by a long tail of ARC, CRBC, RGB, among other metaprotocols.
- Indexer: Each token standard necessitates its own indexer.
- Side Chains & Rollups' Aspirations for BitVM to Trustlessly Peg Them Back to L1: I've become quite skeptical of “L2s” that initially position as a side-chain and claim to become "trustless" upon integrating with BitVM. My skepticism is two-fold:
- Technical Feasibility: The on-chain implementation of "optimistic rollup" style verification involves developing millions, if not billions, of logic gates. This process is not only costly because it operates on the base layer, but it's also slow due to the constraints imposed by the BTC block time. Moreover, it could take a significant amount of time to complete. To my knowledge (please correct me if I'm mistaken), BitVM has become a community project, facing the usual challenges of decentralization: no single entity is accountable for its development timeline, milestones, quality, and overall success.
- GTM timing: According to various sources, BitVM will not be ready for another 18-24 months. Even if everything goes perfectly for BitVM and they deliver on their promises, this means these L2s will remain centralized via multisig for the foreseeable future. What will they compete on until then?
- A wide array of trust assumptions across L2 (side chains + rollups), and metaprotocols It might be worth clarifying the taxonomy of what constitutes a side chain vs. a rollup. Below is a table detailing the difference based on conversations we’ve had over the past few months - feedback is welcome.
- Trust assumption of side chains
- The peg between the BTC base layer and Layer 2 solutions is primarily managed centrally through a multisig controlled by the core team.
- The state and transaction finality are not verified by the BTC base layer, but instead by the project team.
- Trust assumption of ZK Rollups
- Currently, there's no way to perform zk verification on Bitcoin. Sequencers need to be centralized (similar to ETH L2s), and there's a trust assumption that the decentralized verifier network will correctly verify the transactions checked by provers.
- Rollups are limited in the number of transactions they can process due to the requirement of posting data back to Bitcoin.
- Trust assumption of BitVM (Optimistic Rollup) BitVM’s main use case is the promise of a trustless bridge. The high level steps are that BitVM codes can be deconstructed into logic gates for fraud provers to do binary search and find the point where execution is not accurate. While anyone can provide fault proof to confiscate an operator's collateral if the operator behaves maliciously, BitVM presents an economic challenge. The operator needs to match the amount of liquidity being bridged over as collateral. For instance, if I'm bridging over 10BTC via BitVM, the operator of BitVM needs to place 10BTC as collateral for this single transaction, which can be economically difficult to scale.
- Trust assumption of Meta-protocols: Indexers
- BRC20, RUNE, PIPE, Trac, etc., all require their own indexers to translate the "state" for account-based models from or to BTC's native UTXO model. Ethereum has internalized indexing because its VM can calculate state, whereas BTC's indexer is similar to Ethereum's GETH. To understand the concept of an indexer, imagine all UTXO transactions as raw Excel data where a thousand addresses have transactions with each other. To comprehend who owns what and the final balance (account state), indexers serve a similar purpose as a Pivot Table. They compute the additions and subtractions and determine the final balance by address. Presently, indexers like BestInSlots, GeniiData, and ALEX Labs Oracle provide APIs for developers to directly pull the balance or "account state" of meta-protocols like BRC20.
- Discrete Log Contracts (DLCs): dependency on external oracles DLC in Bitcoin relies on external oracles to determine the outcome of a contract. In a DLC, the oracle's role is to sign a message indicating the event's outcome. This signature is then used by the contracting parties to construct and broadcast the transaction that settles the contract on the Bitcoin blockchain. The security and trustworthiness of a DLC heavily depend on the reliability and honesty of the oracle, as its data directly influences the contract's resolution.
- Ongoing skepticism among VCs in the Western Hemisphere:
- I've had several discussions with fellow investors about the value of BTC L2s. While we agree that most Bitcoin "L2s" are viewed as "fake" because they don't necessarily inherit BTC security and many will likely disappear in the coming months, we believe there’s still value in this vertical because
- Flawed, nascent, & inevitable: Over the past 10 years, the segment of BTC holders who want to put BTC in a hard wallet and bury it in their backyard has saturated. While the layer two solutions of BTC are sub-par compared to their Ethereum counterparts in terms of security and trustlessness, this past year has only been the inception of scaling & programmability solutions on Bitcoin. The genie is out of the bottle for Bitcoin’s metamorphosis into a more general-purpose, programmable chain, in addition to its existing identity as a store of value. This trend is evidenced by the public enthusiasm for staking, trading, and the parabolic on-chain fees on Bitcoin since 2023 (as much as $40/tx in Dec). With the advent of OP_CAT, various rollups, and side chain solutions, use cases that used to be exclusive to Ethereum and Solana are now being explored on Bitcoin.
- Enable BTC capital efficiency: BTC remains one of the most highly valued assets among institutions.There is a need for more financial instruments built on or derived from Bitcoin. However, the design constraints of the base layer make such products difficult to implement. This highlights the necessity for second-layer programmable solutions.
- This trend solves BTC’s existential crisis: More programmability generates demand for Bitcoin’s block space, which leads to more fees as net-new incentives for miners to secure the network. This is especially crucial with each halving. This was discussed more in-depth in the previous article.
- Increasingly inventive ways to utilize Bitcoin's block space
- As a method to inscribe data in both the witness block and transaction block
- As permanent on-chain data storage (which is an excellent product-market fit for luxury/collectible use cases)
Reflecting on the thesis from a year ago: how our thinking has evolved or persisted
Where we got right: The overall trend, timing, and demand relate to the issuance of digital assets on Bitcoin (Metaprotocols), programmability solutions (Layer 2s, Rollups), and efforts to increase the capital efficiency of BTC (Babylon, Lorenzo).
Where the jury is still out: The future of BTC could be either native vs. xVM. Although this is not a consensus view, we maintain that BTC should develop its own native ecosystem instead of adopting the seemingly "convenient" Ethereum Virtual Machine (EVM) approach. While we fully acknowledge the benefits of the EVM approach (such as interoperability with existing defi ecosystem, ease to onboard solidity developers, & solidity being the most battle-tested language, etc.) , it seems contradictory to have a BTC Layer 2 token in ERC-20 format, much like Arbitrum launching its token as a Solana SPL.
Where our stance has shifted: In the original article "Panda Renaissance", two paths were proposed: making BTC more "programmable" like a general-purpose L1, or making it more "capital efficient" to extend its functionality and become a more productive financial asset.
At the time, I leaned toward the latter. BTC's inherent constraints from the Script language made it unsuitable for complex programmability. However, my perspective has shifted over the past year. The market has shown a demand for Bitcoin's block space, transforming it from a dormant "digital gold" chain to a programmable, general-purpose chain. Ethereum has now effectively become a “sandbox”: the Bitcoin community is learning from Ethereum's DeFi development over the past 7 years to innovate on Bitcoin.
Chapter Two of BTC Eco: Prediction and Whitespace
Predictions
- There will be 1-2 winners per approach. This suggests that there would be 1-2 winners on EVM (Botanix), Metaprotocol (BRC20 or Rune), bridge-less base layer approach (Arch), ZK rollup, and STX (already a first mover). This totals 5-6 major players in the next cycle, each reaching a valuation of over $50B at their peak.
- Flight to safety: Currently, scaling solutions are competing for attention and access to liquidity. However, over time and especially after a security-related incident, liquidity will gravitate towards the safest L2/rollups with the least trust assumption.
- The majority of other Layer 2 solutions, sidechains, and rollups will not survive. Until that happens, it will remain a fierce competition to see who has the best airdrop program, access to high-signal investors, and connections to bitcoin whales.
- Developers will gradually awaken from the BitVM dream upon realizing it's too late, too slow, and too costly to meet builders' need for trust minimization.
- BTC DeFi will surpass ETH's: I've long maintained that Ethereum serves as BTC's testing ground. Everything since 2017 has been based on the mistaken belief that “BTC CAN'T”. However, that's no longer the case. If I'm taking risk with my token (staking, farming, leveraging), would I prefer my yield in low-value coins or BTC? I fully expect BTC's future to feature an equal, if not stronger, DeFi and infrastructure ecosystem compared to Ethereum's.
- Bitcoin's native "ERC-20" token standard will emerge: Bitcoin needs its own token standard like ERC20, which can operate across various L2s and the base layer. One way to achieve this is through a collaboration between Arch (a bridge-less base layer programmability solution) and Auran (a native Bitcoin TSS-based interoperability solution). Such a standard will be a major unlock for winners to finally emerge in stablecoin, institutional adoption, on-chain yield products, and more.
Whitespace verticals that we are excited about
- The bridge-less experience (for use cases better suited for base layer): complete trustlessness is improbable on any scaling/programmable layer - and frankly, it's not what most users care about, barring any hacks. Holding trust assumptions constant across most rollups/L2s, there will be a slew of low-velocity use cases (such as exchanges of high-value collectibles, lending, native yield, staking, etc.) where users & developers prefer to achieve the same level of programmability on the base layer (via solution like Arch Network) without needing to bridge to another L2. The tradeoff here, of course, is speed, as transactions will be constrained by BTC block time. However, not all operations need to be exceptionally fast on-chain. Bridge-less solutions will be vital in unlocking a new segment of “slow & steady” use cases on the base layer, such as stablecoin, lending, prediction market, and so on.
- Unifying infrastructure through state orchestration across various L2s (for use cases better suited on Layer 2): provide a "one-stop" developer/consumer experience to address the rampant liquidity and functional fragmentation in Bitcoin ecosystem today. Auran Network is a pioneer in this sector that we are excited about. “Formula for startup success: Find large highly fragmented industry w low NPS; vertically integrate a solution to simplify value product” - Keith Rabois, Founders Fund
- Exports of BTC Liquidity into other L1s: Numerous high-profile new/existing alt L1s are exploring ways to leverage BTC's liquidity for their ecosystem growth. Solutions like the Zeus Network, which creates a messaging layer between Solana and BTC, will likely see traction.
- Winner in stablecoin: There have been over 10 stablecoin projects. Forming deep collaborations with prevailing programmability and interoperability solutions will be the key to market dominance.
- OP CAT: OP_CAT (BIP-347) is a Bitcoin Improvement Proposal aiming to simplify and expand Bitcoin’s functionalities to enable logical loops and conditionals. It will allow the creation of rules or conditions on how Bitcoin can be spent, opening the door to many development possibilities, including Layer 2s, Smart Contracts, and more. The timeline is looking like it's 12+ months out.
- Native Ordinals trading platform: If history repeats itself as seen with SOL and ETH, the majority of the trading volume will be dominated by a native professional trading platform like Blur or Tensor. So far, most of the trading activities for Ordinal have taken place on Magic Eden and OKX. As the NFT winter recedes, we anticipate a native Ordinal trading platform, like Ordinal Hive, to flourish.
- Alternatives to BitVM to enable trustless, or at least trust minimize L2 <> base layer bridge
- On-chain BTC-on-BTC yield products for institutions: STX, given its BTC-yield bearing, and regulatory-compliant traits, could be a winner here.
- Liquid staking on bitcoin: skeuomorphic to ETH but there’s merit to LST-on-BTC projects like Lorenzo Protocol to optimize for liquidity in BTC Defi