Introduction

BOB is a unique Hybrid L2 that is designed to combine Bitcoin’s security with Ethereum’s programmability. Hybrid L2s inherit security from Bitcoin, as the most secure and decentralized network. Bitcoin security is then used to create trust-minimized bridges to Bitcoin, Ethereum, and other L1s. As a result, the Hybrid L2 will not rely on third-party bridges for interoperability and solves the problem of fragmented BTC multi-chain liquidity.

By fusing Bitcoin's security and capital with Ethereum's DeFi innovation and versatility, BOB will place Bitcoin at the heart of DeFi - unlocking new use cases and trillions in liquidity. This will make BOB the ideal home for Bitcoin DeFi: the best and safest place to earn yield on your Bitcoin.

In 2024, we published the Hybrid L2 whitepaper, introducing the Hybrid vision and the high-level design for the BOB hybrid L2, as well as the 3-Phase roadmap upgrading BOB from ETH L2 to Hybrid L2.

In this article, we outline how BOB will reach Phase 2: An ETH rollup with Bitcoin finality and a BitVM-powered BTC bridge. As part of this upgrade, BOB will achieve the following five new properties:

  1. State validity via ZK proofs: BOB blocks are cryptographically verified and provably correct to prevent safety failures. This makes transaction sequencing trustless, enabling sequencer decentralization, and improves finality times.
  2. Finality via Bitcoin staking: BOB has a single canonical chain across any native bridge, enforced by Bitcoin finality via BTC staking. If Finality Providers (FPs) sign competing chains, their BTC stake will be slashed.
  3. Native Bitcoin bridge via BitVM: BOB will have a native Bitcoin bridge based on the co-authored BitVM2 design.
  4. Fast withdrawals: Utilizing validity proofs and FPs, withdrawals from BOB to Bitcoin and Ethereum will take a few hours at most.
  5. Hybrid data availability: BOB users can include transactions on BOB by sending a transaction on Bitcoin mainnet. This enables withdrawals back to Bitcoin without the sequencer being able to censor the transactions.

‍

Phase 2 Building Blocks

In Phase 1, BOB launched its mainnet as an OP Stack rollup on Ethereum, supporting BTC assets from Ethereum (wBTC, SolvBTC, LBTC, tBTC, …). BOB will continue to use Ethereum EIP-4844 blobs as DA and support bridging to Ethereum via the OP standard bridge contracts.

In Phase 2, BOB introduces three building blocks to add state validity (“ZK rollup”), Bitcoin finality, and a native BTC bridge.

  1. Validity Proofs: Using SNARKs over BOB state proposals, any third-party, light client, or external chain can cryptographically verify that BOB state proposals are correctly created. Validity proofs are posted to and verified on Ethereum. This ensures the BOB sequencer cannot produce invalid blocks and makes BOB a validity rollup (sometimes referred to as “ZK rollup”). Validity proofs also form the basis for the native bridges to both Bitcoin (via BitVM) and Ethereum.
  2. BTC-Staked Finality Providers (FPs): BOB introduces BTC-staked FPs, powered by Babylon. FPs stake BTC on Bitcoin and sign off on BOB state proposals. If FPs sign more than one version of the BOB chain, their BTC is slashed on Bitcoin (private keys are leaked, read more here). Slashing for equivocation introduces a high economic cost for attempting to fork the BOB chain, offering stronger finality guarantees. This property plays a critical role in the hybrid L2 design as it ensures consistent operation of the native BTC and ETH bridges. While a corrupted sequencer cannot create invalid BOB blocks (due to validity proofs), they could create two valid but conflicting versions of the BOB chain (e.g. containing a double spend) and attempt to create inconsistency across the BTC and ETH bridges. BTC-staked finality prevents this by enforcing a single canonical version of BOB, verified on both Bitcoin and Ethereum.
  3. BitVM: BitVM is a mechanism to execute arbitrary programs on Bitcoin in an optimistic manner: the execution happens off-chain but in case of failures, disputes are resolved and enforced on-chain. We use BitVM to create a trust-minimized bridge between Bitcoin and BOB. Specifically, we create a bi-directional light client bridge: BOB can already verify deposits on Bitcoin, BitVM enables us to verify withdrawals on BOB and ensure correct processing on the Bitcoin mainchain. Thereby, we verify the SNARK proof over the BOB state as well as BTC finality using BitVM’s fraud-proof mechanism.

‍

The BOB Hybrid L2 Design

We now use the three building blocks to create the first-ever Hybrid L2:

  1. Rollup Validity and Bitcoin Finality: Combining Validity Proofs and BTC-Staked FPs, the BOB Hybrid L2 enables safety of transactions and fast-finality secured by BTC. FPs commit to the BOB state being valid by presenting a validity proof and providing signatures over BOB state proposals, weighted by their BTC stake.
  2. Native Bitcoin Bridge: Leveraging the Validity Proofs, BTC-Staked FPs, and BitVM, BOB adds a native Bitcoin bridge. In BitVM, operators claim BTC from BitVM instances through a complex combination of various proofs of the bridge operation and finalization of the BOB state.
  3. Native Ethereum Bridge and Settlement: Integrating the Validity Proofs and BTC-Staked FPs, the native Ethereum proposers claim BOB is valid and finalized by FPs to complete withdrawals from users to Ethereum.

Rollup Validity and Bitcoin Finality

The BOB sequencer produces blocks every 2 seconds. After a certain number of BOB blocks have been created, BOB’s state is finalized - similar to a checkpoint. For this, the BOB sequencer generates a SNARK validity proof of BOB, including all blocks produced since the last checkpoint/proof. This proof cryptographically verifies that all processed transactions are valid.

The sequencer submits the state proposal hash, signature and validity proof to the BTC-staked FPs. FPs must have staked BTC on Bitcoin to qualify as BOB FPs and receive part of the sequencer fees in return as staking rewards. We consider a BOB state proposal final once it has been signed off by at least ⅔ of the BTC stake. Further, the signed commitment to the BOB state is regularly checkpointed to Bitcoin. After 100 Bitcoin blocks, the checkpoint is considered finalized.

This combination of validity proof and Bitcoin finality is then used to verify and correctly execute deposits and withdrawals for the native Bitcoin and Ethereum bridges.

‍

Native Bitcoin Bridge

In BitVM, so-called operators facilitate users bridging BTC in and out of BOB. Operators and users create a BitVM instance for every deposit where the user locks an amount of BTC, and receives bobBTC on BOB. When a user initiates a withdrawal, an operator will first send them BTC from their own wallet (fronting the BTC) and then reclaim the BTC from the BitVM deposit. The operator can only claim the BTC from BitVM if they can prove that (1) they’ve provided BTC out-of-pocket to a withdrawing user and (2) the corresponding withdrawal request (that burns bobBTC) was finalized. This process is optimistic: the operator initiates the BTC claiming process (in the form of a SNARK), stating that he/she correctly processed the withdrawal request, and can be challenged by any observing user during a pre-defined time window (“challenge period”).

If challenged, the operator and challenger verify a small part of the SNARK verifier program on Bitcoin in Bitcoin script. If the challenger successfully proves that the operator is cheating, the BTC remains in the BitVM instance, and the operator is slashed and removed from the bridge. If the operator was honest, they receive the BTC from the BitVM instance, and the challenger is slashed.

‍

‍

For BOB specifically, the operator makes the following claim for a BitVM instance: They combine the withdrawal Bitcoin transaction (= the PegOut transaction) with proof that the bridged BTC on BOB was burned on a finalized block, i.e., a BOB block that is part of a finalized state proposal. They also prove that the PegOut transaction and the BOB checkpoint reference (as part of checkpointing the BOB state signed by BTC stakers to Bitcoin) on Bitcoin are on the same chain.

For a more in-depth primer on BitVM, differences between possible design approaches and latest progress updates, see our BitVM status report.

‍

Native Ethereum Bridge and Settlement

There are two popular rollup types on Ethereum: Optimistic and validity rollups. In optimistic rollups, regular state proposals can be challenged during a predefined time window. If a state proposal is not successfully challenged, it is considered finalized. In validity rollups, a state proposal is accompanied by a ZK proof guaranteeing the validity of the state. The proof is verified on Ethereum and if valid, the state is immediately finalized.

As part of Phase 2, BOB will become a validity rollup. This ensures that the same finalized state used for BitVM is also used for Ethereum. The validity proof for BOB is different from other validity rollups. It combines two proofs: (1) the validity of the BOB block preventing safety failures and (2) a proof that FPs attested to BOB’s canonical chain. The proof over the FPs include the presence ⅔ or more of BTC-staked FPs, a checkpoint of the FP signatures on Bitcoin, and that the checkpoint has at least 100 confirmations on Bitcoin.

We can frequently finalize BOB’s state on Ethereum by submitting this combined validity proof. This, in turn, reduces the withdrawal time to Ethereum from the current 7-day standard of an optimistic rollup to merely a few hours - as per standard for validity rollups.

‍

Hybrid Data Availability

By design, users can include a transaction on BOB by submitting a transaction on Ethereum, protecting them against sequencer censorship. Combined with validity proofs and settlements on Ethereum being open to anyone, users can force withdrawal of their assets back to Ethereum in emergency situations.

Recently BOB introduced the novel concept of Hybrid Data Availability, where Bitcoin is added to the derivation pipeline of an ETH rollup. Similar to how users can send arbitrary transactions alongside a deposit in the OptimismPortal contract on Ethereum, we allow users to send arbitrary transactions to BOB on Bitcoin. The primary use case for this is to include withdrawal transactions on BOB to Bitcoin if the sequencer should be offline or censoring users on the L2.

In the full post, we outline how adding Bitcoin to the derivation pipeline achieves Bitcoin censorship resistance for L2 transactions.

‍

Outlook on Phase 3: Full Bitcoin Security

If Bitcoin adds functionality to verify validity proofs natively in Bitcoin script, BOB can settle directly on Bitcoin with full Bitcoin security. This represents the ideal state of Phase 3: full Bitcoin security that is provable via a Bitcoin light client to any other chain. It means BOB settles on Bitcoin and finalization (of bridges) on other chains is done by verifying Bitcoin. It’s a reasonable trust assumption: if Bitcoin fails, likely every other chain will fail as well.

In the absence of a Bitcoin fork enabling on-chain ZK-verifiers, BOB will have to leverage optimistic verification via BitVM. Achieving optimistic rollups on Bitcoin without additional trust assumptions requires using the Bitcoin mainchain as a data availability layer. As of today, Bitcoin DA costs are onerous (see Galaxy report) and pose a challenge in terms of economics.

As a result, to complete the transition to Phase 3, BOB must reach sufficient scale in terms of active users such that incurring additional data availability fees does not increase transaction fees beyond that of competing Ethereum L2s. Alternative data availability layers can be considered as a trade-off between cost and security, as they introduce additional trust assumptions beyond that of Bitcoin.

It is important to highlight that using an alternative DA layer with BitVM verification for rollup finality does not add benefits over the Phase 2 design: the security (usually PoS) of the DA layer must be trusted. Furthermore, such a construction requires verifying a light client proof for the (alternative PoS) consensus of the DA on in BitVM which is an open research question.

As a result, BOB’s Phase 2 is the most secure, practically feasible solution for BTC DeFi today, especially due to the fact that BTC stake is slashed in case of equivocation.

‍

Conclusion

We presented the technical blueprint for upgrading BOB to the first-ever Hybrid L2: an Ethereum rollup with Bitcoin finality and native, trust-minimized bridges for both BTC and ETH assets.

We will begin rolling out the Hybrid L2 on testnet over the next few weeks and complete the upgrade to mainnet after successful audits. In parallel, we are completing a full technical specification including security proofs that will be released shortly. BOB’s BitVM bridge is already launched on testnet, with operator onboarding commencing soon.

‍