Prepared by:
HALBORN
Last Updated 05/20/2025
Date of Engagement: April 30th, 2025 - May 2nd, 2025
Summary
100% of all REPORTED Findings have been addressed
All findings
3
Critical
0
High
0
Medium
1
Low
0
Informational
2
Table of Contents
1. Introduction
Azos Finance engaged Halborn to conduct a security assessment on their smart contracts beginning on April 30th, 2025 and ending on May 2nd, 2025. The security assessment was scoped to the smart contracts provided to Halborn. Commit hashes and further details can be found in the Scope section of this report.
The Azos Finance codebase in scope consists of a a smart contract responsible for fetching and properly handling prices from a DIA oracle, as well as as the interface based on the DIA oracle and a deployment script.
2. Assessment Summary
Halborn was provided 3 days for the engagement and assigned a full-time security engineer to review the security of the smart contracts in scope.
The purpose of the assessment is to:
Identify potential security issues within the smart contracts.
Ensure that smart contract functionality operates as intended.
In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were mostly addressed by the Azos Finance team. The main one was the following:
Change the variable to not be immutable and implement a setter function for it where the event is emitted.
3. Test Approach and Methodology
Halborn performed a manual review of the code. Manual testing is great to uncover flaws in logic, process, and implementation.
The following phases and associated tools were used throughout the term of the assessment:
Research into architecture, purpose and use of the platform.
Smart contract manual code review and walkthrough to identify any logic issue.
Thorough assessment of safety and usage of critical Solidity variables and functions in scope that could led to arithmetic related vulnerabilities.
4. RISK METHODOLOGY
4.1 EXPLOITABILITY
Attack Origin (AO):
Attack Cost (AC):
Attack Complexity (AX):
Metrics:
| 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 |
4.2 IMPACT
Confidentiality (C):
Integrity (I):
Availability (A):
Deposit (D):
Yield (Y):
Metrics:
| IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Confidentiality (C) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I: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 |
4.3 SEVERITY COEFFICIENT
Reversibility (R):
Scope (S):
Metrics:
| 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 |
5. SCOPE
- DIARelayerV2.sol
- IDIAOraclev2.sol
- Deploy.s.sol
6. Assessment Summary & Findings Overview
Critical
0
High
0
Medium
1
Low
0
Informational
2
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Inconsistency between the desired implementation and the actual implementation | Medium | Solved - 05/16/2025 |
| Floating pragma | Informational | Acknowledged - 05/16/2025 |
| Multiple unused mappings across the code | Informational | Solved - 05/16/2025 |
7. Findings & Tech Details
7.1 Inconsistency between the desired implementation and the actual implementation
//
Description
DIARelayerV2 has the following event and comment above it:
/// @notice Emitted when the stale threshold is updated
/// @param _threshold New threshold value in seconds
event NewStaleThreshold(uint256 _threshold);Whenever the staleness threshold is updated, the event must be emitted. However, there are a few issues with that. Firstly, the event is completely unused, as there is no implemented function to change the threshold at all. Secondly, the threshold is actually immutable:
uint256 public immutable STALE_THRESHOLD;This means that the staleness threshold cannot be changed even if we tried implementing a setter function for it.
BVSS
Recommendation
Consider changing the variable to not be immutable and implementing a setter function for it where the event is emitted.
Remediation Comment
SOLVED: The Azos Finance team solved the issue by implementing a function to change the stale threshold value and making the stale threshold value mutable.
Remediation Hash
7.2 Floating pragma
//
Description
The 3 in-scope files (DIARelayerV2, IDIAOraclev2, Deploy.s.sol) currently use floating pragma versions ^0.8.20 which means that the code can be compiled by any compiler version that is greater than or equal to 0.8.20, and less than 0.9.0.
However, it is recommended that contracts should be deployed with the same compiler version and flags used during development and testing. Locking the pragma helps to ensure that contracts do not accidentally get deployed using another pragma. For example, an outdated pragma version might introduce bugs that affect the contract system negatively.
BVSS
Recommendation
Consider locking the pragma version.
Remediation Comment
ACKNOWLEDGED: The contracts wouldn't compile while working on phase2 parts of development.
7.3 Multiple unused mappings across the code
//
Description
In the DIARelayerV2 contract, there are a few mappings which are never accessed and used, namely the values and timestamps mappings:
/// @notice Mapping of price feed keys to their current values
/// @dev Values are stored with 18 decimal precision
mapping(bytes32 => uint256) public values;
/// @notice Mapping of price feed keys to their last update timestamps
mapping(bytes32 => uint256) public timestamps;If these values are meant to be unused, then consider removing them from the code.
BVSS
Recommendation
Consider removing the mappings if they will not be used or alternatively change the code so they are utilized.
Remediation Comment
SOLVED: The Azos Finance team solved the issue by removing the unused mappings.
Remediation Hash
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
Azos Core
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed