Introduction
We express our gratitude to the AIRDAO team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Air DAO is a bridge solution consisting of 2 contracts, one for each network, and a relay - software that monitors these contracts and sends them user transfers.
title | content |
---|---|
Platform | BSC, Ethereum, AMB |
Language | Solidity |
Tags | ERC20, Bridge |
Timeline | 22/04/2024 - 31/05/2024 |
Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
---|---|
Repository | https://github.com/ambrosus/ambrosus-bridge/tree/dev→ |
Commit | c2ff4a510b5fbe52dc432421d83ed0e2363f7d80 |
Review Scope
- Commit
- c2ff4a510b5fbe52dc432421d83ed0e2363f7d80
Audit Summary
10/10
81.76%
8/10
10/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 AIRDAO |
Audited By | Turgay Arda Usman |
Approved By | Grzegorz Trawinski, Ataberk Yavuzer |
Website | https://airdao.io/→ |
Changelog | 03/05/2024 - Preliminary Report |
31/05/2024 - Final Report |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for AIRDAO
- Audited By
- Turgay Arda Usman
- Approved By
- Grzegorz Trawinski, Ataberk Yavuzer
- Website
- https://airdao.io/→
- Changelog
- 03/05/2024 - Preliminary Report
- 31/05/2024 - Final Report
System Overview
Air DAO Bridge is a secure cross-chain token bridge. It allows users to transfer tokens between two blockchains through a relay network. Users lock tokens on one network, and the bridge mints a synthetic equivalent on the other network after a designated lock period. It has the following contracts:
Eth_AmbBridge — deployed on AMB, receive transfers from ETH.
Eth_EthBridge — deployed on ETH, receive transfers from AMB.
Bsc_AmbBridge — deployed on AMB, receives transfers from BSC.
Bsc_BscBridge — deployed on ETH, receives transfers from AMB.
CommonBridge — contains the core bridge logic.
SignatureCheck —contains a signature checker function.
CommonStructs — a library that contains the common structs.
BridgeERC20_Amb — ERC20 token with decimal conversion logic. It also contains logic for handling side network transfers.
BridgeERC20 — ERC20 token with logic for handling side network transfers.
sAMB — ERC20 token with withdraw and deposit logic for the native token wrappers.
Faucet — faucet implementation for proxies.
MultiSigWallet — multi-sig wallet implementation.
Proxy — proxy implementation for multi-sig wallets.
Privileged roles
DEFAULT_ADMIN_ROLE can grants and revoke all roles below; Set to multi-sig (proxy contract address).
The ADMIN_ROLE can change tokens; unpause contracts; and change params like lockTime, and minSafetyBlocks.
The RELAY_ROLE can submit transfers.
The WATCHDOG_ROLE can pause contracts.
The FEE_PROVIDER_ROLE must sign fee signatures.
Executive Summary
Documentation quality
The total Documentation quality score is 10 out of 10.
Functional requirements are provided.
Technical description is provided.
Code quality
The total Code quality score is 8 out of 10.
The code mostly follows style guides and best practices.
See informational issues for more information.
The development environment is configured.
Test coverage
Code coverage of the project is 81.76% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative case coverage is missed.
Interactions by several users are not tested thoroughly.
Compilation fails due to node-gyp build.
Security score
Upon auditing, the code was found to contain 0 critical, 2 high, 5 medium, and 2 low severity issues. Out of these, 6 issues have been addressed and resolved, 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 8.9. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
Making external calls within loops increases the risk of gas exhaustion, potentially leading to failed transactions and reduced contract reliability, especially when processing large datasets.
The token ecosystem grants a single entity the authority to implement upgrades or changes. This centralization of power risks unilateral decisions that may not align with the community or stakeholders' interests, undermining trust and security.
The implemented Wrapper logic highly depends on external contracts not covered by the audit. This reliance introduces risks if these external contracts are compromised or contain vulnerabilities, affecting the audited project's integrity.
The project does not support non-standard ERC20 tokens. Adding such tokens in the future can cause additional risks.
Findings
Code ― | Title | Status | Severity | |
---|---|---|---|---|
F-2024-1915 | Reentrancy Vulnerability While Unlocking Transactions | fixed | High | |
F-2024-1906 | Exposed Private Keys in Repository Files | fixed | High | |
F-2024-2020 | Incompatibility with ERC20 Tokens Not Returning Boolean on Transfers | fixed | Medium | |
F-2024-1938 | Withdrawals are not Affected From Pausability | fixed | Medium | |
F-2024-1936 | The usage of the precompile ecrecover can lead to signature mailability | fixed | Medium | |
F-2024-1928 | Use Of Transfer() Instead Of Call() To Send Funds | fixed | Medium | |
F-2024-1913 | Requirements Validation - Missing Access Control Allows Anyone to Trigger Transfers | mitigated | Medium | |
F-2024-1940 | Missing Duplicate Check via Locking Transfer Events | mitigated | Low | |
F-2024-1939 | Checks Effects Interactions Pattern Violation | accepted | Low | |
F-2024-2023 | Return Value not Being Utilized | accepted | Observation |
Identify vulnerabilities in your smart contracts.
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/ambrosus/ambrosus-bridge/tree/dev→ |
Commit | c2ff4a510b5fbe52dc432421d83ed0e2363f7d80 |
Whitepaper | N/A |
Requirements | https://github.com/ambrosus/ambrosus-bridge/tree/dev→ |
Technical Requirements | https://github.com/ambrosus/ambrosus-bridge/tree/dev→ |
Scope Details
- Commit
- c2ff4a510b5fbe52dc432421d83ed0e2363f7d80
- Whitepaper
- N/A
- Technical Requirements
- https://github.com/ambrosus/ambrosus-bridge/tree/dev→