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 | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Dexlyn |
| Audited By | Ataberk Yavuzer, Turgay Arda Usman |
| Approved By | Ivan Bondar |
| Website | https://docs.dexlyn.com→ |
| Changelog | 28/08/2025 - Preliminary Report |
| 23/09/2025 - Final Report | |
| Platform | Supra |
| Language | Move |
| Tags | Orderbook, Perpetual DEX, Prediction Market |
| Methodology | https://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
- Website
- https://docs.dexlyn.com→
- Changelog
- 28/08/2025 - Preliminary Report
- 23/09/2025 - Final Report
- Platform
- Supra
- Language
- Move
- Tags
- Orderbook, Perpetual DEX, Prediction Market
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/DexlynLabs/dexlyn_perp_dex→ |
| Initial Commit | 6feeaaa2b1bd9bb4be97469c045cd72e0431ad96 |
| Final Commit | 4dcc4c3cff517afc1f6c158f7ddbf903906747de |
Review Scope
- Initial Commit
- 6feeaaa2b1bd9bb4be97469c045cd72e0431ad96
- Final Commit
- 4dcc4c3cff517afc1f6c158f7ddbf903906747de
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
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
tradingcontract 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
vaultcontract 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_lpcontract 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 systemThe owner of the
price_oraclecontract 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_distributorcontract 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
capabilitycontract 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_usercontract 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-1246 | Profit Cap Bypass via Partial Position Closures Breaks Protocol Limitations | fixed | Critical | |
| F-2025-1244 | Funding Rate Mechanism Abused to Systematically Drain Protocol Liquidity | accepted | High | |
| F-2025-1239 | Leverage Clamp Can Push Open Interest Over the Pair Cap | fixed | High | |
| F-2025-1236 | DXLP Ratio Manipulation and Denial of Service | fixed | High | |
| F-2025-1235 | Incorrect DAY_SECONDS Constant Breaks LP Token Withdrawal Security Model | fixed | High | |
| F-2025-1234 | Liquidation Blocked by Profit-Taking Cooldown | fixed | High | |
| F-2025-1234 | Validation-Execution Leverage Buffer Mismatch Causing Unexpected Order Cancellations | fixed | High | |
| F-2025-1221 | Redeem Fees Distort MDD Calculation, Bypassing Safety Mechanisms | fixed | High | |
| F-2025-1230 | Maximum Position Collateral Validation Inconsistency | fixed | Medium | |
| F-2025-1219 | Arithmetic Overflow DoS in place_order and execute_order Functions due to Taker Fee | 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/DexlynLabs/dexlyn_perp_dex→ |
| Initial Commit | 6feeaaa2b1bd9bb4be97469c045cd72e0431ad96 |
| Final Commit | 4dcc4c3cff517afc1f6c158f7ddbf903906747de |
| Whitepaper | https://docs.dexlyn.com→ |
| Requirements | https://docs.dexlyn.com→ |
| Technical Requirements | https://github.com/DexlynLabs/dexlyn_perp_dex→ |
Scope Details
- Initial Commit
- 6feeaaa2b1bd9bb4be97469c045cd72e0431ad96
- Final Commit
- 4dcc4c3cff517afc1f6c158f7ddbf903906747de
- Whitepaper
- https://docs.dexlyn.com→
- Requirements
- https://docs.dexlyn.com→
- Technical Requirements
- https://github.com/DexlynLabs/dexlyn_perp_dex→
Assets in Scope
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() | Failed | 1k |
| Fee Distribution Accuracy | test_protocol_fee_distribution_randomized() | Passed | 1k |
| Leverage Constraints Validation | test_protocol_leverage_constraints_randomized() | Passed | 1k |
| Liquidation Process Integrity | test_protocol_liquidation_process_randomized() | Passed | 1k |
| Minimum Collateral Enforcement | test_protocol_minimum_collateral_enforcement_randomized() | Passed | 1k |
| Minimum Position Size Enforcement | test_protocol_minimum_position_size_enforcement_randomized() | Passed | 1k |
| Open Interest Tracking Accuracy | test_protocol_open_interest_tracking_randomized() | Passed | 1k |
| Order Types Execution Logic | test_protocol_order_types_randomized() | Passed | 1k |
| Take Profit/Stop Loss Execution | test_protocol_tp_sl_execution_randomized() | Passed | 1k |
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.