summary:
Layer 2s should be as censorship-resistant as the Layer 1 public chains they are based on;
On BOB, users can already force withdrawal their assets from BOB to Ethereum via transactions on Ethereum;
For the BitVM bridge, BOB is working on integrating the Bitcoin network as a way for users to perform transactions on BOB;
Bitcoin users can withdraw BTC assets from BOB without sending transactions to BOB.
On February 4, 2025, the hybrid Layer 2 project BOB released the BitVM forced withdrawal function for the first time on its official blog. This is the first time that BTC Layer 2 has made substantial progress on the specific function of forced withdrawal, which is of primary significance to the Bitcoin ecosystem and the entire industry.
Vitalik has emphasized that whether users can smoothly withdraw assets from Layer 2 to Layer 1 is a very important safety indicator. In an emergency, the forced withdrawal function is as important to Layer 2 as the safe exit in the real world. In Ethereum Layer 2, a custody platform system that carries tens of billions of dollars in assets, the forced withdrawal function that allows users to safely withdraw assets to Layer 1 has become an indispensable facility.
For Layer 2 public chains using the EVM protocol, there are relatively complete forced withdrawal and escape hatch functions on the market to ensure that users can withdraw their assets safely and promptly to Layer 1. Below, we can learn how BOB completes the forced withdrawal function of BTC Layer 2 through this blog .
One of the core properties of Layer 2s is that their state transitions need to continue even if the sorter is offline . Layer 2s do this by reading and writing their state from the Data Availability (DA) layer, which can be updated online independently of Layer 2. This allows users to enforce their transactions even if the sorter is offline or the sorter does not accept the users transaction request. Because if the sorter keeps rejecting the users transaction request, or simply fails for a long time, or even shuts down, this often results in huge financial losses.
For example, during the Solana outage, some people were unable to replenish their positions in time because their assets were facing liquidation, which put millions of dollars of assets at risk. Once such a scenario of rejecting user requests occurs, the economic losses caused cannot be underestimated.
This raises an interesting question for BOBs BitVM bridge. BOB currently uses Ethereum EIP-4844 blobs as its DA layer. Users on Ethereum can easily withdraw assets back to the Bitcoin network through the BitVM bridge, but in this process, users are required to hold ETH on Ethereum as gas fees.
So, this is not user-friendly enough, Bitcoin users only need BTC on the Bitcoin network to withdraw their BTC from BOB back to Bitcoin. BOB is working on a hybrid solution: using Ethereum as the DA layer by default, while allowing users to force the inclusion of transactions on BOB through special transactions on Bitcoin.
Data availability (DA) and derived context
The derivation process is very important for Layer 2 public chains: BOBs entire Layer 2 state needs to be built from L1 and DA layers. It allows Layer 2 to enjoy the same censorship resistance as the DA layer (Ethereum in this case).
Simply put , in rollup (especially public chains using OP Stack), we have two types of data on Layer 1:
Deposit transactions made to the OptimismPortal contract. These are transactions made by users on Ethereum, typically depositing their assets into BOB. These deposit transactions can also be used to perform other transactions on BOB.
Batches submitted by the sorter (or more accurately, op-batcher) from Layer 2 transaction processing. These include all transactions made directly by users on BOB and eventually included in the Ethereum blob.
Bitcoin as a DA layer
If you want Bitcoin as a DA layer, why not just switch to using Bitcoin completely as a DA layer? The reason is mainly cost. Bitcoin has very little available storage space (about 4 MB every 10 minutes), so storage costs are high.
However, in this case, BOB can still use Ethereum as its primary DA layer, publishing its entire transaction data there, but add Bitcoin as a highly censorship-resistant fallback layer if the Ethereum DA is unavailable. In essence, Ethereum becomes the optimistic DA layer, while Bitcoin becomes an expensive but fault-tolerant last resort.
Hybrid Derivation Pipeline
The basic solution is to add Bitcoin to BOB as part of the derivation pipeline, so that BOB (specifically the op-node) processes the inputs in the following order:
Bitcoin forced withdrawal transaction (newly added specifically for BOB);
Ethereum deposits to BOB’s OptimismPortal contract (OP Stack standard);
Ethereum batches from op-batcher (OP Stack standard).
There is a possible solution here, encoding a Bitcoin forced withdrawal transaction into the BOB derivation pipeline. This is still under research though, so it may change.
Bitcoin forced withdrawal transaction
BOB needs three parts to create a forced withdrawal transaction:
Constructing a forced withdrawal transaction on Bitcoin.
Storing forced withdrawal transactions within Bitcoin’s block size limit.
Gas fees for processing Bitcoin forced withdrawal transactions.
1. Construct a forced withdrawal transaction on Bitcoin
An OP Stack deposit transaction has the following structure:
bytes 32 sourceHash: source hash value, uniquely identifies the source of the deposit.
Address From: The address of the senders account.
Address to: The address of the recipient account, or an empty (zero-length) address if the deposited transaction is a contract creation.
uint 256 mint: Value of ETH minted on L2.
uint 256 value: The ETH value sent to the recipient account.
uint 64 gas: Gas limit for L2 transactions.
bool isSystemTx: If true, the transaction does not interact with the L2 block gas pool.
Bytes data: call data.
A mandatory withdrawal transaction requires the encoded withdrawal transaction to be included in the data field of the deposit transaction. This is done by creating a transaction on BOB that triggers a withdrawal from BOB to Bitcoin, and it works exactly the same way as sending a transaction from Ethereum.
We can then store a (compressed) version of the forced withdrawal transaction on Bitcoin, which includes all of the above data.
2. Store the mandatory withdrawal transaction on Bitcoin
Since the data of the forced withdrawal transaction is larger than what should normally be stored in an OP_RETURN output, BOB may use a Taproot output to store the data.
While it is easy to identify a deposit transaction (which may include a withdrawal) on Ethereum because it is sent to BOB’s OptimismPortal contract, identifying a forced withdrawal transaction on Bitcoin is not so easy.
Data Serialization: Enforce withdrawal transactions to be serialized using Taproot scripts within an “envelope” structure. These are noops on the Bitcoin network and can also be used for ordinals, etc. We tweak the structure to suit our needs.
Unset
OP_FALSE OP_IF
OP_PUSH bob
OP_1
OP_PUSH transaction
OP_ 0
OP_PUSH $WITHDRAWAL_TRANSACTION_DATA
OP_ENDIF
Two-phase commit/display scheme:
As with ordinals, users must submit two transactions to Bitcoin:
Submit transaction: Create a Taproot output and submit to the script containing the inscription content. This transaction has not yet revealed the data, we need a second transaction from the BOB full node and sorter to include the withdrawal transaction.
Show transaction: spend the output of the submitted transaction and show the inscription on the chain, that is, show the users withdrawal transaction to be included in BOB.
3. Gas fees for processing Bitcoin forced withdrawal transactions
BOB is currently considering two options for the gas fee issue:
Set the Gas of the Bitcoin forced withdrawal transaction to 0 and deduct the Gas fee from the users ETH balance on BOB. In this way, only users with ETH on BOB can force withdrawals. However, this is not the best option because it requires users to have ETH on BOB to force withdrawals, i.e. users who have BTC on Bitcoin cannot force withdrawals.
Gas fees are paid by users on Bitcoin with BTC. The BOB network needs to have an address on Bitcoin that can receive BTC and effectively exchange the BTC received by the user into ETH on BOB to pay for the Gas cost of the Layer 1 part plus the execution cost. This option may be achieved by using BOB Gateway and setting the EVM address of BOB DAO as the BTC recipient.
Summarize
Anyone can determine the status of BOB simply by looking at the data on Bitcoin and Ethereum:
Read all withdrawal transactions for Bitcoin. Each withdrawal is encoded as two transactions, a commit transaction and a reveal transaction. This is our addition to the OP Stack and where we enhance the derivation pipeline.
Read all transactions made to BOBs OptimismPortal contract on Ethereum. This is already part of the standard OP Stack derivation pipeline.
All transactions made directly on the BOB are read and integrated as part of the Ethereum batch. Importantly, full nodes do not read directly from the sorter to receive confirmed transactions, but rather from the Ethereum blob. This is already part of the standard OP Stack derivation pipeline.
Technical Challenges
Data consistency: While ensuring data consistency between the Ethereum and Bitcoin chains is important, the mere presence of transaction data on both chains does not guarantee validity. Transactions must represent valid state transitions according to the rollup’s state transition function to be considered legitimate. This solution requires implementing validation logic inside the op-node (or other consensus layer implementation) to first verify that a transaction results in a valid state change before accepting it.
Fraud proofs and validity: Both BitVM and Ethereum’s fraud proof systems need to be enhanced to handle data from both chains, which could make dispute resolution more complicated. To address this, BOB needs to accurately account for possible transactions from Bitcoin and Ethereum as part of the BitVM bridge and BOB settlement on Ethereum.
Increased storage: In addition, BOB nodes in the network face increased storage and bandwidth requirements as they need to process and store data from both Bitcoin and Ethereum. However, we can mitigate this by requiring that BOB transactions made on Bitcoin need to be included in Ethereum blobs and reference the latest Bitcoin block. This way, nodes only need to sync the most recent Bitcoin block.
The debut of the forced withdrawal function on BTC Layer 2, led by BOB, has greatly promoted the innovation of the hybrid L2 model that combines the security of Bitcoin with the innovation of Ethereum. On the specific issue of forced withdrawal, BOB combines Bitcoins anti-censorship nature with BOBs rollup stack to complete the forced withdrawal function of BTC Layer 2, thereby ensuring the security of users assets in extreme cases.
About BOB (Build on Bitcoin)
BOB (Build on Bitcoin) is a hybrid Layer-2 network that combines the best of Bitcoin and Ethereum, and is committed to establishing itself as the Home of BTC DeFi. The unique Hybrid L2 model combines the advantages of both ecosystems - Bitcoins security and dormant BTC capital, and Ethereums DeFi innovation and versatility. By positioning BTC as the backbone of a new decentralized financial system, BOB can unlock new use cases and trillions of BTC liquidity. BOB perfectly inherits the security of the Bitcoin network using the BitVM protocol, and creates a trust-minimized bridge between BOB, Bitcoin, Ethereum, and other L1 networks. As a result, Hybrid L2 does not need to rely on a third-party cross-chain bridge for interoperability, easily concentrating liquidity around the Bitcoin network instead of being scattered across various chains.
BOB is supported by leading investment institutions such as Castle Island Ventures, Coinbase Ventures, Ledger Cathay Ventures and IOSG.
