A prototype BitVM bridge between BOB and Bitcoin has been successfully tested, marking a major milestone in our Hybrid L2 mission to combine the best of Bitcoin and Ethereum.
The prototype leverages the latest version of BitVM2 to facilitate a trust-minimized Bitcoin bridge. It was developed in close partnership with Fiamma—a leading BitVM developer and zero-knowledge infrastructure company.
This follows hot on the heels of the announcement of our upcoming integration with Babylon, which will bring Bitcoin finality to the BOB Network via Babylon’s Bitcoin staking protocol. Together, these two developments allow BOB to start moving into Phase 2 of the Hybrid L2 roadmap.
BOB will be the first Layer-2 solution to both inherit Bitcoin’s security and develop a prototype BitVM-based bridge.
Read on to learn more.
What is BitVM?
BitVM is a mechanism to execute programs on Bitcoin in an optimistic manner. The execution happens off-chain but in case of failures, disputes are resolved and enforced on-chain. Think Optimism, but on Bitcoin. The two main use cases are Bitcoin rollups and trust-minimized bridges. In both, we want to allow users to deposit and withdraw BTC from an L2 without trusting a 3rd party.
Existing bridges typically rely on centralized entities—such as Wrapped Bitcoin (wBTC) and Coinbase Wrapped Bitcoin (cbBTC)—or semi-trusted networks like tBTC, where security depends on the honesty of the majority of participants. In contrast, BitVM2 bridges introduce a superior security model: BTC deposits cannot be stolen as long as there is a single honest and online node in the network, and this node can be the depositor themself.
The latest and practical version is BitVM2. Please refer to our latest paper for a full protocol specification.
BOB’s Co-Founder, Alexei Zamyatin, an active contributor and co-author of the BitVM2 technical design, emphasized the importance of today’s achievement:
“Bitcoin security and trust-minimized BTC bridging is what sets Bitcoin L2s apart from all other chains. Security from the most robust and decentralised network, paired with a way to deposit and withdraw BTC without trusting any third party. So far, this has not been possible, almost all BTC bridges are trusted multisigs. Only now, for the first time in Bitcoin’s history, do we finally have a blueprint and a prototype for achieving this in practice with BitVM2.”
BitVM2 Protocol Flow
- Compress a program into a SNARK verifier, implemented in Bitcoin Script. Using the Groth16 proof system we get approximately 1GB in size.
- Split the verifier into sub-program chunks, max 4MB each, so each can be run in a Bitcoin transaction.
- The operator commits to the program during setup.
- When attempting to withdraw funds from BitVM2, the Operator can be challenged by anyone, for example, if the unwrapping (peg-out) was not completed correctly.
- If challenged, the Operator must reveal all intermediary program results.
- If the Operator cheats, one of the claimed sub-program results will be wrong. Anyone can disprove the Operator by executing that specific sub-program in a Bitcoin transaction, showing that the Operator claimed a fake computation.
- Done! The faulty Operator is kicked out and cannot access the BitVM funds due to an invalidated spend transaction.
BitVM Bridge Flow
The BitVM Bridge makes use of BitVM2 to implement a light-client bridge on Bitcoin. The L2 verifies Bitcoin, Bitcoin verifies the L2. The most interesting part is the un-wrapping, also called the peg-out, which has long been a challenge for Bitcoin DeFi protocols.
- Operators pay BTC to the withdrawing user from their own funds and then reclaim the BTC from BitVM.
- BitVM checks that for a un-wrap transaction on the L2, there is a correct peg-out on Bitcoin.
- If all is correct, the Operator gets the BTC refunded.
Under correct operation, the bridging process completes in less than one hour each way, which is much faster than existing Ethereum L1 or L2 bridges to Bitcoin.
A Strategic Partnership with Fiamma
To accelerate its implementation of BitVM2, BOB teamed up with Fiamma, the pioneer behind the first products utilizing BitVM2, including the first BitVM bridge (Fiamma Bridge) and the first BitVM-powered verification layer on Bitcoin (Fiamma Layer).
This partnership was instrumental in the success of BOB’s BitVM bridge prototype. Together, BOB and Fiamma deployed key bridge infrastructure and trialled an early version of the prover software to verify BOB’s consensus. This follows BOB’s strategic investment in Fiamma earlier this month, with their infrastructure and expertise able to support the rapid deployment of BitVM on BOB; starting with this BitVM bridge prototype.
Speaking on today’s milestone, Cyimon Chen, Fiamma Co-founder and core BitVM contributor said:
“We’re excited to announce our partnership with the BOB team! We deeply appreciate Alexei and his team’s valuable insights during our discussions. We look forward to integrating the BitVM Bridge into BOB, making it the first Bitcoin Layer 2 with a trust-minimized bridge. We hope BOB’s BitVM bridge prototype is the first of many impressive announcements that result from our strategic partnership.”
Advancing BOB’s Hybrid L2 Roadmap
Earlier this week, BOB announced its planned integration with Babylon, the leading BTC staking protocol, which will establish BOB as a Bitcoin-secured network and provide Bitcoin finality to its blockchain.
Trust-minimized bridging and Bitcoin finality are essential components of BOB’s hybrid design, which aims to combine Bitcoin's security and liquidity with Ethereum's DeFi innovation and versatility, establishing BOB as the home for BTC DeFi.
This combination will enable:
- Enhanced security: Transactions on BOB will be anchored to Bitcoin’s security.
- Seamless BTC transfers: Users will be able to move BTC between Bitcoin and BOB without needing to trust intermediaries.
- Faster withdrawals: Bitcoin finality will accelerate withdrawal times on BOB’s native Ethereum bridge.
To learn more about what this means, please read BOB’s Hybrid L2 Vision Paper.
What’s Next?
Following this prototype's delivery, BOB plans to roll out the BitVM bridge on the BOB testnet in early 2025, with the mainnet deployment to follow after successful audit and partner integration.
Once BOB has completed its integration with Babylon and is a Bitcoin Secured Network (BSN), the primary security mechanism for the BitVM bridge will be Bitcoin finality through BTC staking. We are actively working with Babylon to implement this.
In the meantime, keep an eye out on our socials to be informed on the launch of the BitVM bridge, and all the other exciting developments we have planned.
For developers and anyone who loves to get deep into the technology, the next sections explain more of the specific developments underpinning the bridge prototype. There are also links to the prototype test transactions.
BitVM Bridge Technical Details
Specialized zkVM-based Prover
Integrating with Fiamma’s core infrastructure, we developed an early prototype of our zkVM-based prover to validate block construction on BOB. In this early version, we gave as input to our SNARK prover:
- Ethereum L1 transactions submitting new output roots to the L2OutputOracle contract.
- The L2 block headers up until this “checkpoint” for a target block.
- Execution receipts for the target L2 block.
Here we made sure that the approved proposer signed off correctly, and that the output root matched the latest L2 block. We also verified that all the blocks leading up to our target block were in the correct order. Then, within the target block’s transaction records, we confirmed there was a specific “burn event” that uniquely identified the BitVM instance created during the initial setup.
Bridge Contract and Bitcoin SPV Full Relay
Most of our smart contract logic is defined in a new "Bridge" contract, which makes it possible to mint ERC20 tokens on BOB, and allows operators to process peg-out requests.
Internally, there is also a Bitcoin SPV “full relay”, which we check to make sure the Bitcoin transactions are included.
Peg-In and Peg-Out Processes
Assuming a user, Alice, wants to bridge BTC into BOB and then withdraw, the step-by-step BitVM bridge protocol is executed as follows. Note: “peg-in” and “peg-out” refer to bridging in and out, as per the definitions used in the code and BitVM paper.
Peg-In:
- Alice coordinates with the committee* to set up a new BitVM instance and gets a unique ID (off-chain).
- Alice sends BTC to the designated Bitcoin address, referencing the ID.
- The committee submits the Bitcoin tx and inclusion proof to the bridge smart contract on BOB, which verifies (using the SPV relay) that the deposit transaction was included in the Bitcoin main chain with at least 6 confirmations.
- If everything checks out, the smart contract mints a wrapped BTC ERC20 token to Alice at a 1:1 ratio to the BTC deposit. Alice can then use this in any of BOB’s DeFi protocols, just like any other ERC20 token.
* The so-called “covenant emulation” committee is used to simulate missing covenant op-codes on Bitcoin. This committee is needed to pre-sign specific Bitcoin transactions that ensure the operator can only spend BTC deposits in a way that can be challenged, thus preventing theft. Specifically, this is a m-of-m committee, where m can be very large (100s of randomly sampled signers). As long as one of these signers is honest, the setup is secure. Alice herself can participate in this setup. This committee can eventually be replaced if Bitcoin adds a new opcode like TXHASH or OP_CAT.
Peg-Out:
- Alice locks the wrapped BTC ERC20 in the bridge smart contract on BOB and waits for an operator to accept the request.
- One of the operators then sends the corresponding BTC amount to Alice’s address on Bitcoin, and provides an inclusion proof to the bridge smart contract on BOB after there have been at least 6 confirmations. The smart contract emits a “burn” event.
Note: the peg-out is completed to Alice at this point. The operator is “fronting” the BTC from their own balance. In the steps below, the operator reclaims this amount from the BitVM deposits to complete the process. This logic can be compared to that of a liquidity bridge on Ethereum.
- The BOB sequencer produces a block that contains the “burn” event, which is then used as input for the ZK prover described above.
- The operator initiates a withdrawal from the BitVM deposits on Bitcoin. Now, within 7 days, anyone can verify the correctness of the peg-out and, in case of errors, challenge the operator.
- Option 1: Everything is correct. If the operator executed the peg-out correctly (correct amount, recipient, within the required time, …), they will not be challenged and claim the BTC from the BitVM deposits after 7 days.
- Option 2: Error and challenge. If the operator tried to cheat (e.g., did not send BTC to Alice but is trying to reclaim anyway), they will be challenged - as long as there is at least 1 honest and online user in the network. The operator is then forced to publish additional data about the execution of the SNARK verifier (“Assert” transaction), which allows the challengers to prove to the Bitcoin network that the operator is cheating (with 1 more transaction). If the operator does not post the Asset transaction or has indeed cheated (meaning, the SNARK verifier cannot have correctly executed), their withdrawal attempt will fail and they will be removed from the operator set.
Note that in the case of peg-out, we have flexibility to subtract fees in the smart contract so the operator can recoup more when reclaiming from the BitVM instance.
BitVM Bridge Prototype in Action
To demonstrate the prototype bridge in action, let’s take a look at some example transactions on Bitcoin signet.
Firstly, the peg-in transaction where the user locks their BTC:
Happy Path
In the optimal case (where the operator is honest), they front the BTC to the user in pegout_tx and then reclaim the funds (unchallenged) in happy_take_tx:
- pegout_tx: https://mempool.space/signet/tx/c3b7b647a09bacb02a1ba16e014b296f069883e18fa6ba6fe5ea6561639f9b54
- kick_off_tx: https://mempool.space/signet/tx/37d9cab98db5573c055e13ac280c0b7630c39d7e089ff4e96696c40c46c5a6f0
- happy_take_tx: https://mempool.space/signet/tx/f724e65d3bd9a414c8703453a94a9420c0a8f3a9349fe4ce7e51598c3381e5b8
Unhappy Path (with Successful Challenge)
When an operator tries to reclaim the BTC without a successful ZK proof a challenger can provide a disprove_tx which proves to BitVM that the assert_tx was invalid:
- pegout_tx: https://mempool.space/signet/tx/c14d8afa983d25a20d9576c139b867ec5eb75bfdeb22fcb0e2b278d8f2fc1b41
- kick_off_tx: https://mempool.space/signet/tx/9d023f3fc45b60ec3a5fa96cf7bf0c456f4d949bae4600efe2f45880579f65da
- challenge_tx: https://mempool.space/signet/tx/9420c8076c0bf642be39dc88ca632a90594c8303e9447085bdf3eb312d50352e
- assert_tx: https://mempool.space/signet/tx/dcb324e02f617fe511dec49b0cebce34fc9da31522e183791f7405d4bc265767
- disprove_tx: https://mempool.space/signet/tx/014f501fca5545ac8a17d8e5f9af3817b814a27aa2ef4ea10a76a4363a685d07
Unhappy Path (with Unsuccessful Challenge)
If an operator is challenged on a valid peg-out they provide an assert_tx which cannot be disproven. They then reclaim the funds in unhappy_take_tx:
- pegout_tx: https://mempool.space/signet/tx/d9d00da9633febfd7ab551267782a747eaef0547faf437e3e06ecf57012ca6e6
- kick_off_tx: https://mempool.space/signet/tx/63d86bc55ee8005d698bb8a9b77cac177e947d9a6ad23b23371216df7def7984
- challenge_tx: https://mempool.space/signet/tx/47e90712093d7e5360fb8cf877ee190a6d4a4406597dda497aac5d799a42fdb2
- assert_tx: https://mempool.space/signet/tx/75786e0ea56e942439eedcc140acafb1682b32bb958062b780ef851039da586b
- unhappy_take_tx: https://mempool.space/signet/tx/8a6d87b634713f2038f0cf795f4bd4574af052ebecd6d01e8cfc2d8532369404
Next Development Steps
The current prototype still has a few limitations, being under development. Next steps leading up to a pre-launch testnet release:
- Add Bitcoin finality checks via Babylon, including a ZK light client to correctly verify this on Bitcoin.
- Integrate with BOB Bridge and Stake to improve UX, hiding complexity from users.
- There are some practical limitations of posting some commitments on-chain due to size constraints (i.e., currently the assert tx lacks data commitments). We are looking into this with Fiamma.
- Fine tuning economics to ensure operators are paid fairly and are incentivised to operate the BitVM bridge.