The Hacken 2025 Yearly Security ReportCovers major Web3 breaches, their root causes, prevention insights, and key regulatory trends for 2026.
Learn more

Audit name:

[SCA] Dexlyn | Perp Dex | Jul2025

Date:

Sep 23, 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 Dexlyn team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

The Dexlyn Perpetual DEX is a sophisticated decentralized derivatives trading platform built on the Supra blockchain using the Move programming language. This project enables users to trade perpetual futures contracts with leverage, providing advanced trading features including market and limit orders, stop-loss/take-profit mechanisms, automated liquidations, and real-time price oracle integration. The system consists of comprehensive Move smart contracts handling trading logic, position management, fee distribution, house liquidity provision, and risk management, supported by a high-performance Rust-based keeper service that monitors blockchain events and executes orders when market conditions are met.

Document

NameSmart Contract Code Review and Security Analysis Report for Dexlyn
Audited ByAtaberk Yavuzer, Turgay Arda Usman
Approved ByIvan Bondar
Websitehttps://docs.dexlyn.com
Changelog28/08/2025 - Preliminary Report
23/09/2025 - Final Report
PlatformSupra
LanguageMove
TagsOrderbook, Perpetual DEX, Prediction Market
Methodologyhttps://hackenio.cc/sc_methodology
  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Dexlyn
    Audited By
    Ataberk Yavuzer, Turgay Arda Usman
    Approved By
    Ivan Bondar
    Changelog
    28/08/2025 - Preliminary Report
    23/09/2025 - Final Report
    Platform
    Supra
    Language
    Move
    Tags
    Orderbook, Perpetual DEX, Prediction Market

Review Scope

Repositoryhttps://github.com/DexlynLabs/dexlyn_perp_dex
Initial Commit6feeaaa2b1bd9bb4be97469c045cd72e0431ad96
Final Commit4dcc4c3cff517afc1f6c158f7ddbf903906747de

Audit Summary

19Total Findings
14Resolved
4Accepted
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

  • Functional requirements are partially provided.

    • Use cases are not provided.

    • Infrastructural assumptions and expected behavior are not provided.

  • Technical description is  partially provided.

    • Key function descriptions are not provided

Code quality

  • The code mostly follows style guides and best practices.

    • See informational findings for more details.

  • The development environment is configured.

System Overview

The Dexlyn Perpetual DEX is a Move-based service that serves as a critical component in the Dexlyn perpetual trading platform. It continuously monitors the blockchain for trading events, executes market and limit orders when market conditions are met, manages stop-loss and take-profit triggers, and handles position liquidations. It contains the following contracts:

  • trading.move — Manages the core trading logic for perpetual swaps, including creating orders, managing positions, and handling liquidations.

  • fee_distributor.move — Distributes fees collected from trading activities to various stakeholders, including liquidity providers and the development fund.

  • price_oracle.move — Provides reliable and up-to-date price feeds for assets, crucial for executing trades and liquidations at accurate prices.

  • trading_calc.move — Contains all the complex mathematical calculations required for trading, such as profit and loss (PnL), price impact, and funding rates.

  • capability.move — Manages access control and permissions, defining what actions different accounts or contracts are authorized to perform.

  • delegate_account.move — Allows users to delegate trading authority to another account, enabling features like copy trading or managed accounts.

  • vault.move — Securely holds user funds and assets required for various operations within the decentralized exchange.

  • house_lp.move — Manages the liquidity provided by the "house," enabling it to act as the counterparty to all trades on the platform.

  • blocked_user.move — Maintains a list of blocked users who are restricted from interacting with the protocol.

  • coin_utils.move—Provides utility functions for handling different coin types and converting between coins and fungible assets.

  • safe_math.move — Implements safe mathematical operations to prevent overflow and underflow errors in calculations.

  • supra_oracle_pull.move — Interacts with the Supra Oracle to pull price data by verifying oracle proofs.

  • supra_oracle_storage.move — Stores and provides access to the price feed data obtained from the Supra Oracle.

  • managed_trading.move — Provides entry functions to interact with the trading module, allowing users to place and manage their trading orders and positions.

  • managed_vault.move — Exposes the entry function to register a new vault type within the vault module.

  • managed_house_lp.move — Contains entry functions for liquidity providers to interact with the house_lp module, such as depositing and withdrawing liquidity.

  • managed_price_oracle.move — Exposes entry functions for managing and interacting with the price_oracle module, including updating prices and configuring oracle parameters.

  • managed_fee_distributor.move — Provides entry functions for the admin to configure and manage the fee distribution settings in the fee_distributor module.

  • managed_delegate_account.move — Exposes entry functions for users to manage their delegate accounts through the delegate_account module.

  • managed_capability.move — Provides entry functions for managing capabilities and permissions for different accounts within the protocol.

Privileged roles

  • The owner of the trading contract can arbitrarily modify critical trading parameters such as fees, leverage limits, and open interest caps, and is therefore entitled to control the fundamental risk and financial model of the exchange at will.

  • The owner of the vault contract can register new vaults for different asset types, and is therefore entitled to control which assets are supported for collateral, liquidity, and fee payments within the system.

  • The owner of the house_lp contract can arbitrarily modify deposit fees, withdrawal fees, and risk parameters for the liquidity pool, and is therefore entitled to control the profitability and risk exposure of liquidity providers in the system

  • The owner of the price_oracle contract can arbitrarily set price feed configurations and authorize which addresses can update asset prices, and is therefore entitled to control the source of truth for asset valuation, a critical component for liquidations and trade execution.

  • The owner of the fee_distributor contract can arbitrarily modify fee distribution weights and withdraw accumulated fees, and is therefore entitled to control the allocation of protocol revenue at will.

  • The owner of the capability contract can arbitrarily grant powerful permissions to other accounts to act as system executors, and is therefore entitled to control which external actors can perform critical system functions like executing orders.

  • The owner of the blocked_user contract can arbitrarily add or remove any address from the contract's blacklist, and is therefore entitled to censor any user and prevent them from interacting with the protocol at will.

  • The executor role can:

    • execute market and limit orders

    • trigger stop-loss/take-profit positions

    • perform liquidations

    • update price oracle data

Potential Risks

The implemented price oracle logic highly depends on external contracts not covered by the audit. This reliance introduces risks if these external contracts are compromised or contain vulnerabilities, affecting the audited project's integrity. The project heavily depends on Supra Oracle for price feeds and external price validation.

The project utilizes libraries or contracts without security audits, potentially introducing vulnerabilities. This compromises the security of the audited system, making it susceptible to attacks exploiting these external weaknesses.

Dynamic Array Iteration Gas Limit Risks were identified in trading.move where the system iterates through order vectors in get_execute_order_all_ids() function.

Critical functions rely on single-signer authorization rather than multi-signature. The ecosystem grants a single entity the authority to implement upgrades or changes. This centralization of power risks unilateral decisions that may not align with the community or stakeholders' interests, undermining trust and security.

No time delays for critical parameter changes or admin functions.

Admin can modify Oracle configurations without constraints. This grants a single entity the authority to implement upgrades or changes. This centralization of power risks unilateral decisions that may not align with the community or stakeholders' interests, undermining trust and security.

Heavy reliance on @dexlyn address for all administrative functions.

Findings

Code
Title
Status
Severity
F-2025-1246Profit Cap Bypass via Partial Position Closures Breaks Protocol Limitations
fixed

Critical
F-2025-1244Funding Rate Mechanism Abused to Systematically Drain Protocol Liquidity
accepted

High
F-2025-1239Leverage Clamp Can Push Open Interest Over the Pair Cap
fixed

High
F-2025-1236DXLP Ratio Manipulation and Denial of Service
fixed

High
F-2025-1235Incorrect DAY_SECONDS Constant Breaks LP Token Withdrawal Security Model
fixed

High
F-2025-1234Liquidation Blocked by Profit-Taking Cooldown
fixed

High
F-2025-1234Validation-Execution Leverage Buffer Mismatch Causing Unexpected Order Cancellations
fixed

High
F-2025-1221Redeem Fees Distort MDD Calculation, Bypassing Safety Mechanisms
fixed

High
F-2025-1230Maximum Position Collateral Validation Inconsistency
fixed

Medium
F-2025-1219Arithmetic Overflow DoS in place_order and execute_order Functions due to Taker Fee
fixed

Medium
1-10 of 19 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/DexlynLabs/dexlyn_perp_dex
Initial Commit6feeaaa2b1bd9bb4be97469c045cd72e0431ad96
Final Commit4dcc4c3cff517afc1f6c158f7ddbf903906747de
Whitepaperhttps://docs.dexlyn.com
Requirementshttps://docs.dexlyn.com
Technical Requirementshttps://github.com/DexlynLabs/dexlyn_perp_dex

Assets in Scope

.
move
common
sources
blocked_user.move - . › move › common › sources › blocked_user.move
coin_utils.move - . › move › common › sources › coin_utils.move
safe_math.move - . › move › common › sources › safe_math.move
dexlyn-perp-trade
sources
capability.move - . › move › dexlyn-perp-trade › sources › capability.move
delegate_account.move - . › move › dexlyn-perp-trade › sources › delegate_account.move
deployments
pair_types.move - . › move › dexlyn-perp-trade › sources › deployments › pair_types.move
fee_distributor.move - . › move › dexlyn-perp-trade › sources › fee_distributor.move
house_lp.move - . › move › dexlyn-perp-trade › sources › house_lp.move
managed_capability.move - . › move › dexlyn-perp-trade › sources › managed_capability.move
managed_delegate_account.move - . › move › dexlyn-perp-trade › sources › managed_delegate_account.move
managed_fee_distributor.move - . › move › dexlyn-perp-trade › sources › managed_fee_distributor.move
managed_house_lp.move - . › move › dexlyn-perp-trade › sources › managed_house_lp.move
managed_price_oracle.move - . › move › dexlyn-perp-trade › sources › managed_price_oracle.move
managed_trading.move - . › move › dexlyn-perp-trade › sources › managed_trading.move
managed_vault.move - . › move › dexlyn-perp-trade › sources › managed_vault.move

Appendix 3. Additional Valuables

Verification of System Invariants

During the audit of Dexlyn Perpetual DEX, Hacken followed its methodology by performing invariant testing combined with randomized inputs on the project's official invariants. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use invariant testing to ensure that several system invariants hold true in all situations.

Throughout the assessment, 9 invariants were tested over 9000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.

Invariant Name

Test Case

Test Result

Run Count

Maximum Profit Cap (900%)test_protocol_maximum_profit_cap_randomized()Failed1k
Fee Distribution Accuracytest_protocol_fee_distribution_randomized()Passed1k
Leverage Constraints Validationtest_protocol_leverage_constraints_randomized()Passed1k
Liquidation Process Integritytest_protocol_liquidation_process_randomized()Passed1k
Minimum Collateral Enforcementtest_protocol_minimum_collateral_enforcement_randomized()Passed1k
Minimum Position Size Enforcementtest_protocol_minimum_position_size_enforcement_randomized()Passed1k
Open Interest Tracking Accuracytest_protocol_open_interest_tracking_randomized()Passed1k
Order Types Execution Logictest_protocol_order_types_randomized()Passed1k
Take Profit/Stop Loss Executiontest_protocol_tp_sl_execution_randomized()Passed1k
  • Invariant Name

    Maximum Profit Cap (900%)

    Test Case

    test_protocol_maximum_profit_cap_randomized()

    Test Result

    Failed

    Run Count

    1k

    Invariant Name

    Fee Distribution Accuracy

    Test Case

    test_protocol_fee_distribution_randomized()

    Test Result

    Passed

    Run Count

    1k

    Invariant Name

    Leverage Constraints Validation

    Test Case

    test_protocol_leverage_constraints_randomized()

    Test Result

    Passed

    Run Count

    1k

    Invariant Name

    Liquidation Process Integrity

    Test Case

    test_protocol_liquidation_process_randomized()

    Test Result

    Passed

    Run Count

    1k

    Invariant Name

    Minimum Collateral Enforcement

    Test Case

    test_protocol_minimum_collateral_enforcement_randomized()

    Test Result

    Passed

    Run Count

    1k

    Invariant Name

    Minimum Position Size Enforcement

    Test Case

    test_protocol_minimum_position_size_enforcement_randomized()

    Test Result

    Passed

    Run Count

    1k

    Invariant Name

    Open Interest Tracking Accuracy

    Test Case

    test_protocol_open_interest_tracking_randomized()

    Test Result

    Passed

    Run Count

    1k

    Invariant Name

    Order Types Execution Logic

    Test Case

    test_protocol_order_types_randomized()

    Test Result

    Passed

    Run Count

    1k

    Invariant Name

    Take Profit/Stop Loss Execution

    Test Case

    test_protocol_tp_sl_execution_randomized()

    Test Result

    Passed

    Run Count

    1k

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

Dexlyn audit by Hacken