Audit name:
[dAPP] DreamX | HODLBonds | mar2026
Date:
Apr 24, 2026
Table of Content
Introduction
We express our gratitude to the DreamX team for the collaborative engagement that enabled the execution of this dApp Security Assessment.
HODLBonds is a DeFi protocol where users deposit token pairs into vaults, and the protocol's trader swaps between them.
Document | |
|---|---|
| Name | dApp Code Review and Security Analysis Report for DreamX |
| Audited By | Bogdan Bodisteanu |
| Approved By | Ece Orsel |
| Website | https://hodlbonds.io/→ |
| Changelog | 26/03/2026 - Preliminary Report, 27/03/2026 - Final Report. |
| Platform | dApp |
| Language | TypeScript, Docker |
| Tags | dApp Audit |
| Methodology | https://docs.hacken.io/methodologies/dapp-audit-methodology→ |
Document
- Name
- dApp Code Review and Security Analysis Report for DreamX
- Audited By
- Bogdan Bodisteanu
- Approved By
- Ece Orsel
- Website
- https://hodlbonds.io/→
- Changelog
- 26/03/2026 - Preliminary Report, 27/03/2026 - Final Report.
- Platform
- dApp
- Language
- TypeScript, Docker
- Tags
- dApp Audit
Review Scope | |
|---|---|
| Repository | https://github.com/DreamX-Development/hodlbonds-blockchain-executor→ |
| Commit | 35c049a (main branch) |
| Repository | https://github.com/DreamX-Development/hodlbonds-api→ |
| Commit | e8b188c (main branch) |
Review Scope
- Commit
- 35c049a (main branch)
- Commit
- e8b188c (main branch)
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
{FindingsVulnSeverityStatusTable}
System Overview
HodlBonds System ├── API & Backend (hodlbonds-api-main) │ ├── Apps (microservices) │ │ ├── intake │ │ │ ├── adapters (Alchemy integration) │ │ │ ├── handlers (on-chain event processors) │ │ │ ├── lib │ │ │ │ ├── event-decoder │ │ │ │ ├── event-router │ │ │ │ ├── replay / ingestion logic │ │ │ │ └── signature validation │ │ │ ├── services (webhook handling) │ │ │ └── types │ │ │ │ │ ├── price-oracle │ │ │ ├── fetch-prices │ │ │ └── record-prices │ │ │ │ │ ├── public-api │ │ │ ├── routers (bonds, listings) │ │ │ ├── services │ │ │ │ ├── bonds │ │ │ │ └── listings │ │ │ ├── schemas │ │ │ └── utils │ │ │ │ │ ├── server │ │ │ ├── routers (token metadata) │ │ │ ├── services (token logic) │ │ │ └── schemas / utils │ │ │ │ │ └── trading-api │ │ ├── middleware (auth, validators) │ │ ├── routers │ │ │ ├── orders / vaults / time │ │ │ └── internal (order status) │ │ ├── services │ │ │ ├── DEX integrations │ │ │ │ ├── Uniswap v4 │ │ │ │ ├── LFJ / Blackhole │ │ │ │ └── Oracle │ │ │ ├── order management │ │ │ ├── vault logic │ │ │ └── DB access │ │ └── scripts (deploy, mint, trade) │ │ │ ├── Shared Packages │ │ ├── blockchain │ │ │ ├── contracts (ABIs + instances) │ │ │ ├── clients │ │ │ ├── networks │ │ │ └── tokens (ERC20 utils, mocks) │ │ │ │ │ ├── db │ │ │ ├── schema │ │ │ └── types (bigint, swap data) │ │ │ │ │ ├── env (service configs) │ │ └── config (tsconfig base) │ │ │ └── Infra │ ├── Dockerfiles per service │ ├── CloudBuild configs │ └── pnpm monorepo │ ├── Execution Layer (hodlbonds-blockchain-executor-main) │ ├── Apps │ │ ├── executor │ │ │ ├── Core │ │ │ │ ├── ExecutionManager │ │ │ │ ├── ExecutorAbstract / Factory │ │ │ │ └── ExecutionResult │ │ │ │ │ │ │ ├── Wallet System │ │ │ │ ├── Wallet │ │ │ │ └── WalletManager │ │ │ │ │ │ │ ├── Strategies / Implementations │ │ │ │ ├── DcaBot │ │ │ │ └── HodlBondsTrade │ │ │ │ │ │ │ ├── MerkleTreeManager (batching / proofs) │ │ │ ├── DatabaseProvider │ │ │ └── Utils (Queue, Serialize, Timeout) │ │ │ │ │ └── intake │ │ ├── Intake (message consumer) │ │ ├── MessageFactory │ │ ├── DatabaseProvider │ │ └── utils (canonicalization) │ │ │ ├── Shared Packages │ │ ├── client │ │ │ ├── BlockchainExecutorClient │ │ │ ├── TradingApiClient │ │ │ └── HodlBondsTradeClient │ │ │ │ │ ├── database │ │ │ ├── SQL migrations (Drizzle) │ │ │ └── schema │ │ │ │ │ └── dto │ │ ├── message schemas │ │ ├── task models │ │ └── bot models (DCA, HodlBonds) │ │ │ └── Deployment │ ├── docker-compose (main / stage) │ ├── init scripts │ └── cloudbuild configs │ └── System Flow ├── 1. Blockchain Events │ → intake (API repo) │ → decode + route events │ ├── 2. Data Processing │ → handlers update DB │ → price-oracle updates pricing │ ├── 3. API Layer │ → public-api (read) │ → trading-api (write / actions) │ ├── 4. Execution Pipeline │ → messages sent to executor │ → executor selects strategy (DCA / bonds) │ → executes on-chain transactions │ └── 5. Feedback Loop → execution results stored → exposed via APIs
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-1538 | Unauthenticated Administrative Debug Endpoints | fixed | Critical | |
| F-2026-1540 | Race Condition in Order Processing Leads to Inconsistent State and Potential Data Loss | fixed | High | |
| F-2026-1539 | Authentication Bypass via Replay Attack (Broken HMAC Middleware) | fixed | High | |
| F-2026-1540 | Plaintext Storage of Master Seed Phrase in Filesystem | fixed | High | |
| F-2026-1539 | Authentication Bypass on Internal Endpoints in Non-Production Environments | fixed | Medium | |
| F-2026-1539 | Observable Timing Discrepancy in Webhook Signature Validation | fixed | Low | |
| F-2026-1539 | Missing Blockchain Transaction Receipt Status Validation | fixed | Observation | |
| F-2026-1538 | Potential SQL Injection via Unparameterized sql.raw() Usage | fixed | Observation | |
| F-2026-1540 | Use of Cryptographically Weak Hash Algorithm (SHA-1) | fixed | Observation |
Appendix 1. Severity Definitions
Findings are categorized based on their potential impact and assigned a severity level using the Common Vulnerability Scoring System (CVSS) version 4.0: →
Severity | Description |
|---|---|
Critical | These issues present a major security vulnerability that poses a severe risk to the system. They require immediate attention and must be resolved to prevent a potential security breach or other significant harm. |
High | These issues present a significant risk to the system, but may not require immediate attention. They should be addressed in a timely manner to reduce the risk of the potential security breach. |
Medium | These issues present a moderate risk to the system and cannot have a great impact on its function. They should be addressed in a reasonable time frame, but may not require immediate attention. |
Low | These issues present no risk to the system and typically relate to the code quality problems or general recommendations. They do not require immediate attention and should be viewed as a minor recommendation. |
Severity
- Critical
Description
- These issues present a major security vulnerability that poses a severe risk to the system. They require immediate attention and must be resolved to prevent a potential security breach or other significant harm.
Severity
- High
Description
- These issues present a significant risk to the system, but may not require immediate attention. They should be addressed in a timely manner to reduce the risk of the potential security breach.
Severity
- Medium
Description
- These issues present a moderate risk to the system and cannot have a great impact on its function. They should be addressed in a reasonable time frame, but may not require immediate attention.
Severity
- Low
Description
- These issues present no risk to the system and typically relate to the code quality problems or general recommendations. They do not require immediate attention and should be viewed as a minor recommendation.
Appendix 2. Scope
The scope of the project includes the following:
Scope Details | |
|---|---|
| Repository | https://github.com/DreamX-Development/hodlbonds-blockchain-executor→ |
| Commit | 35c049a (main branch) |
| Repository | https://github.com/DreamX-Development/hodlbonds-api→ |
| Commit | e8b188c (main branch) |
Scope Details
- Commit
- 35c049a (main branch)
- Commit
- e8b188c (main branch)
Assets in Scope
Appendix 3. Additional Valuables
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 →, the Penetration Testing Execution Standard (PTES) →, and the OWASP Testing Guide →. 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.