Welcome to another installment of our 101 education series, where we break down the key building blocks of BOB as simply and clearly as possible.
Today we’ll be delving into BitVM—a new way to run programs on Bitcoin without changing any of the core consensus rules that have made it the biggest, most secure and most well known blockchain. By the end of this article, you’ll see how BitVM plays a vital role in BOB’s Hybrid Layer 2, supporting secure, trust-minimized Bitcoin DeFi for everyone.
BitVM makes Bitcoin smarter
By now, you may know that Bitcoin is incredibly secure, but not very flexible. It processes transactions, but can’t handle the more advanced requirements of DeFi apps on chains like Ethereum and Solana.
This is because Bitcoin Script lacks built in shortcuts or tools so even simple programs quickly become very large and prohibitively expensive to run. For example, something as simple as multiplication can only be processed as repeated addition. Instead of a single 10 x a = 10a calculation, it is necessary to program multiple sequential addition calculations to get the same result. Even though some optimizations are possible, you can see how this could get complicated very quickly.
In order to make the most of their assets and access DeFi yield, some Bitcoin holders have therefore chosen to wrap their BTC on other chains or rely on centralized exchanges, neither of which offers the trustlessness and control that they really want.
Currently, there are really only two possible ways around Bitcoin’s programmability restraints while retaining Bitcoin’s security model:
- Add new opcodes: These are new built-in functions which can be added to Bitcoin code to reduce program size in order to fit them into Bitcoin’s 4MB blocks. There is significant community resistance to changing Bitcoin’s code, which makes this unlikely in the short term.
- Use BitVM: BitVM allows for programs to be run on Bitcoin in an optimistic manner, which means it handles most computation off-chain and is therefore not hampered by Bitcoin’s limitations. However, if anyone disagrees with the result, they can raise a dispute on-chain on Bitcoin. If there’s any cheating, the fraudulent person gets exposed, and is punished.
Out of the two proposed solutions, BitVM is the only one that is currently possible.
Trustless bridging and true Bitcoin rollups
Originally proposed by Robin Linus of ZeroSync, BitVM has two main potential use cases:
- Trustless Bitcoin bridges: Reimagining bridging for Bitcoin DeFi, dramatically improving on all current Bitcoin bridge models which require you to trust someone with your Bitcoin. Enables BTC to be easily and safely transported into new ecosystems—like BOB.
- True Bitcoin rollups: Although bridges are currently the number 1 use case, in the future it could be possible to use BitVM to run a true Bitcoin rollup where transaction data is stored on the Bitcoin blockchain. No current Bitcoin L2s do this yet because of the huge cost of that blockspace. How to do this efficiently is still being researched.
BitVM2—the latest, most practical version that almost everyone is using as their bridge blueprint—stems from a year-long collaboration between Robin Linus, BOB co-founder Alexei Zamyatin, and other researchers. This puts BOB in a unique position with a deep understanding of the theory of BitVM, plus a clear path to its successful delivery.
BOB’s BitVM bridge design is customised for the Hybrid Layer 2
As you may have learned in our previous 101 article, BOB is a Hybrid Layer 2 that will anchor its security in Bitcoin while offering Ethereum-style DeFi. BitVM2 plays a central role in BOB’s hybrid design:
- Trust-minimized bridges: Rather than trusting multisignature groups or centralized custodians, BitVM ensures that as long as there is at least one honest participant, no one can steal funds. A successful prototype was recently tested in conjunction with Fiamma—a game-changer for bridging BTC into BOB.
- Accelerating Bitcoin DeFi: With BitVM, BTC can seamlessly move onto BOB, interact with various DeFi dapps, and then withdraw back to Bitcoin with minimal trust. Any dishonest operator can be challenged on-chain, which keeps the system safe.
BitVM roles and responsibilities
A BitVM bridge is different from other bridges you might have studied. While there is a single bridge smart contract on BOB, there are many instances of the BitVM program on Bitcoin. Each time BTC is bridged to BOB, a new instance of the BitVM program is created. Each instance of the BitVM program ensures that BTC can only be unlocked if the BitVM BTC are also burned on BOB and the user receives their BTC back on Bitcoin. The instances are supported by several groups of participants, each with important roles and responsibilities.
Operators
Operators are the keystones that support the bridge operation. They are responsible for setting up the instances of the BitVM program required for BTC deposits. Then for withdrawals back to the Bitcoin layer-1, they send BTC from their own funds to the user, and reclaim that BTC from the BitVM deposits. This means users do not need to wait for the full challenge period before receiving their assets.
Committee
The committee is responsible for signing the Bitcoin transactions that form each instance of the BitVM program. On a high level, BitVM instances can be treated as a black-box that allows optimistic verification. Under the hood, several Bitcoin transactions need to be connected to implement the logic. The committee’s signatures serve as the connections. In the future, the committee can be replaced if Bitcoin Script implements covenants.
Liquidity providers (LPs)
Professional liquidity providers are expected to handle the minting of the vast majority of BitVM BTC on BOB. That’s because each mint and therefore each new instance of BitVM will include a large amount of BTC - typically 10 or 100 BTC for efficiency. Similarly each withdrawal must be of a full BitVM instance - partial withdrawals are not possible. This is impractical for everyday users, so the LPs are responsible for re-balancing the assets between the L1 and L2.
Challengers
Challengers ensure the safety of the withdrawal process by monitoring transactions and challenging an operator in case of misbehaviour. The operators and DeFi users themselves are permitted to act as challengers.
Bitcoin DeFi users
Rather than directly using BitVM, most DeFi users will swap into BTC on BOB via atomic cross-chain swaps powered by BOB Gateway and Bitcoin intents. This means they will do a direct swap of their native BTC for trust-minimized BitVM bridged BTC on BOB, that was previously brought onto the L2 by one of the LPs. This delivers a near “CEX-like” experience despite BitVM’s under-the-hood complexity, similar to how liquidity bridges on Ethereum function—all without needing to trust a central custodian.
BitVM/acc
BOB founded bitvm/acc with 20+ research and institutional partners to accelerate BitVM adoption. The technology is only as good as the people who use and support it, so bitvm/acc is designed to help educate and onboard top tier operators and LPs.
BitVM step by step
The latest BitVM2 design, co-authored by BOB co-founder Alexei Zamyatin, enables practical fraud proofs on Bitcoin, which is what allows us to enforce trust minimized bridging between the Bitcoin L1 and BOB. This is understandably a bit harder to keep simple but we’ll give it a go. The below process is for the deposit and withdrawal of 10 BTC through a single instance of the BitVM program.
1. Setup the BitVM instance
The operator sets up an instance of BitVM for 10 BTC, the committee checks it and presigns the required transactions. The instance is a program in Bitcoin script, which is then compressed into a zero knowledge (ZK) proof. A SNARK verifier can be 2GB in size which is still far too large for a 4MB Bitcoin block. The SNARK is then divided into sequential sub-programs so that each can fit into a block.
2. Deposit BTC (peg-in)
The user sends the BTC to the address associated with this BitVM instance and 10 BTC is minted on BOB.
3. Withdraw BTC (peg-out)
The user requests a peg-out and selects an appropriate peg-in. The full amount locked in the BitVM address must be withdrawn at the same time back to the Bitcoin L1 - in this case, the whole 10 BTC. An operator accepts the request and sends BTC from their own funds to the user’s address on the L1. Payment is proved on BOB using a relay, the BTC on BOB is burned, and the operator starts the reimbursement process. If there is no challenge forthcoming, the operator is able to claim the 10 BTC locked in the BitVM address.
4. Challenge
During the challenge period and before the operator is able to reclaim the BTC from the BitVM instance, challengers verify the process has been completed correctly with the BTC on BOB burned and the BTC on Bitcoin provided to the correct address according to the transactions presigned during the setup phase. If a challenger thinks that the reimbursement request is fraudulent, they are able to submit a challenge. If this happens, the operator has to submit the proof data on the Bitcoin chain.
5. Prove
If the transaction is fraudulent, the proof will be incorrect, and the challenger is able to submit a transaction that slashes the operator’s collateral and prevents the claim from going through. If the operator was incorrectly challenged, the disprove transaction will fail and the operator will be able to reclaim the BTC.
BitVM + BOB: Unlocking Bitcoin DeFi
BitVM2 + BOB’s Hybrid L2 is the missing puzzle piece for unlocking Bitcoin DeFi’s full potential. No more depending on big custodians or complicated multi-signature groups—just one honest participant is all it takes to keep everyone safe.
The result is a win on every front. Retail users and large institutions alike will be able to deploy their BTC in DeFi with full custody and trust-minimized security, while developers benefit from a very secure BTC ERC-20 token powered by BitVM—allowing them to leverage Bitcoin’s unmatched liquidity for their dapps.
