## 5. Bridging Bitcoin and Bitlayer Network

### 5.1 Integration of the BitVM Bridge

A secure and reliable method for managing user assets is essential for rollup solutions. Among known approaches, the BitVM bridge stands out due to its robust architecture and practicality. The BitVM bridge securely facilitates the transfer of BTC from the Bitcoin network to Bitlayer, where it is represented as a native asset called BTR. Additionally, the bridge ensures secure and efficient asset withdrawals back to Bitcoin, providing users a trustworthy exit mechanism.

In our design, each user's deposit corresponds to an individual BitVM smart contract instance. Deposited funds are locked by the presign committee's address, and an equivalent amount of BTR is minted on Bitlayer. Liquidity providers can participate in these contract instances by redeeming BTC from the smart contracts, submitting appropriate proofs that include the associated 'Burn' transaction on Bitlayer and its corresponding claim on Bitcoin. You can learn more about Bitcoin-based claim verification [here](https://hackmd.io/LH3uh0sGSNWUpo22zKQG1w).

### 5.2 Roles

The BitVM protocol defines four primary roles—User, Broker, Attester, and Watcher—to ensure correctness and security.

**Users** hold assets either as BTC on the Bitcoin network or BTR on Bitlayer. When depositing assets, users interact with Brokers to obtain and verify necessary transaction information. Under normal conditions, users withdraw funds by initiating a `Burn` transaction on Bitlayer. In emergency scenarios, users directly issue a `force inclusion` transaction on the Bitcoin network.

**Brokers** assist users in preparing deposits and withdrawals, including constructing initial transaction graphs and obtaining signatures from Attesters. Brokers directly interface with users, abstracting the complexity of the BitVM protocol and enabling seamless interaction.

**Attesters** collectively form a trusted group characterized by existential honesty, meaning the group's security relies on at least one member being honest. They verify transaction graphs submitted by Brokers and provide signatures upon successful validation, safeguarding the protocol's integrity.

**Watchers** act as protocol overseers, continuously monitoring transactions to detect potential violations by Brokers. This role is permissionless, allowing any participant to initiate challenge transactions against malicious activities, thus enhancing the protocol's security.

### 5.3 Reclaim Checker


Several critical validations are implemented to safeguard user funds during withdrawals. Initially, users must burn BTR on Bitlayer, generating a specific event to verify the burn. The event structure is defined as follows:

event Burn(address sender, bytes32 txid, uint256 vout, bytes32 predecessorTxid, uint256 predecessorVout, uint256 brokerAmount, uint256 brokerFee, bytes32 targetScriptHash)

Upon detecting a `Burn` event, Brokers front the withdrawal funds by completing a `PegOut` transaction on the Bitcoin network. Subsequently, a `KickOff` transaction initiates the reclaim process. Watchers validate this reclaim; if they identify any invalidity, they issue a `Challenge` transaction. Brokers must then respond with `Assert` transactions containing Groth16 proofs. If Watchers verify these proofs as invalid, they issue a `Disprove` transaction to penalize the Broker.

The reclaim checker depends on Bitlayer's light client, relying on Bitcoin to finalize Bitlayer transactions. Consequently, a Bitlayer `Burn` transaction can only be validated after finalization on Bitcoin. The initial transaction (`Bootstrap`) of the rollup is embedded in the verifier's script. If challenged, Brokers must provide a verified transaction chain from `Bootstrap` to `Acceptance`, validated via the Bitcoin light client and included within the Groth16 proof disclosed in the `Assert` transaction.

#### 5.3.1 Escape Hatch

For security reasons, the bridge protocol needs to provide an exit path to return user funds when the rollup is not running or in abnormal circumstances.
In the Rollup protocol, we require the Operator to submit batch to Bitcoin regularly at a certain interval. Once the Operator fails to submit within the specified time, anyone can send a slash transaction to interrupt the Rollup process. In addition, since the proof of Rollup is a recursive proof, any illegal state transfer of a previous batch will result in the inability to generate a correct proof later. If the Operator continues to submit batch on this basis, it will only lose all the margin, because the batch that is not agreed upon cannot be finalized, and the funds locked in the bridge will always be safe.
In this case, we add a new path to the protocol to help users retrieve their assets. This also relies on Broker to complete liquidity front payment:
1. **Escape Account Binding**
When a user creates an account in the Bitlayer Rollup, the layer2 address will be bound to the future withdrawal address (native account abstraction).
2. **Force Inclusion of Withdrawal**
The user sends a withdrawal transaction to Bitcoin by sending a **force inclusion** transaction. Note that since the Rollup can no longer reach the final state, this force inclusion transaction cannot be finalized either.
3. **Broker Liquidity Provision**
Brokers monitor Bitcoin and collect enough user withdrawal requests until the withdrawal granularity specified in the Bridge smart contract is reached (the broker can collect handling fees in this process), brokers will then front the withdrawals of these users
4. **Reclaim**
The Broker who fronted funds initiates the reclaim process and provides a Groth16 proof that demonstrates:
- The Rollup protocol has been interrupted, proven by
- Lack of new batches (e.g., a CommitBatchTimeout transaction was the last observed activity).
- The last batch was successfully challenged (validated by slash transactions).
- The user withdrawal requests were valid, proven by
- Force inclusion transactions are proven to exist via a Bitcoin light client.
- The last valid Rollup batch state confirms the users had sufficient balances.
- Corresponding front transactions from the Broker are confirmed via a Bitcoin light client.

Through the escape hatch, users maintain control of their assets even if Layer 2 becomes unresponsive.
### 5.4 Pegin Flow

Depositing funds into Bitlayer involves a structured and secure multi-step process. Users initiate deposits by submitting a `PeginRequest` to all Brokers, specifying UTXOs for deposit, the target Bitlayer address, and a Bitcoin address for transaction change. Brokers respond with a complete `Pegin` transaction and the associated transaction graph, which users must carefully verify for correctness. After verification, users broadcast the confirmed `Pegin` transaction on the Bitcoin network. Once the transaction is included and finalized on Bitcoin, a `Mint` transaction is issued on Bitlayer, converting deposited BTC into BTR credited to the user's specified Bitlayer address.

### 5.5 Pegout Flow

When users request withdrawals exceeding the denomination of reclaimable UTXOs, they initiate a `Burn` transaction on Bitlayer. Users select a small (dust) UTXO, provide necessary signatures, and specify withdrawal details, including the receiving Bitcoin address and the amount. The difference between the withdrawal and received amounts serves as the Broker's fee. Brokers detect these events and, if the fee is acceptable, front the withdrawal funds, ensuring efficient completion of the user's transaction.

### 5.6 User Interaction and Asset Management

From the user's perspective, asset management within the Bitlayer environment is streamlined into three primary methods, each tailored to specific scenarios:

- **Pegin** enables users to securely deposit BTC into Bitlayer by verifying and broadcasting transactions provided by Brokers, converting BTC into BTR.

- **Pegout** facilitates efficient withdrawal of funds by initiating a `Burn` transaction on Bitlayer, after which Brokers front equivalent BTC on Bitcoin.

- **Escape** provides an emergency exit solution, allowing users to directly submit a `force inclusion` transaction on Bitcoin, with Brokers advancing the necessary funds promptly, ensuring asset recovery even in compromised situations.

Together, these mechanisms offer users flexibility, security, and convenience in managing their digital assets across Bitcoin and Bitlayer networks.