Bitcoin L3 Audit Report

Prepared by Fuzzland

Overview

This document details our collaborative engineering effort with Bitcoin L3 regarding their protocol.

Project Name	Bitcoin L3
File Hash	c19b81e75729dab8717b7604541f4732
Language	Solidity

Targets

Contract Name	File Location	Overview
Bridge	Bridge.sol#L12	Implementation of a bridge to transfer tokens between different blockchains.
BTCL3	BTCL3.sol#6	Bitcoin L3 ERC20 token.
Crowdsale	Crowdsale.sol#9	Crowdsale smart contract that manages multiple rounds of token sales with different price and limit configurations.
PrivateVesting	PrivateVesting.sol#12	Vesting contract that allows private sale token holders to claim their tokens after a cliff period, with partial token burning if claimed late.
ProjectVesting	ProjectVesting.sol#9	Vesting contract that allows token purchases from a private sale to be claimed over time based on a merkle root of allocations.
PublicDistribution	PublicDistribution.sol#9	Distribution contract that allows public sale token holders to claim their allocation after the sale ends based on a merkle root.

Disclaimer

The audit does not ensure that it has identified every security issue in the smart contracts, and it should not be seen as a confirmation that there are no more vulnerabilities. The audit is not exhaustive, and we recommend further independent audits and setting up a public bug bounty program for enhanced security verification of the smart contracts. Additionally, this report should not be interpreted as personal financial advice or recommendations.

Auditing Process

Static Analysis: We perform static analysis using our internal tools and Slither to identify potential vulnerabilities and coding issues.
Fuzz Testing: We execute fuzz testing with our internal fuzzers to uncover potential bugs and logic flaws.
Invariant Development: We convert the project into Foundry project and develop Foundry invariant tests for the project based on the code semantics and documentations.
Invariant Testing: We run multiple fuzz testing tools, including Foundry and ItyFuzz, to identify violations of invariants we developed.
Formal Verification: We develop individual tests for critical functions and leverage Halmos to prove the functions in question are not vulnerable.
Manual Code Review: Our engineers manually review code to identify potential vulnerabilities not captured by previous methods.

Findings

[LOW] [Bridge.sol] Centralization risk: Minimum confirmations of the bridge should be larger than 1

setMinConfirmations allows the new minimum confirmations to be set to 1. This is risky because if a bad signer can trick other signers into tuning the minimum confirmations to 1, this single signer is able to mint tokens.