The Hacken 2025 TRUST ReportKey findings on trust, security maturity, and the factors driving blockchain adoption.
Learn more

Audit name:

[SCA] Dirol | Dirol-Agr | Oct2025

Date:

Oct 31, 2025

Table of Content

Introduction
Audit Summary
System Overview
Potential Risks
Findings
Appendix 1. Definitions
Appendix 2. Scope
Appendix 3. Additional Valuables
Disclaimer

Want a comprehensive audit report like this?

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

NameSmart Contract Code Review and Security Analysis Report for Dirol
Audited ByOlesia Bilenka; Kaan Caglan
Approved ByIvan Bondar
Websitehttps://www.dirol.io
Changelog17/10/2025 - Preliminary Report
31/10/2025 - Final Report
PlatformMonad
LanguageSolidity
TagsSignatures; DEX
Methodologyhttps://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
    Changelog
    17/10/2025 - Preliminary Report
    31/10/2025 - Final Report
    Platform
    Monad
    Language
    Solidity
    Tags
    Signatures; DEX

Review Scope

Repositoryhttps://github.com/thxForu/dirol-agr
Commit4bb80a4
Remediation Commit4688dda

Audit Summary

34Total Findings
33Resolved
0Accepted
1Mitigated

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 setFee and setFeeReceiver (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 CoreAggregator with 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.

  • getOrderKey provides unique hash of an order for identification.

PRIVILEGED ROLES

Role

Contract

Privileges

ownerCoreAggregatorSet routers, fees, fee receiver, withdraw stuck tokens
ownerLimitOrderModuleAuthorize keepers
keeperLimitOrderModuleExecute limit orders on behalf of users
  • Role

    owner

    Contract

    CoreAggregator

    Privileges

    Set routers, fees, fee receiver, withdraw stuck tokens

    Role

    owner

    Contract

    LimitOrderModule

    Privileges

    Authorize keepers

    Role

    keeper

    Contract

    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-1350Native Input Routed as Zero for Native-Send Routes
fixed

Critical
F-2025-1354Improper Weight Reset on tokenIn Change Allows Bypassing MAX_WEIGHT Cap
fixed

High
F-2025-1352Missing Check for Residual Input Tokens When Route Weights Are Incomplete
fixed

High
F-2025-1359ZkSwap Router Mismatch: Calls Non-Existent exactInputSingle On Monad
fixed

High
F-2025-1356Weights Misapplied When Routes Are Not Grouped By TokenIn
fixed

High
F-2025-1350Native Balance Sweep via Absolute Balance on NATIVE Legs
fixed

High
F-2025-1353Double Fee Charged in Limit Order Execution Due to Aggregator Fee Overlap
fixed

Medium
F-2025-1355Unvalidated Market Address Leads To Arbitrary Token Approvals
fixed

Medium
F-2025-1350Output Accounting Uses Absolute Balance
fixed

Medium
F-2025-1351Unlimited ERC20 Approval to Aggregator
fixed

Low
1-10 of 34 findings

Identify vulnerabilities in your smart contracts.

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

Repositoryhttps://github.com/thxForu/dirol-agr
Commit4bb80a4f568a1cd8a66068c7b965ee15f7241e5f
Remediation Commit4688ddad657eeac9f141139cd08b3167fb784ec8
WhitepaperN/A
Requirementshttps://github.com/thxForu/dirol-agr/README.md
Technical Requirementshttps://github.com/thxForu/dirol-agr/README.md

Assets in Scope

src
CoreAggregator.sol - src › CoreAggregator.sol
limit-orders
LimitOrderModule.sol - src › limit-orders › LimitOrderModule.sol

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.

Disclaimer