The first phase of testing of BOB’s BitVM Bridge on testnet is coming to an end. The second phase will include the implementation of fraud proofs for bridge security and Transfer of Ownership Protocol (TOOP) to reduce the need for operators to front capital. The second testnet phase is planned to commence in Q4. BOB will also open source the BitVM Bridge code repo at this time.
A Big Thank You to Our Institutional Partners
Before we dive into the key lessons learned during the first phase, we’d like to say thank you to our testnet partners for helping us turn our BitVM research into reality.
Ten BitVM operators provided important feedback for the future development of BOB's BitVM bridge during the last six weeks: Amber Group, Ankr, Fiamma, Lombard, Luganodes, P2P.org, RockawayX, SatLayer, Solv Protocol and UTXO Management.
.webp)
Improving capital efficiency of the bridge with TOOP
Although partners appreciated the architectural split between operator nodes (managing peg-ins and peg-outs) and LP nodes (fronting BTC for peg-outs), the need to front capital remains sup-optimal. This is because:
- LPs need to maintain idle BTC reserves for potential peg-outs: When no withdrawals are happening, funds simply sit unused - creating opportunity costs for capital providers.
- The design introducing a potential bottleneck risk: If LPs lack available BTC when users need to withdraw, their BTC on BOB could become stuck.
Following this partner feedback, we are eliminating the LP role entirely from the BOB BitVM Bridge design by implementing TOOP or Transfer of Ownership Protocol. TOOP retains BitVM's 1 of n honesty assumption while eliminating the need to front capital by enabling users to withdraw BTC directly from BitVM instances.
In traditional BitVM2&3, the BitVM instances specify during setup which parties can receive the BTC - these recipients are the operators. Operators can only withdraw from a BitVM instance after sending users an equivalent amount of BTC (minus fees) from their own wallets. TOOP removes this requirement entirely.
Instead, the next phase of the partner testnet will introduce keyshare holders who form an n of n multisig that can receive the BTC from the BitVM instance. When users withdraw, keyshare holders send their private keys to the user, who then combines them to withdraw directly from the BitVM instance. The result is the security model remains intact - if even one keyshare holder refuses to share their key (suspecting malicious activity), the withdrawal stops, preserving the 1 of n assumption that makes BitVM secure.
NB. Keyshare holders are called "committee" in the paper, but have been renamed to avoid confusion with BitVM's existing covenant committee.
Fraud proofs
Beyond the implementation of TOOP, the next partner testnet release will feature new institutional partners as operators, as well as the implementation of the BitVM fraud proof process. This is the optimistic process which keeps BitVM secure, meaning anyone can challenge an operator's request to withdraw BTC from a BitVM instance.
As part of this new phase, BOB will also open-source the BitVM Bridge repo, allowing teams and institutions to evaluate the code ahead of potential integrations. This will be possible when the audit of the BitVM2 repository has been completed.
Native BTC on BOB
The successful completion of this first testnet phase marks a significant milestone in BOB's journey to deliver Native BTC on BOB, powered by BitVM. With TOOP eliminating capital inefficiencies and the fraud proof system ensuring security, we're building the trust-minimized bridge that Bitcoin DeFi needs.
We look forward to announcing more partners and builders as we move toward mainnet. If you are interested in working with BOB and supporting the development of BitVM, please apply to join bitvm/acc.
bitvm/acc
For those who want to dive deeper into the BitVM ecosystem, why not check out the recordings from our recent bitvm/acc event in Cannes - featuring discussions and presentations from across the BitVM community:
