The Landscape of Bitcoin DeFi and Metaprotocols on Layer 1

On Bitcoin, Metaprotocols are being developed to allow advanced functionality (e.g. decentralized finance and smart contracts) via base-layer Bitcoin transactions.

Originally, metaprotocols such as Ordinals, Runes, and BRC-20s emerged as a means to bring asset standards to Bitcoin for fungible and nonfungible tokens. However, these standards in their original forms do not provide the capability for more complex applications like AMMs, advanced lending protocols, programmatic stablecoins, and so on.

In this article, we’ll examine a (non-exhaustive) selection of newer L1-based metaprotocols bringing programmability such as DeFi primitives and smart contract functionality to Bitcoin.

Unlike Layer 2 solutions that require bridging assets from Bitcoin, metaprotocols operate natively on Bitcoin via base layer transactions. They avoid the complexities associated with rollups and sidechains and typically do not require bridging of BTC. This approach may result in easier onboarding of a portion of Bitcoin’s $1T+ market cap to decentralized finance applications. Looking ahead, applications on Bitcoin’s base layer can mean less fragmented liquidity — an issue we are seeing on Ethereum with its large array of Layer 2 networks.

Over the past two years, metaprotocols have demonstrated how quickly and effectively new on-chain primitives can be implemented on Bitcoin. Take the rapid introduction of BRC-20 tokens and Runes as examples — these innovations would have required significant capital and development resources to implement through more traditional Layer 2 methodologies. Metaprotocols offer more flexibility and composability, allowing for greater experimentation and innovation on Bitcoin’s base layer.

Furthermore, we believe metaprotocols can inspire base-layer Bitcoin activity that will bring more transaction fees (and potential MEV-related revenue) to miners, creating a revenue stream in addition to (diminishing) block rewards.

The primary disadvantages of these L1-based metaprotocols are Bitcoin’s 10 minute block times and potentially high transaction fees as well as blockchain congestion. We will be watching to see whether the base layer can provide an attractive enough user experience to draw usage and liquidity over Layer 2 options. We are also watching how metaprotocols ensure decentralization and censorship resistance in the cases that they use off-chain execution and state solutions such as virtual machines.

We’re observing the development and launches of these following metaprotocols with a keen interest in how Bitcoin MEV will come into play. Considering that these metaprotocols generally make use of base layer Bitcoin transactions and thus take advantage of the UTXO model, new Bitcoin-native MEV products and research will be required. Lastly, expect the information below to change (or even become outdated!) as time goes on — one of the most exciting aspects of Bitcoin’s ecosystem right now is the level of building and innovation taking place.

OP_NET is an upcoming metaprotocol that introduces smart contract capabilities to Bitcoin without changing the Bitcoin’s core consensus rules. It enables programmability needed for DeFi applications like Automated Market Makers (AMMs), lending protocols, and even stablecoins.

Interaction: OP_NET works by abstracting Bitcoin addresses into interactable smart contract addresses. Users can send transactions with call data to these addresses to interact with these smart contracts, effectively "burning" the sats (a very small amount) sent to them as these are “no-spend” addresses. Since these are base layer BTC transactions, OP_NET maintains Bitcoin's native fee structure with transaction fees paid in Bitcoin

Execution: Smart contract execution occurs on a virtual machine called OP_VM, processed by a network of external nodes. This setup allows for complex programmatic operations while maintaining the security of the underlying Bitcoin network.

Looking ahead: OP_NET has a strong ecosystem in the works, with an AMM DEX (Motoswap), decentralized lending (Stash Protocol), and more. Because they work with smart contracts, it’s fairly simple to port over existing smart contract code (e.g. from Ethereum DeFi) to work with OP_NET. We’re keeping an eye on the potential for Bitcoin MEV strategies such as arbitrage and frontrunning on OP_NET, particularly considering their impressive DeFi ecosystem buildout thus far.

Glittr is an upcoming metaprotocol that enables smart contract functionality directly on Bitcoin's base layer through OP_RETURN transactions, avoiding the need for additional layers or sidechains. OP_RETURN is an opcode in Bitcoin’s scripting language that allows for data to be embedded into a transaction on the Bitcoin blockchain.

Unlike other metaprotocols that use virtual machines or external execution environments, Glittr focuses on Bitcoin-native execution using UTXOs and does not keep a global state. In cases where intra-block state is required, e.g. AMMs, the app layer is responsible for intermediate state.

Interaction: Developers build applications using a TypeScript library that compiles down to Bitcoin Script, with transactions executing directly through Bitcoin's UTXO model. The protocol is designed to be interoperable with existing Bitcoin standards including Ordinals, Runes, and BRC-20 tokens.

Execution: Glittr transactions (utilizing OP_RETURN) are mined on Bitcoin's base layer. The protocol provides building blocks that can be combined to create smart contracts, allowing for DeFi functionality like AMMs and lending to be built using Bitcoin's native UTXO model. Rather than using a virtual machine or off-chain computation, Glittr achieves programmability by having users issue transactions that comply with contract constraints, which are then validated by the Proof of Stake network post-mining.

Looking ahead: Their focus on Bitcoin-native execution without virtual machines could offer an interesting alternative to other metaprotocols in the space. We're particularly interested in how their validator network will interact with Bitcoin's base layer and what MEV opportunities might emerge from their DeFi primitive implementations.

Arch Network brings smart contracts and complex DeFi applications to Bitcoin by utilizing the Arch VM, a parallel execution network.

Interaction: Users can use smart contracts by sending regular Bitcoin transactions. They don't need to bridge their assets to a separate network. To use an Arch-based app, users send a specially formatted Bitcoin transaction that includes information about which program to run and what it should do.

Execution: Arch uses a network of "verifiers" to process transactions. These verifiers work together to create Bitcoin addresses and sign transactions. They use a combination of signature schemes called FROST and ROAST, which allows them to operate securely even if some verifiers go offline or misbehave.

When a user sends a transaction, the verifiers run the requested program and create a new Bitcoin transaction to reflect any changes. This means all actions on Arch are recorded on the Bitcoin blockchain, but Arch can process them faster than Bitcoin's normal 10-minute block time.

Looking ahead: Arch Network is rolling out an incentivized testnet and has its first DEX, Saturn, coming soon. We’ll be watching the growth of their ecosystem and seeing how MEV strategies may emerge.

CAT (Covenant Attested Token) Protocol brings a novel approach to Bitcoin-native tokens by using covenants to enforce token rules directly through Bitcoin's consensus mechanism, rather than relying on external indexers or off-chain computation. Unlike other entries in this list, CAT Protocol requires for Bitcoin to implement the OP_CAT opcode.

Interaction: Users interact with CAT Protocol through standard Bitcoin transactions, with two token standards available: CAT-20 for fungible tokens and CAT-721 for non-fungible tokens. All token operations are validated directly by Bitcoin miners as part of normal block validation.

Execution: The protocol uses covenant-based “smart contracts” to manage token operations, including transfers and minting. This means token rules are enforced at the consensus level — invalid operations like over-minting are rejected by the network before they can be mined into a block.

Looking ahead: CAT Protocol's approach could be particularly valuable for Bitcoin DeFi due to its compatibility with Simplified Payment Verification (SPV), allowing light clients to verify tokens independently and its modular design that enables composition with other smart contracts. However, its reliance on covenant functionality means full implementation depends on Bitcoin implementing OP_CAT.

BitVM enables Turing-complete Bitcoin contracts without requiring changes to Bitcoin's consensus rules. The protocol lets users verify complex computations on Bitcoin's base layer through a challenge-response system between two parties.

Interaction: The protocol works through two participants: a prover (who makes claims about a program's results) and a verifier (who can check if those claims are true). Instead of running computations on-chain, BitVM handles comutation off-chain and only uses Bitcoin's blockchain for verification when disputes arise.

Execution: BitVM uses Bitcoin's native scripting features for its challenge-response system. Programs are turned into binary circuits and stored in Taproot addresses, with each logic gate getting its own Taproot leaf. If the prover makes a false claim about program execution, the verifier can prove the fraud through a series of challenges, causing the prover to lose their deposit.

Looking ahead: BitVM currently only works between two parties, but its approach could enable applications like DeFi primitives, validity proofs for Bitcoin contracts, and cross-chain bridges. The need for significant off-chain computation and communication between parties remains a key consideration for teams building with BitVM.

Bitcoin's DeFi landscape continues to evolve rapidly, driven by a diverse array of metaprotocols that extend its capabilities on the Bitcoin base layer.

From OP_NET's VM-based smart contracts and Glittr's Bitcoin-native execution to Arch Network's parallel processing, CAT Protocol's covenant solutions, and BitVM's challenge-response mechanism, these varied approaches to achieving programmability demonstrate the potential for a rich DeFi ecosystem to emerge directly on Bitcoin's L1, potentially offering advantages in liquidity concentration and security compared to traditional L2 solutions.

At Rebar Labs, we’ll continue to monitor how MEV strategies will emerge around these protocols as well as the opportunities for new sources of miner revenue from both increased transaction volume as well as MEV-based revenue.