Background

The Bitlayer BitVM Bridge is a Bitcoin bridging solution optimized based on BitVM2 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. This document provides a detailed description of the audit scope, which is divided into two main sections: Bridge Contract A (Deployed on Bitcoin) and Bridge Contract B (Deployed on Ethereum).

Bridge Contract A

Bridge Contract A is essentially a set of Bitcoin transactions (which we will refer to as the TransactionGraph), as shown in the diagram below.

Different colored dashed boxes represent the presigning actions of different roles and the scope of their presigned transactions.

Transaction Details

For the sake of clarity, potential change outputs in the transactions are omitted from the diagram.

Pegin

Peg-in users only deposit funds after verifying that the correct smart contract instance has been generated and published. If no deposit occurs, no party is at risk.

• Input
  • There may be multiple inputs from a Peg-in user
• Output
  • A taproot with two unlocking conditions:
    1. The Committee's signature, used for HappyTake or UnhappyTake tx
    2. The Security Council's signature, used for emergency situation
  • OP_RETURN: containing the Ethereum address that the Peg-in user intends to deposit to.

Pegout (partial)

After the Pegout user burns yBTC on Ethereum, they must pre-sign a Pegout transaction and make it publicly available.

• Input
  • An UTXO from the Pegout user, where the unlocking script contains the signature of the user on part of the transaction content using the SinglePlusAnyoneCanPay method.
• Output
  • The withdrawal address is the Pegout user, and the amount corresponds to the amount burned on Ethereum.

Pegout (complete)

• Input
  • There may be multiple inputs from a Broker
• Output
  • OP_RETURN: The corresponding Peg-in transaction and vout that needs to be consumed. Additionally, the broker's own Bitcoin address is required to inform the zk program of who made the advance payment.

Kickoff

The Kickoff transaction represents the start of the reclaim process.

• Input
  • There may be multiple inputs from the Broker
• Output
  • Broker: used for HappyTake tx or Challenge tx
  • A taproot with three unlocking conditions:
    1. The Committee's signature and a Timelock, used for HappyTake tx
    2. The Committee's signature and the Broker's signature, used for Assert tx
    3. The Committee's signature and a Timelock, used for PreAssert Timeout tx
  • OP_RETURN: Same as the OP_RETURN output of Pegout tx, it will be verified in the Prover that the OP_RETURN contents of these two transactions match, to prove that the Pegout and Kickoff transactions correspond to each other.

HappyTake

If no one initiates a challenge after a certain period of time, the Broker can complete the reclaim through HappyTake.

• Input
  As described in the diagram
• Output
  • Broker

Challenge

The challenge transaction is pre-signed by the Broker. Anyone can initiate a challenge by paying the challenge fee to the Broker.

• Input
  • Broker output of the Kickoff tx
  • Watcher (could be anyone who pays the fee)
• Output
  • Broker

PreAssert

If someone challenges the Broker, the Broker needs to issue a set of Assert transactions within the specified time frame.

• Input
  As described in the diagram
• Output
  • A taproot with two unlocking conditions:
    1. The Committee's signature, used for Assert tx
    2. The Committee's signature and a Timelock, used for Assert Timeout tx
  • Plenty of taproots, each of which makes a commitment to a BitCommitment. These commitments will be revealed in the Assert transaction. Additionally, the unlocking condition for each output must include the Committee's signature.

Assert

• Input
  As described in the diagram
• Output
  • A taproot with two unlocking conditions:
    1. The Committee's signature and a Timelock, used for Unhappy Take tx
    2. The Committee's signature, used for Disprove tx
  • Any revealed BitCommitment value cannot be validated, used for Disprove tx

PreAssertTimeout

If a Watcher initiates a challenge but the Broker does not issue an Assert transaction within the specified time, anyone can send an AssertTimeout transaction to penalize the Broker.

• Input
  As described in the diagram
• Output
  • BURN: burn most of the staked BTC
  • Watcher: rest of the staked BTC will be reawarded to anyone who issues this tx

AssertTimeout

• Input
  As described in the diagram
• Output
  • Same as PreAssertTimeout tx

UnhappyTake

If the challenged Broker correctly reveals the BitCommitment via PreAssert & Assert and the specified period has elapsed, the Broker can complete the reclaim process through an UnhappyTake transaction.

• Input
  As described in the diagram
• Output
  • Broker

Disprove

If the Broker reveals an incorrect BitCommitment during Assert, anyone can immediately penalize the Broker by sending a Disprove transaction, resulting in the burning of the Broker’s staked BTC and redistribution of the funds to the Watcher.

• Input
  As described in the diagram
• Output
  • BURN: burn most of the staked BTC
  • Watcher: rest of the staked BTC will be reawarded to anyone who issues this tx

ETH Smart Contracts

The current audited code only includes the implementation of the Bitcoin-to-ETH bridge. Therefore, the smart contract is designed specifically for the Ethereum contract. The process flowchart is as follows:

Mint

1. After the pegin transaction occurs on Bitcoin, the pegin user constructs the corresponding mint transaction and calls the bridge system contract.
2. The BitlayerBridgeV2 contract calls the BitcoinTx contract to check the validity of the user-provided Pegin data.
3. The Attesting 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 BitlayerBridgeV2 contract calls the AttestingCommittee contract to verify the mint tx's validity.
4. The BitlayerBridgeV2 contract calls the BitcoinTx contract to verify whether the corresponding transaction exists and matches the pegin transaction.
5. Call the YBTC contract to mint yBTC to the account.

Burn

1. Pegout user sends the burn tx.
2. The BitlayerBridgeV2 contract calls the BitcoinTx contract to check the validity of the user-provided pegout request.
3. After successful verification, it burns the yBTC from its account back to the YBTC contract.

ZK Prover

The ZK Prover itself is not included in the scope of this audit, but it relies on some of the data provided by these two contracts to generate proofs. I'm sharing the Prover's proof logic here, please also help us check if there might be any potential vulnerabilities in the way these contracts provide that data.

• Check the integrity of the Burn, Pegout, and Kickoff txs based on the committee endorsements (threshold signatures).
• Check whether the OP_RETURN output in the Pegout tx contains the three parameters — txid, vout, and the broker address — and whether they are in the correct format.
• Check whether the information in the Burn tx matches the OP_RETURN output provided in the Pegout tx, in other words, verify that the Burn tx is indeed targeting the given Pegin tx id, vout, and broker address.
• Check that the OP_RETURN content in the Kickoff tx is identical to that of the Pegout tx to ensure they correspond properly.