Introduction
We express our gratitude to the Bitlayer team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Bitlayer represents a revolutionary integration, melding elite decentralized exchange (DEX) mechanisms into an innovative, high-efficiency system. This pioneering approach is designed to streamline token exchanges and cross-chain transactions, ensuring seamless operability and liquidity management within the crypto ecosystem.
| title | content |
|---|---|
| Platform | EVM |
| Language | Solidity |
| Tags | Bridge |
| Timeline | 02/04/2024 - 04/04/2024 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/bitlayer-org/bitlayer-bridge→ |
| Commit | 41c7c06 |
| Repository | https://github.com/bitlayer-org/getBTC→ |
| Commit | 345036b |
Review Scope
- Commit
- 41c7c06
- Repository
- https://github.com/bitlayer-org/getBTC→
- Commit
- 345036b
Audit Summary
10/10
86.36%
9/10
7/10
The system users should acknowledge all the risks summed up in the risks section of the report
Document Information
This report may contain confidential information about IT systems and the intellectual property of the Customer, as well as information about potential vulnerabilities and methods of their exploitation.
The report can be disclosed publicly after prior consent by another Party. Any subsequent publication of this report shall be without mandatory consent.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Bitlayer |
| Audited By | Kaan Caglan |
| Approved By | Przemyslaw Swiatowiec |
| Website | https://www.bitlayer.org/→ |
| Changelog | 04/04/2024 - Preliminary Report |
| 08/04/2024 - Final Report |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Bitlayer
- Audited By
- Kaan Caglan
- Approved By
- Przemyslaw Swiatowiec
- Website
- https://www.bitlayer.org/→
- Changelog
- 04/04/2024 - Preliminary Report
- 08/04/2024 - Final Report
System Overview
Bitlayer bridge comprises three main contracts:
TokenExchange: Facilitates the exchange of tokens with rigorous permission and signature verification mechanisms. It supports operations like swapping tokens under specific conditions, withdrawing tokens, and modifying contract administrative roles.
BitlayerProxy: Serves as a proxy following the ERC1967 standard, allowing for future upgrades and changes to the contract logic without affecting the deployed version.
BitlayerBridge: Enables the locking and unlocking of native cryptocurrency transactions across different blockchain networks, with roles and permissions managed through AccessControl. It supports liquidity management, fee adjustments, and pausable functionality for emergency stops.
Contracts
TokenExchange
Functionalities:
Facilitates token swaps with ERC20 tokens using EIP712 signatures for permissioned operations.
Allows the withdrawal of ERC20 tokens and native cryptocurrency (referred to as "BTC" in comments) by the owner.
Supports owner and operator role management for executing sensitive contract operations.
Manages vaults that designate supported token addresses for swapping.
Attributes:
owner: Address of the contract owner.operator: Address of the contract operator.vaults: A mapping of addresses to boolean values, indicating whether a token address is supported for swaps.
Privileged Roles:
owner: Can transfer ownership, set the operator, manage vaults, and withdraw tokens.operator: Can execute thepermitAndSwapfunction.
BitlayerProxy
Functionalities: Serves as a minimalistic instance of the ERC1967Proxy, primarily for deployment purposes without additional specific functionalities.
BitlayerBridge
Functionalities:
Manages cross-chain transactions with functionality to lock and unlock native cryptocurrency.
Handles liquidity contributions and withdrawals, enabling users to support the bridge's operations with their assets.
Allows role-based management for pausing and unpausing contract operations, setting fee addresses, and adjusting fees.
Attributes:
feeAddress: Address where transaction fees are collected.lockFeeAmount: The amount charged as a fee for locking transactions.liquidityOf: Mapping of addresses to their contributed liquidity amounts.totalLocked: Total amount of cryptocurrency locked through the bridge.totalUnlocked: Total amount of cryptocurrency unlocked.
Privileged Roles:
AdminRole: Can upgrade the contract, manage roles, pause/unpause the bridge, and adjust fees and the fee address.PauseRole: Can pause contract operations.UnlockRole: Can unlock transactions, allowing the withdrawal of locked funds.LiquidityRole: Can manage liquidity withdrawals on behalf of others.
Executive Summary
Documentation quality
The total Documentation Quality score is 7 out of 10.
Functional requirements are partially missed.
Technical description is not provided.
Technical flow is not provided.
Code quality
The total Code Quality score is 9 out of 10.
Missing best practices
The development environment is configured.
Test coverage
Code coverage of the project is 86.36% (branch coverage),
Not all branches are covered with tests.
Security score
Upon auditing, the code was found to contain 0 critical, 0 high, 1 medium, and 3 low severity issues. After remediation part of the audit process 1 medium issue was mitigated, 2 low issues were fixed and 1 low issue was accepted, leading to a security score of 10 out of 10.
All identified issues are detailed in the “Findings” section of this report.
Summary
The comprehensive audit of the customer's smart contract yields an overall score of 9. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
Authorized used can call unlock function anytime to get balances in the contract..
Solidity version 0.8.20 might not work on all chains due to PUSH0 opcode.
There is no upper limit set for lockFeeAmount, allowing the admin to assign any valid integer value to it.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-1925 | Missing return value check on permit function | mitigated | Medium | |
| F-2024-1957 | Missing two-step ownership transfer process | accepted | Low | |
| F-2024-1956 | Missing lock limitations | fixed | Low | |
| F-2024-1915 | Missing checks for the zero address | fixed | Low | |
| F-2024-1984 | Unnecessary payable usage | fixed | Observation | |
| F-2024-1930 | Possible Gas optimization by using unchecked subtractions | fixed | Observation | |
| F-2024-1929 | Unneeded initializations of uint256 and bool variable to 0/false | fixed | Observation | |
| F-2024-1927 | Avoid using state variables directly in emit for Gas efficiency | fixed | Observation | |
| F-2024-1926 | Missing array length cache in for loop | fixed | Observation | |
| F-2024-1924 | Typos in the code | accepted | Observation |
Appendix 1. Severity Definitions
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/bitlayer-org/bitlayer-bridge→ |
| Commit | 41c7c064117218eef147f4ae7e7052708846273d |
| Remediation | 1f2b25eb3d7f8afef937bdd57be188fbe063abb3 |
| Repository | https://github.com/bitlayer-org/getBTC→ |
| Commit | 345036b3d5ce868347e5c46ab8a6fe2a071d78df |
| Remediation | 752b04b9b2856cc5f187c2190a07b0a26cf0cead |
| Whitepaper | Not provided |
| Requirements | Not provided |
| Technical Requirements | Not provided |
Scope Details
- Commit
- 41c7c064117218eef147f4ae7e7052708846273d
- Remediation
- 1f2b25eb3d7f8afef937bdd57be188fbe063abb3
- Repository
- https://github.com/bitlayer-org/getBTC→
- Commit
- 345036b3d5ce868347e5c46ab8a6fe2a071d78df
- Remediation
- 752b04b9b2856cc5f187c2190a07b0a26cf0cead
- Whitepaper
- Not provided
- Requirements
- Not provided
- Technical Requirements
- Not provided