Prepared by:
HALBORN
Last Updated Unknown date
Date of Engagement: October 14th, 2024 - October 25th, 2024
100% of all REPORTED Findings have been addressed
All findings
25
Critical
0
High
0
Medium
3
Low
11
Informational
11
Atlas Protocol engaged Halborn to conduct a security assessment of the Atlas and atBTC token contracts for Near blockchain as well as the atBTC token for the EVM, beginning on October 14th, 2024, and ending on October 25th, 2024. This security assessment focused on the smart contracts within the Atlas Protocol Github repository.
Atlas Protocol is a BTC liquid staking protocol that allows users to deposit native Bitcoin and receive aBTC, a liquid staking token, on their chosen blockchain.
The team at Halborn assigned two full-time security engineers to verify the security of the smart contracts. The security engineers are blockchain and smart-contract security experts with advanced penetration testing, smart-contract hacking, and deep knowledge of multiple blockchain protocols.
The purpose of this assessment is to:
Ensure that smart contract functions operate as intended.
Identify potential security issues with the smart contracts.
In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were successfully addressed by the Atlas Protocol team. The main ones were the following:
Implement an emergency withdrawal feature for users whose deposits remain invalidated after a specified period or are likely to fail due to persistent errors.
Implement an error filtering mechanism to ensure that deposits guaranteed to fail are not rolled back.
Enable Two-Factor Authentication (2FA) for all privileged actions.
Remove the state-resetting functions from the Atlas contract prior to deployment.
Halborn performed a combination of the manual view of the code and automated security testing to balance efficiency, timeliness, practicality, and accuracy regarding the scope of the smart contract assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation, automated testing techniques help enhance the coverage of smart contracts. They can quickly identify items that do not follow security best practices. The following phases and associated tools were used throughout the term of the assessment:
Research into the architecture, purpose, and use of the platform.
Manual code reading and walkthrough.
Manual assessment of the use and safety of critical Rust variables and functions to identify potential arithmetic vulnerabilities.
Cross-contract call controls.
Logical controls related to architecture.
Scanning of Rust files for vulnerabilities using tools like cargo audit.
Integration testing using the NEAR testing framework.
| EXPLOITABILITY METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
| Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
| Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
| IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Confidentiality (C) | None (C:N) Low (C:L) Medium (C:M) High (C:H) Critical (C:C) | 0 0.25 0.5 0.75 1 |
| Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
| Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
| Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
| Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
| SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
|---|---|---|
| Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
| Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
| Severity | Score Value Range |
|---|---|
| Critical | 9 - 10 |
| High | 7 - 8.9 |
| Medium | 4.5 - 6.9 |
| Low | 2 - 4.4 |
| Informational | 0 - 1.9 |
Critical
0
High
0
Medium
3
Low
11
Informational
11
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Lacking Recovery Mechanism Increases The Risk Of Potential Fund Loss | Medium | Solved - 01/16/2025 |
| Deposits Guaranteed To Fail May Be Re-Executed Repeatedly | Medium | Solved - 12/04/2024 |
| Absence Of Two Factor Authentication For Privileged Functions | Medium | Solved - 12/04/2024 |
| Exposed Dangerous Functions That Could Reset Contract State | Low | Solved - 01/09/2025 |
| Centralization Risk | Low | Solved - 12/18/2024 |
| Lack of Mempool Verification in Deposit and Redemption Processes | Low | Solved - 01/09/2025 |
| Flawed Logic Allows Deposits To Be Marked As Minted Without Actually Minting Anything For The User | Low | Solved - 12/20/2024 |
| Missing Input Validation May Result In Corrupted Deposits, Leading To A Loss Of Funds | Low | Solved - 12/03/2024 |
| Lacking Pausability Mechanism | Low | Solved - 12/17/2024 |
| Inadequate Upper Bound for Protocol Fees | Low | Solved - 12/03/2024 |
| Lack Of State-Updating Upgrade Functionality | Low | Solved - 12/22/2024 |
| Potential for atBTC to Have Different Decimals from BTC | Low | Solved - 12/03/2024 |
| Ineffective Ownership Transfer Due to Lack of External Accessibility | Low | Solved - 12/02/2024 |
| Single-Step Ownership Transfer Process | Low | Solved - 12/02/2024 |
| Protocol Fees Are Not Incorporated Into The Contract Logic | Informational | Solved - 12/05/2024 |
| Unlocked Pragma Compiler | Informational | Solved - 11/24/2024 |
| Public Functions Never Called Internally | Informational | Solved - 11/26/2024 |
| Redundant State Existence Check During Contract Creation | Informational | Solved - 12/03/2024 |
| Use of Revert Strings Instead of Custom Error | Informational | Solved - 11/26/2024 |
| Inefficient Code | Informational | Solved - 12/03/2024 |
| Misleading Comment | Informational | Solved - 12/03/2024 |
| Presence Of Typographical Error | Informational | Solved - 11/24/2024 |
| Possible Optimizations To Reduce Binary Size | Informational | Solved - 12/03/2024 |
| Utility Functions Are Made Public Unnecessarily | Informational | Solved - 12/19/2024 |
| Deprecated And Lacking Tests | Informational | Solved - 12/19/2024 |
//Medium
//Medium
//Medium
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
// Download the full report
Atlas NEAR
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
