# Background
The Bitlayer BitVM Bridge is a Bitcoin bridging solution optimized based on [BitVM2](https://bitvm.org/bitvm_bridge.pdf) protocol, which leverages Bitcoin’s security and efficiency for cross-chain interactions using n-of-n multisignature and zero-knowledge proofs (ZKP).
# How does Bitlayer BitVM Bridge work?
You can gain a comprehensive understanding of Bitlayer BitVM Bridge architecture by reading [this blog](https://blog.bitlayer.org/introducing_finality_bridge/). This document provides a detailed description of the Bridge Contract B (Deployed on Sui).
## Transaction Graph on Bitcoin
This part is not within the audit scope, but some of these transactions will be provided as inputs to the Sui contract. Understanding the details of these transactions can help identify deeper business logic bugs.

### Overview
After a `Pegin` transaction is issued, which means the bridge smart contract is established. When a user(Bob in this figure) initiates a withdrawal, they essentially create an `Pegout`(Initiated) transaction, and its first input comes from Bob(`Predecessor` transaction). The `Pegout`(Initiated) transaction, signed with a `single|anyonecanpay` signature type, signifies the user's intent to get funds. However, it's incomplete because it only contains the user's input and the desired output. Upon receiving the `Pegout`(Initiated) from destination chain, the Broker is responsible for completing the transaction by adding the corresponding UTXOs. Following this, the Broker can then initiate the reclaim process. There are 4 possible results for a reclaim
- HappyTake: If the Broker is honest, a `KickOff` transaction will be issued by the Broker. some days(7 days in our example) later, the Beneficiary can reclaim the funds through a `HappyTake` transaction.
- UnhapyTake: If the Broker is honest but the Watcher suspects malicious intent, the Broker issues a `KickOff` transaction. The Watcher responds with a `Challenge` transaction. The Broker then provides `PreAssert` and `Assert` transactions to prove their honesty. If the Watcher finds no errors in the proof, the Broker can reclaim the funds via an `UnhappyTake` transaction 15 days after the `Assert`.
- Disprove: If the Broker is malicious, such as no withdraw happened or they didn't issue the associated `Pegout`(Finalized) transaciton but they issue a `KickOff` transaction. Then the Watcher detects the malicious behavior and issues a `Challenge` transaction. The Broker attempts to defend themselves by issuing `PreAssert` and `Assert` transactions, but these only contain incorrect proof. The Watcher, upon verifying the proof, will issue a `Disprove` transaction to halt the reclaim process
- `Timeout`: In another case of malicious behavior, the Broker issues a `KickOff` transaction, and the Watcher detects this, leading to a `Challenge` transaction. If the Broker chooses not to issue `PreAssert` or `Assert` transactions, the Watcher can issue a `PreAssertTimeout` or `AssertTimeout` transaction to stop the reclaim.
### Pegin
- version: 1
- locktime: 0
- txin: Any, while all inputs are of the same type, only one is shown here for simplicity. This does not imply that there is only one input.
- input0:
- previous outpoint: any if the user can spend
- sequence: MAX
- script bytes: 0
- witness: Anything that can spend the UTXO, perhaps they are some signatures and public keys
- txout: Depends on the splitting policy and the desired deposit amount. For example, if the total input sum is $a$, the change amount is $b$, the fee is $c$ and each reclaimable UTXO's denomination is $d$ ,then the total output number is: $\frac {a-b-c}{d}$ + 1 (Optional, for change) + 1 (MUST, for inscription)
- output0: It is the reclaimable UTXO, The total number reclaimable UTXOs is $\frac {a-b-c}{d}$
- amount: It depends on the splitting policy, in our example is $2$ BTC
- script_pubkey: A taptree consists of `CheckSig` and `MultiSigs` scripts
- output1(Optional): If the sum of inputs exceeds the total of reclaimable UTXO plus the transaction fee, the excess will be included in this output; if nothing is left, the output will not exist.
- amount: $b$ BTC
- script_pubkey: The address provided by the user
- output2: It contains the ethereum address
- amount: 0 BTC
- script_pubkey: `Inscription` script, the inscripted information is ethereum address

## Sui Smart Contracts
The process flowchart is as follows:

### Mint
1. After the pegin transaction occurs on Bitcoin, the minter constructs the corresponding mint transaction and calls the bridge system contract.
2. The bridge contract calls the relayercontract to verify whether the corresponding transaction exists on Bitcoin and matches the pegin transaction.
3. The Committee, during the pre-signing step, will also endorse the signed pegin transaction to prevent attackers from arbitrarily constructing pegin transactions for double-spending. Therefore, the bridge contract calls the committeecontract to verify the mint tx's validity.
4. For validated Pegin transactions, we record the relevant information in the contract to prevent duplicate minting. Then call the treasury contract to mint yBTC to the account.
### Burn
1. For a pegout, the user needs to specify the pegin transaction and, as shown in the diagram above, provide the predecessor transaction along with a pre-signed PSBT pegout transaction. This ensures that only one broker can front the funds by fulfilling this transaction.
2. The bridge contract calls the relayercontract to verify the SPV proof of the predecessor transaction
3. After successful verification, it updates the pegin status to 'spent' and burns the yBTC from its account. Then the contract generates a pegout request, which will then be picked up by a broker who listens and fronts the funds on the BTC chain.