Prepared by:
HALBORN
Last Updated 12/03/2025
Date of Engagement: October 31st, 2025 - November 6th, 2025
100% of all REPORTED Findings have been addressed
All findings
9
Critical
0
High
0
Medium
0
Low
2
Informational
7
Deploy Finance engaged Halborn to conduct a security assessment on their smart contracts beginning on October 31st, 2025 and ending on November 6th, 2025. The security assessment was scoped to the smart contracts provided in the Deploy Finance Github repository, provided to the Halborn team. Commit hash and further details can be found in the Scope section of this report.
The reviewed contracts implement minting, redemption, and staking of the dUSD stablecoin, featuring per-asset mint/redeem limits, support for multiple signature types, and stable-specific validation mechanisms.
Halborn was provided with 5 days for this engagement and assigned a full-time security engineer to assess the security of the smart contracts in scope. The assigned engineer possess deep expertise in blockchain and smart contract security, including hands-on experience with multiple blockchain protocols.
The objective of this assessment is to:
Identify potential security issues within the Deploy Finance protocol smart contracts.
Ensure that smart contract of ````Deploy Finance protocol functions operate as intended.
In summary, Halborn identified several areas for improvement to reduce the likelihood and impact of security risks, which were partially addressed by the Deploy Finance team. The main ones were:
Modify the ORDER_TYPE string to match the field types in the Order struct to prevent signature verification failures.
Include the full 128 bits of the nonce in order verification to prevent nonce collisions and order rejection.
Halborn performed a combination of manual review of the code and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to 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 coverage of smart contracts and 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 and purpose of the Deploy Finance protocol.
Manual code review and walkthrough of the Deploy Finance in-scope contracts.
Manual assessment of critical Solidity variables and functions to identify potential vulnerability classes.
Manual testing using custom scripts.
Static Analysis of security for scoped contract, and imported functions. (Slither).
Local deployment and testing with (Foundry, Remix IDE).
| 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
0
Low
2
Informational
7
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Nonce truncation causes potential nonce collisions and order rejection | Low | Solved - 11/23/2025 |
| Mismatch between Order struct definition and its EIP-712 type string breaks signature verification | Low | Solved - 11/23/2025 |
| Lack of per-stable configuration may enable depegged stable exploitation | Informational | Acknowledged - 11/28/2025 |
| Missing minimum output enforcement leads to silent value loss for users | Informational | Acknowledged - 11/28/2025 |
| Centralized control over minting and redemption introduces trust risk | Informational | Acknowledged - 11/26/2025 |
| Ineffective staker restriction mechanism enables indirect deposits | Informational | Acknowledged - 11/27/2025 |
| Blacklist role updates may silently fail due to unchecked results | Informational | Acknowledged - 11/28/2025 |
| Dust donation can lock StakedDUSD deposits permanently | Informational | Acknowledged - 11/28/2025 |
| Non-standard ERC-20 tokens are not supported | Informational | Acknowledged - 11/28/2025 |
//Low
//Low
//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
StakedDUSD
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
