Prepared by:
HALBORN
Last Updated 12/13/2024
Date of Engagement by: May 21st, 2024 - August 27th, 2024
Summary
100% of all REPORTED Findings have been addressed
All findings
10
Critical
4
High
2
Medium
2
Low
2
Informational
0
Table of Contents
1. Introduction
The Dominant Strategies team engaged Halborn to conduct a security assessment on their fork of the go-ethereum client, beginning on May 21, 2024, and ending on August 27, 2024. The security assessment was scoped to cover the entire go-quai GitHub repository, located at https://github.com/dominant-strategies/go-quai/tree/51726eae3ba7e0cfd2aa4ff52ca2f0299a5d2d77, giving extra attention to the new consensus mechanism as well as the changes being done under the core folder.
2. Assessment Summary
The team at Halborn was provided fourteen weeks for the engagement and assigned two full-time security engineers to assess 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 achieve the following:
Ensure that the system operates as intended.
Identify potential security issues.
Identify lack of best practices within the codebase.
Identify systematic risks that may pose a threat in future releases.
In summary, Halborn identified some security issues that needed to be addressed by the Dominant Strategies team.
3. SCOPE
4. Findings Overview
| Security analysis | Risk level | Remediation |
|---|---|---|
| Rewards default to 0 | Critical | Solved - 10/25/2024 |
| Basefee changes between blocks at least 1GWei, instead of 1 Wei | Critical | Solved - 11/19/2024 |
| Rounding issues makes a header from an upper layer fall to the next one incorrectly | Critical | Solved - 11/16/2024 |
| Missing work share discount in blake3pow poem implementation | Critical | Solved - 10/25/2024 |
| Incompatible CREATE Opcode In EVM Implementation | High | Risk Accepted - 11/19/2024 |
| Infinite loop and resource consumption upon connecting to broken endpoint | High | Solved - 10/25/2024 |
| Possible deadlock in Multiplex implementation | Medium | Solved - 10/29/2024 |
| Missing fields in toCallArg | Medium | Solved - 10/29/2024 |
| Repeated code | Low | Solved - 10/29/2024 |
| Different panic logs between consensus implementations | Low | Solved - 10/29/2024 |
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.
Table of Contents
// Download the full report
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed