Audit name:
[SCA] DreamX | HODLBonds | mar2026
Date:
Apr 1, 2026
Table of Content
Introduction
We express our gratitude to the Drteam for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
HODLBonds is a DeFi protocol where users deposit token pairs into vaults, and the protocol's trader swaps between them.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for DreamX |
| Audited By | Seher Saylik, Kerem Solmaz |
| Approved By | Kornel Światłowski |
| Website | https://hodlbonds.io/→ |
| Changelog | 18/03/2026 - Preliminary Report |
| 16/04/2026 - Final Report | |
| Platform | Avalanche chain |
| Language | Solidity |
| Tags | DeFi, Vault |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for DreamX
- Audited By
- Seher Saylik, Kerem Solmaz
- Approved By
- Kornel Światłowski
- Website
- https://hodlbonds.io/→
- Changelog
- 18/03/2026 - Preliminary Report
- 16/04/2026 - Final Report
- Platform
- Avalanche chain
- Language
- Solidity
- Tags
- DeFi, Vault
Review Scope | |
|---|---|
| Repository | https://github.com/DreamX-Development/hodl-bonds-contracts→ |
| Initial Commit | fbabb4246ae6d7781c54dd67714cd1741b8212b1 |
| Final Commit | ef0df2a9caa604fd985c1db27f1437f10bba6f11 |
Review Scope
- Initial Commit
- fbabb4246ae6d7781c54dd67714cd1741b8212b1
- Final Commit
- ef0df2a9caa604fd985c1db27f1437f10bba6f11
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are partially missed.
Technical description is provided.
Code quality
Best practices were applied.
The development environment is configured.
Test coverage
Code coverage of the project is 35.59% (branch coverage).
Negative cases and edge conditions, such as boundary parameter values, non-standard token decimals, failed transfers, and oracle error handling, are largely missed.
DEX behavior in SwapBase, LiquidityBookSwap, and BlackholeSwap is only partially validated; fork tests are provided, but coverage still leans on simplified assumptions/mocks and doesn’t comprehensively exercise router-specific revert/encoding/slippage/approval corner cases.
Access control, factory configuration setters, and multi-user interaction scenarios are not tested thoroughly.
System Overview
HODL Bonds is a dual-token bond protocol on Avalanche with the following contracts:
DualTokenVaultFactory — factory contract that deploys vault instances. It manages approved trading pairs, fee configurations (management and performance fees in basis points), a global trader Merkle root for authorization, and maintains a registry of all created vaults. Vault creation and bond issuance are performed atomically through this contract.
DualTokenVault — core vault contract that handles the complete bond lifecycle across three states: BOND_ISSUANCE, TRADING, and SETTLED. During issuance, a user deposits a vault token (e.g., AVAX) and a stable token (e.g., USDC) calculated via a Chainlink oracle and reserve ratio. During the trading period, an authorized protocol trader swaps between the two tokens via integrated DEX protocols. At maturity, the bond is redeemed — performance fees are deducted from any vault token profit, and remaining balances are returned to the redeemer.
LiquidityBookSwap — abstract contract providing swap functionality through Trader Joe's Liquidity Book protocol. Supports single-hop and multi-hop swaps with configurable bin steps and versions, and handles native token wrapping/unwrapping.
BlackholeSwap — abstract contract providing swap functionality through the Blackhole (Solidly/Velodrome-style) DEX protocol. Supports route-based single-hop and multi-hop swaps with configurable pair addresses, stable/volatile pool selection, and native token handling.
VaultReceiptToken — ERC1155 token that serves as a bond receipt. Minted to the depositor at bond issuance and burned upon redemption.
PaymentSplitterUpgradeable — upgradeable contract for splitting fee payments among multiple payees according to predefined shares in basis points. Distributes both ERC20 tokens and native currency.
MerkleTreeHelper — library for Merkle tree operations used to verify authorized traders via proof verification against a global Merkle root stored in the factory.
Privileged roles
The
DEFAULT_ADMIN_ROLEon the factory can grant and revoke all other roles, includingMODERATOR_ROLE. This role is assigned to the deployer at construction.The
MODERATOR_ROLEon the factory can update fee parameters (management and performance fees without upper bounds), set the fee splitter address, update the trader Merkle root affecting all active vaults, and manage approved trading pairs.The
MINTER_ROLEon the VaultReceiptToken is granted to the factory deployer and to each newly created vault, allowing them to mint receipt tokens.The
MODERATOR_ROLEon the PaymentSplitter can update payee addresses and share allocations at any time, including while funds are pending distribution.
Potential Risks
The Blackhole and Liquidity Book routers are modified forks of Uniswap V2/Solidly with non-standard extensions to their routing logic and parameter handling, and their security and correct implementation fall outside the scope of this audit. Any vulnerabilities, behavioral changes, or administrative actions within these external router contracts could directly impact the safety of funds held in DualTokenVault instances.
A single moderator key can instantly halt all trading across every active vault in the protocol by updating or misconfiguring the global Merkle root, invalidating all existing trader proofs and locking authorized traders out of all vaults until a correct root and new proofs are distributed off-chain.
Swap routes and paths are hardcoded at vault creation and cannot be updated during the trading period. If liquidity migrates to different pools or the configured pools become illiquid, the trader is locked into suboptimal or non-functional routes with no mechanism to adapt, potentially degrading trading performance or preventing swaps entirely.
All DualTokenVault instances are EIP-1167 minimal proxies that permanently delegatecall to the implementation address set at factory construction. If a critical vulnerability is discovered in the vault implementation after deployment, existing vaults cannot be patched — the implementation address is baked into each proxy’s bytecode at creation. New vaults can be directed to a corrected implementation via a new factory, but funds held in the existing vault fleet have no upgrade or recovery path.
Bond issuance pricing depends entirely on Chainlink price feeds. If a configured feed is deprecated, removed, or Chainlink service is interrupted on Avalanche C-Chain, all new bond issuance for affected trading pairs becomes permanently blocked. Since oracle addresses are set at pair configuration time and are not-updateable per vault after initialization, existing vaults that rely on a deprecated feed cannot switch to an alternative source without redeployment.
The protocol has no emergency mechanism to halt trading or redemption during an exploit or incident. Governance can stop new vault creation by removing approved pairs in DualTokenVaultFactory, but it cannot freeze state-changing operations for existing vaults while a fix is prepared.
The vault's oracle configuration fetches only the vault token price in USD (e.g., AVAX/USD) and implicitly assumes the stable token maintains a 1:1 USD peg. No secondary oracle validates the stable token's actual market price. If the stable token depegs, the reserve calculation at bond issuance and the performance fee calculation at settlement will both operate on incorrect valuations, potentially underfunding reserves or mischarging performance fees proportional to the magnitude of the depeg.
The payment splitter uses a push-based distribution that pays all recipients in one transaction. If any recipient cannot receive funds (reverts) or a token transfer fails (e.g., blacklist/paused/non-standard token), the entire payout reverts and blocks distribution for everyone until the recipient list is updated.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-1537 | Hardcoded Receiver Field Breaks Native Token Output and Multi-Hop Swap Paths | fixed | High | |
| F-2026-1536 | Bidirectional Swaps Broken | fixed | High | |
| F-2026-1536 | Redundant Native Token Unwrap Causes Revert on Token-to-ETH Swap Path | fixed | High | |
| F-2026-1544 | Incorrect Unit Comparison In Bond Minimum Price Validation | fixed | Medium | |
| F-2026-1542 | Performance Fee Can Be Minimized Through Unvalidated bondPrice and One-Sided Fee Calculation | mitigated | Medium | |
| F-2026-1542 | Arithmetic Underflow in _convertTokenAmount Prevents Vault Creation for Certain Token Decimal Combinations | fixed | Medium | |
| F-2026-1539 | Failed Token Transfer in Settlement Permanently Locks All Vault Funds | mitigated | Medium | |
| F-2026-1537 | Insufficient Chainlink Oracle Validation Allows Stale Price Usage | fixed | Medium | |
| F-2026-1543 | No Supply Cap Per Token ID in VaultReceiptToken — Duplicate Receipt Minting Possible | fixed | Low | |
| F-2026-1542 | Missing SafeERC20 Usage for Token Transfers | fixed | Low |
Appendix 1. Definitions
Severities
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. |
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.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/DreamX-Development/hodl-bonds-contracts→ |
| Initial Commit | fbabb4246ae6d7781c54dd67714cd1741b8212b1 |
| Final Commit | ef0df2a9caa604fd985c1db27f1437f10bba6f11 |
| Whitepaper | N/A |
| Requirements | N/A |
| Technical Requirements | N/A |
Scope Details
- Initial Commit
- fbabb4246ae6d7781c54dd67714cd1741b8212b1
- Final Commit
- ef0df2a9caa604fd985c1db27f1437f10bba6f11
- Whitepaper
- N/A
- Requirements
- N/A
- Technical Requirements
- N/A
Assets in Scope
Appendix 3. Additional Valuables
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.
Frameworks and Methodologies
This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.