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 |
| 02/07/2026 - Second Report | |
| 15/07/2026 - Third Report | |
| 31/08/2026 - Fourth Report | |
| 14/09/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
- 02/07/2026 - Second Report
- 15/07/2026 - Third Report
- 31/08/2026 - Fourth Report
- 14/09/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 |
| Second Commit | ef0df2a9caa604fd985c1db27f1437f10bba6f11 |
| Third Commit | 4e8b1816a38d3390bbd34bfa98623fabd9f9cb1d |
| Fourth Commit | 9fe0ed4ecc62cb2e0874eb242bef412835bd8402 |
| Final Commit | 077587d8a6c39ea6477a98709ae571d32950b035 |
Review Scope
- Initial Commit
- fbabb4246ae6d7781c54dd67714cd1741b8212b1
- Second Commit
- ef0df2a9caa604fd985c1db27f1437f10bba6f11
- Third Commit
- 4e8b1816a38d3390bbd34bfa98623fabd9f9cb1d
- Fourth Commit
- 9fe0ed4ecc62cb2e0874eb242bef412835bd8402
- Final Commit
- 077587d8a6c39ea6477a98709ae571d32950b035
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 that deploys vault instances. It manages approved trading pairs (including Liquidity Book, Blackhole, Pharaoh, and Uniswap V3 route data), fee settings (management and performance fees in basis points), a global trader Merkle root for authorization, and a registry of all created vaults. Vault creation and bond issuance are done atomically through this contract.
DualTokenVault — core vault that runs the full bond lifecycle across three states: BOND_ISSUANCE, TRADING, and SETTLED. At issuance, a user deposits a vault token (e.g. AVAX) and a stable token (e.g. USDC), with the stable amount set via a Chainlink oracle and reserve ratio. During trading, an authorized protocol trader swaps between the two tokens through integrated DEX adapters. At maturity, the bond is redeemed: performance fees are taken from profit (oracle-aware when possible), and remaining balances go back to the redeemer.
LiquidityBookSwap — abstract swap adapter for Trader Joe’s Liquidity Book. Supports single-hop and multi-hop paths with configurable bin steps and versions, and handles native token flows.
BlackholeSwap — abstract swap adapter for the Blackhole DEX. Supports route-based single-hop and multi-hop swaps, stable/volatile pool selection, and native token handling.
PharaohSwap — abstract swap adapter for Pharaoh’s concentrated-liquidity router. Uses packed paths with tick spacing and supports native input via msg.value.
UniswapV3Swap — abstract swap adapter for Uniswap V3. Uses packed paths with fee tiers, enforces deadlines via multicall, and wraps/unwraps native through the wrapped native token for ERC20 router calls.
SwapBase — shared base for DEX adapters. Holds the vault token pair, wrapped native address, and common helpers for balance checks and token validation.
VaultReceiptToken — ERC1155 bond receipt. Minted to the depositor at issuance and burned on redemption.
BondMarketplace — ERC1155 marketplace for bond receipt tokens. Sellers escrow receipts and set a variable-token price; the stable leg is taken from the vault’s starting stable balance. Buyers pay variable token (plus marketplace cut) and stable token; private sales can restrict the buyer address.
ERC1155MarketplaceBase — abstract ERC1155 marketplace core used by BondMarketplace. Holds approved token sets (ERC1155, trade token, stable token), listing storage and indexes, the marketplace cut in basis points, and the fee recipient. It escrows and transfers receipts, settles native or ERC20 payments (sale price to the seller plus cut to the fee recipient), and exposes moderator controls to replace or clear token sets and to update the fee recipient. Listing create, purchase, and cancel are abstract and implemented by the concrete marketplace.
MerkleTreeHelper — library for Merkle proofs used to check authorized traders against the factory’s global Merkle root.
FeeTypes — shared fee-type definitions used when emitting fee collection events (e.g. bond management, performance, and marketplace fees).
Privileged roles
DEFAULT_ADMIN_ROLE on the factory can grant and revoke other roles, including
MODERATOR_ROLE. Assigned to the deployer at construction.MODERATOR_ROLE on the factory can update fee parameters (management and performance fees), set the fee splitter address, update the trader Merkle root (affects all active vaults), and manage approved trading pairs (including all DEX route configs).
MINTER_ROLE on
VaultReceiptTokenis granted to the factory (and used so vaults/factory can mint receipts at issuance).MODERATOR_ROLE on
BondMarketplacecan update approved marketplace token sets and the marketplace fee recipient address.DEFAULT_ADMIN_ROLE on ERC1155MarketplaceBase (inherited by BondMarketplace) can grant and revoke other marketplace roles, including MODERATOR_ROLE. Assigned to the deployer at construction.
Potential Risks
The Liquidity Book, Blackhole, Pharaoh, and Uniswap V3 routers are external DEX contracts (forks or third-party periphery). Their security and correct behavior are outside this audit’s scope. 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.
Marketplace listings freeze the stable payment as the vault’s startingStableTokenBalance at list time, not the vault’s current balances. After trading, the buyer still pays that fixed stable amount while the bond’s redeemable vault assets may differ, so listing price and vault value can diverge.
Creating a listing escrows the ERC-1155; purchase and cancel are the only exits. The ERC-1155 receiver callbacks always accept transfers, and the contract accepts ETH. Tokens or native sent directly, or listings that can no longer be removed, remain in the contract with no admin sweep.
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-1895 | Missing Active Listing Index Update During Removal Permanently Locks Escrowed Bond Receipts | 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-1895 | Missing Native Unwrap in _pharaohCLSwapExactInput Causes Stuck WAVAX on Native Vaults | fixed | Medium |
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 |
| Second Commit | ef0df2a9caa604fd985c1db27f1437f10bba6f11 |
| Third Commit | 4e8b1816a38d3390bbd34bfa98623fabd9f9cb1d |
| Fourth Commit | 9fe0ed4ecc62cb2e0874eb242bef412835bd8402 |
| Final Commit | 077587d8a6c39ea6477a98709ae571d32950b035 |
| Whitepaper | N/A |
| Requirements | N/A |
| Technical Requirements | N/A |
Scope Details
- Initial Commit
- fbabb4246ae6d7781c54dd67714cd1741b8212b1
- Second Commit
- ef0df2a9caa604fd985c1db27f1437f10bba6f11
- Third Commit
- 4e8b1816a38d3390bbd34bfa98623fabd9f9cb1d
- Fourth Commit
- 9fe0ed4ecc62cb2e0874eb242bef412835bd8402
- Final Commit
- 077587d8a6c39ea6477a98709ae571d32950b035
- 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.