Introduction
We express our gratitude to the Dirol team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Dirol is a multi-router DEX aggregator that supports complex weighted swaps across six different decentralized exchange types.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Dirol |
| Audited By | Olesia Bilenka; Kaan Caglan |
| Approved By | Ivan Bondar |
| Website | https://www.dirol.io→ |
| Changelog | 17/10/2025 - Preliminary Report |
| 31/10/2025 - Final Report | |
| Platform | Monad |
| Language | Solidity |
| Tags | Signatures; DEX |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Dirol
- Audited By
- Olesia Bilenka; Kaan Caglan
- Approved By
- Ivan Bondar
- Website
- https://www.dirol.io→
- Changelog
- 17/10/2025 - Preliminary Report
- 31/10/2025 - Final Report
- Platform
- Monad
- Language
- Solidity
- Tags
- Signatures; DEX
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/thxForu/dirol-agr→ |
| Commit | 4bb80a4 |
| Remediation Commit | 4688dda |
Review Scope
- Repository
- https://github.com/thxForu/dirol-agr→
- Commit
- 4bb80a4
- Remediation Commit
- 4688dda
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
{Finding_Table?columns=title,severity,status&setting.filter.type=Vulnerability}
Documentation quality
NatSpec is sufficient.
Technical description is provided.
Code quality
Some of the practices are not applied.
Test coverage
Code coverage of the project is 100% (branch coverage).
Deployment and basic user interactions are covered with tests.
System Overview
Dirol implements a multi-router DEX aggregator (CoreAggregator) that supports complex weighted swaps across six different decentralized exchange types, including Uniswap V2/V3, LFJ V1, ZkSwap V3, Kuru, and Crystal orderbooks. It is tightly integrated with a gasless limit order module (LimitOrderModule), which allows off-chain order signing via Permit2 and on-chain execution by authorized keepers when profitable.
The files in the scope:
1\. CoreAggregator
Type: Upgradeable, Ownable
Primary Role: Acts as the core DEX aggregator for executing complex multi-hop and multi-router swaps.
Key Features:
Supports 6 router types: Uniswap V2/V3, LFJ V1, ZkSwap V3, Kuru Orderbook, Crystal Orderbook.
Permit2 integration enables gasless token approval.
Weighted route execution with fee deduction and split routing logic.
Support for both ERC20 and native ETH input/output.
Swap Methods:
swap: Direct swap function.swapWithPermit2: Swap using a Permit2 signature.swapWithPermitted: Swap using a pre-approved Permit2 allowance.
Router Management:
setRouter/removeRouter: Owner-controlled router registry.
Fees:
Configurable via
setFeeandsetFeeReceiver(BPS-based).
Emergency:
withdrawStuckTokens: Emergency token recovery function.
2\. LimitOrderModule
Type: EIP-712 compliant limit order executor.
Primary Role: Enables off-chain signed limit orders to be executed on-chain by authorized keepers.
Key Features:
Gasless order creation using Permit2's
permitWitnessTransferFrom.Order execution through
CoreAggregatorwith fee collection.Strict input validation and reentrancy protection.
On-chain order cancellation by users (per order or all).
Fee:
10 BPS taken from output amount, sent to
feeRecipient.
Keeper Model:
Only pre-authorized addresses (set by
owner) can execute orders.
Order Tracking:
Nonce-based system to invalidate old orders.
getOrderKeyprovides unique hash of an order for identification.
PRIVILEGED ROLES
Role | Contract | Privileges |
|---|---|---|
owner | CoreAggregator | Set routers, fees, fee receiver, withdraw stuck tokens |
owner | LimitOrderModule | Authorize keepers |
keeper | LimitOrderModule | Execute limit orders on behalf of users |
Role
ownerContract
- CoreAggregator
Privileges
- Set routers, fees, fee receiver, withdraw stuck tokens
Role
ownerContract
- LimitOrderModule
Privileges
- Authorize keepers
Role
keeperContract
- LimitOrderModule
Privileges
- Execute limit orders on behalf of users
Potential Risks
Scope Definition and Security Guarantees: The audit does not cover all code in the repository. Contracts outside the audit scope may introduce vulnerabilities, potentially impacting the overall security due to the interconnected nature of smart contracts.
External DEX Integrations Out Of Audit Scope: The aggregator calls multiple third-party routers directly (Uniswap V2/V3, “LFJ V1”, ZkSwap V3, Kuru, Crystal). These contracts and their ABIs/semantics are not in scope, so interaction correctness, safety, and invariants are not guaranteed.
Interactions with External DeFi Protocols: Dependence on external DeFi protocols inherits their risks and vulnerabilities. This might lead to direct financial losses if these protocols are exploited, indirectly affecting the audited project.
Absence of Time-lock Mechanisms for Critical Operations: Without time-locks on critical operations, there is no buffer to review or revert potentially harmful actions, increasing the risk of rapid exploitation and irreversible changes.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1350 | Native Input Routed as Zero for Native-Send Routes | fixed | Critical | |
| F-2025-1354 | Improper Weight Reset on tokenIn Change Allows Bypassing MAX_WEIGHT Cap | fixed | High | |
| F-2025-1352 | Missing Check for Residual Input Tokens When Route Weights Are Incomplete | fixed | High | |
| F-2025-1359 | ZkSwap Router Mismatch: Calls Non-Existent exactInputSingle On Monad | fixed | High | |
| F-2025-1356 | Weights Misapplied When Routes Are Not Grouped By TokenIn | fixed | High | |
| F-2025-1350 | Native Balance Sweep via Absolute Balance on NATIVE Legs | fixed | High | |
| F-2025-1353 | Double Fee Charged in Limit Order Execution Due to Aggregator Fee Overlap | fixed | Medium | |
| F-2025-1355 | Unvalidated Market Address Leads To Arbitrary Token Approvals | fixed | Medium | |
| F-2025-1350 | Output Accounting Uses Absolute Balance | fixed | Medium | |
| F-2025-1351 | Unlimited ERC20 Approval to Aggregator | 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/thxForu/dirol-agr→ |
| Commit | 4bb80a4f568a1cd8a66068c7b965ee15f7241e5f |
| Remediation Commit | 4688ddad657eeac9f141139cd08b3167fb784ec8 |
| Whitepaper | N/A |
| Requirements | https://github.com/thxForu/dirol-agr/README.md→ |
| Technical Requirements | https://github.com/thxForu/dirol-agr/README.md→ |
Scope Details
- Repository
- https://github.com/thxForu/dirol-agr→
- Commit
- 4bb80a4f568a1cd8a66068c7b965ee15f7241e5f
- Remediation Commit
- 4688ddad657eeac9f141139cd08b3167fb784ec8
- Whitepaper
- N/A
- Requirements
- https://github.com/thxForu/dirol-agr/README.md→
- Technical Requirements
- https://github.com/thxForu/dirol-agr/README.md→
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.