Sign in Subscribe

The Bitcoin L1 Thesis: A Middle Way to Unlock DeFi

Arch Network

• 6 min read
The Bitcoin L1 Thesis: A Middle Way to Unlock DeFi

By Nick Fouriezos, CMO at Arch

What if the world’s most secure store of value could also be its most powerful programmable asset?

That is the core thesis of Bitcoin builders, who hope to unlock $2T+ in BTC left under-utilized by Bitcoin’s lack of native programmability. 

The chance to tap that treasure trove of digital gold drove half a billion dollars in venture investment to Bitcoin L2s — a third of which was allocated just last year amid technical breakthroughs that made Bitcoin programmability seem closer than ever.

While promising, these investments have been mostly built on an assumption that developers only have two choices to unlock Bitcoin DeFi.

The Bitcoin innovator’s dilemma

  1. Build secure, but slow, base-layer dApps, sacrificing speed and UX while offering no native interoperability to pool liquidity from other Bitcoin apps, significantly limiting their DeFi use cases.
  2. Build fast, user-friendly, L2 apps that require bridging, introducing security risks, removing the ability to use native BTC assets, and fracturing the very liquidity that makes Bitcoin so appealing in the first place. 

The problem? Neither of these options are truly capable of unlocking the Bitcoin economy.

In this piece, I will explore the tradeoffs that underpin the Bitcoin innovator’s dilemma, and the mistaken assumptions that Bitcoin L2s and metaprotocols make in trying to solve it. 

Then, I will detail “The Bitcoin L1 Thesis,” a  middle way that Arch is using to fully realize Bitcoin’s potential as a programmable and productive asset. 

Roadmap: (<10 minute total reading time)

  • Metaprotocols: The Isolation Challenge
  • L2s: A Bridge Too Far
  • The Bitcoin L1 Thesis: A Middle Way
  • How it Works
  • The Trade-offs of Arch’s Approach
  • How to Get Involved

Metaprotocols: Isolated and Limited

Base-layer apps, or “metaprotocols,” have the benefit of inheriting Bitcoin’s security, forcing users to take no greater trust assumptions than Bitcoin itself. They make it possible to do more with UTXO-based assets, including native Bitcoin, Runes, BRC-20s and Ordinals.

However, these metaprotocols are severely constrained by Bitcoin’s inherent limitations, making them fundamentally unsuitable for true DeFi. These apps have failed to gather significant users or liquidity in the last year, lacking the speed or programmability to enable true composability between Bitcoin apps. 

This is in stark contrast to more programmable L1s like Solana, where apps can use “cross-program invocation” and other native features to automatically call and execute code from other apps. 

Such flexibility is essential to fueling complex DeFi functions and pooling liquidity from multiple sources. 

L2s: A Bridge Too Far

Since base-layer apps are incapable of empowering true DeFi, most Bitcoin programmability investment has flowed to those building L2s.

L2s generally fall into three camps, with various trade-offs

  1. Performance-focused L2s: Multisigs with few or no decentralized signers/validators.
  • Pros: Faster speeds and greater programmability options
  • Cons: Sacrifice decentralization, native BTC liquidity, and interoperability
  • Bet: They can convince Bitcoiners to trade decentralization for greater programmability and performance.
  1. Deployment-focused L2s: EVM-compatible L2s that stress ease for Solidity developers
  • Pros: Easier to bootstrap and integrate apps, greater programmability options
  • Cons: Lack of liquidity, BTC alignment, and native UTXO compatibility
  • Bet: They can convince Bitcoiners to take bridge risk and use synthetic BTC assets for greater programmability and performance.
  1. Security-focused L2s: L2s that optimize BTC alignment and bridge-security
  • Pros: Greater BTC alignment, security, and (potentially) greater performance
  • Cons: Still requires bridging, no native liquidity, inefficient use of liquidity
  • Bet: They can convince Bitcoiners to take bridge risk while also attracting liquidity providers and bridge operators to process deposits and withdrawals.

In all three cases, these L2s are sacrificing Bitcoin’s native liquidity, and compatibility with native UTXO-based assets like native Bitcoin or Runes/Ordinals. 

Their hope is that they can later pull in the liquidity needed to fuel DeFi in their ecosystems.

That bet hasn’t been proven out. To date, there is less than $2 billion in DeFi TVL on Bitcoin “sidechains,” with none holding larger than $500 million, according to DeFi Llama.

The Bitcoin L1 Thesis: A Middle Way

Earlier this year, Jon Charbonneau, co-founder of the crypto investment firm DBA, wrote a piece titled “The Bitcoin L2 Thesis.” 

The piece provides an excellent breakdown of how most people “over-index on Ethereum L2s in trying to understand Bitcoin L2s.” He writes:

Unfortunately, reasoning by analogy leads to the wrong conclusions, including:

  1. Underestimating the market size – Bitcoin’s lack of programmability on L1 means that BTC L2s have a fundamentally larger market opportunity vs. ETH L2s.
  2. Missing what will determine the “winner” – Security will matter more and earlier on for BTC L2s compared to ETH L2s.
  3. Underestimating what’s possible to build – Recent breakthroughs have unlocked the ability to build Bitcoin ZK-rollups with optimistic-ZK bridges (carrying a 1 of n trust assumption), and they’re coming sooner than you think. Potential future Bitcoin upgrades could make them fully trustless (i.e., enabling direct ZK verification and removing the 1 of n).

Charbonneau makes some powerful insights. It’s hard to argue with the fact that the market size for Bitcoin L2s that can offer programmability is fundamentally larger than ETH L2s. 

He’s also right that security is paramount for Bitcoiners, a value we’ve also bet big on from day one — if it weren’t a factor, then significantly more Bitcoin liquidity would have simply moved to ETH or other chains for DeFi long ago. 

Charbonneau argues then that security-focused L2s are the only real option for adding programmability (accordingly, he makes the case for ZK-based ones to “win” that Bitcoin L2 race, given their high security). 

“Altogether, Bitcoin’s leading L2 will need to be as close as possible to Bitcoin itself,” Charbonneau writes. 

If it were true that a bridge-based L2 is the closest you can get to native Bitcoin programmability, this wouldn't be a bad assumption — an assumption rooted in the Bitcoin innovator’s dilemma. 

But Charbonneau ironically falls victim to the same limited vision he critiques in others, even as he warns against 'underestimating what's possible to build.'"

After all, a programmability solution that could …

  1. Work with native Bitcoin assets on the base layer,
  2. Without requiring users to bridge, while
  3. Still maintaining decentralized security

… would be more preferable, and even closer to Bitcoin, than any Bitcoin L2.

It would allow users to access DeFi with pristine Bitcoin, not some derivative product that required bridging or wrapping into another chain to access.

It would more directly tap into Bitcoin liquidity, and enable greater composability between all Bitcoin apps that access smart contracts through it. 

That is the “Bitcoin L1 Thesis” — the middle way that Arch enables. 

How it Works

Arch’s architecture is tailored to support a more performant and native programmability experience on Bitcoin. 

It includes three major components:

  1. A custom Rust-based VM similar to the SVM
  2. A cryptographic multisig using FROST + ROAST signature schemes
  3. A decentralized Proof-of-Stake validator set

The Arch VM uses a hybrid UTXO-account-based model to allow for Solana-like speeds and the more complex logic necessary to create smart contracts. However, unlike the SVM, it also has the added feature of being able to interact with the Bitcoin base layer, and manipulate UTXO assets on it. 

The funds from the Bitcoin blockchain are deposited into Bitcoin addresses that represent Arch accounts owned by the Arch multisig, essentially a smart contract-controlled wallet. These assets can only be transferred with consensus from the decentralized validator set, which are secured by a cutting edge FROST + ROAST threshold signature scheme.

The result of Arch’s “middle way” is … 

  1. A more native experience. Actual Bitcoin assets can be moved, as opposed to L2s, which typically have to lock up Bitcoin funds or burn them, then mint a virtual representation of that asset.
  2. A faster experience. Transactions can be done quickly in Arch apps, then posted to Bitcoin. Any potential state concurrency issues are solved by using real-time mempool indexing to synchronize with Bitcoin state, then initiating a rollback mechanism if Arch transactions fail to confirm on Bitcoin.
  3. A more composable experience. Features like cross-program invocation enable greater interoperability between Bitcoin apps that use Arch, creating the foundation for a more liquid Bitcoin-native economy. 

If you’re interested in learning more about the technical components, you can read this in-depth breakdown by Arch CTO Amine El Qaraoui. 

The Trade-offs of Arch’s Approach

We defined a lot of technical terms in this piece. The simplest way to describe Arch’s design choice? 

We identified what Bitcoin was missing, and we built it.

That decision certainly comes with trade-offs, when compared to Bitcoin L2s.

While L2s can create simple forks of the EVM or SVM, Arch had to create a custom VM that could manage UTXOs and maintain Bitcoin state, while also working with Bitcoin’s inherent limitations. 

We knew it would be harder for developers to deploy their apps on us — while Solidity developers could simply copy-paste their apps to EVM-compatible L2s, our core programming language is native Rust. 

Plus, building this way meant we would have to craft many developer tools, guides, and supports from scratch.

For Arch, the trade-offs were worth it to offer users the ability to make their native Bitcoin more programmable and more productive on the base layer.

Our bet is that users will prioritize a solution that allows them to do and earn more with their pristine Bitcoin, without compromising on high performance, native liquidity, or decentralized security. 

How you can get involved: