Introduction
We express our gratitude to the Dexlyn team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Dexlyn is a dynamic DeFi platform on the Supra Chain, offering secure and efficient token swaps and liquidity management through its automated market maker (AMM) technology. Beyond these capabilities, Dexlyn is evolving into a comprehensive DeFi ecosystem, with plans to integrate advanced functionalities, empowering users with a wide range of decentralized financial solutions. Hyperlane, an open-source interoperability framework, enhances Dexlyn’s ecosystem by enabling seamless cross-chain communication and deployment. It connects over 100 blockchains, utilizing customizable security modules and multi-VM support to drive innovation and scalability.
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Dexlyn
- Audited By
- Jakub Heba
- Approved By
- Przemyslaw Swiatowiec
- Website
- dexlyn.com→
- Changelog
- 03/01/2025 - Preliminary Report, 13/01/2025 - Final Report
- Platform
- Supra
- Language
- MOVE
- Tags
- cross-chain
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope
- Commit
- 8d4b098701f84dc440ed88a6dfc2ce61e0ca9067
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are partially missed.
Technical description is not provided.
Code quality
The code duplicates commonly known contracts instead of reusing them.
Several template code patterns were found.
The development environment is configured.
Test coverage
Code coverage cannot be calculated, as only E2E tests were provided, which are covering basic contract iterations only.
Deployment and basic user interactions are covered with tests.
Negative cases coverage is missed.
Interactions by several users are not tested thoroughly.
System Overview
Dexlyn Hyperlane on Aptos implementation consists of the following components:
IGPS (Interchain Gas Payment Service) module manages cross-chain gas payments, allowing users to pay for transaction gas fees on destination chains using the source chain's native token, with features for gas price conversion based on exchange rates and beneficiary management. It is also using the Gas Oracle.
Multisig ISM (Interchain Security Module) contract implements a multi-signature verification scheme for cross-chain messages, allowing a configurable threshold of validators from different domains to sign and verify message authenticity, with features for validator management and ownership control.
Mailbox module serves as the core messaging infrastructure for cross-chain communication, handling message dispatch, verification, and delivery between different domains with features like message merkleization, gas payment integration, and delivery status tracking.
Router module manages cross-chain communication routing by maintaining registries of remote router addresses and providing functionality to enroll and verify router addresses across different domains, with features for ownership management and type-safe router initialization.
Synthetic tokens - Both modules implement cross-chain token bridge functionality, with different token management approaches:
HyperCoin - Implements a synthetic token bridge that can mint and burn tokens, using capabilities for token management.
HyperCoinCollateral - Implements a collateral-based token bridge that locks tokens in a resource account instead of burning, using existing token type FusionCoin.
Validator Announce module manages validator announcements and their storage locations, implementing signature verification for announcements and preventing replay attacks, with functionality to track and query validator registrations and their associated storage metadata.
Privileged roles
Validators - Sign and verify cross-chain messages using multi-signature scheme, announce their storage locations
Owner/Admin - Controls protocol configuration, can update gas prices, beneficiary addresses, and validator settings
Relayers - Pay gas fees and relay messages between chains
Beneficiary - Receives collected gas fees from interchain gas payments
Potential Risks
No additional risks have been found.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
F-2025-8185 | Incorrect token amount calculation during transfer | Fixed | Critical | |
F-2025-8182 | Incorrect message signature verification parameters | Fixed | Critical | |
F-2025-8048 | One-way ownership transfer pattern is Unsafe | Fixed | Low | |
F-2025-8047 | Unused variable | Fixed | Low | |
F-2025-8049 | In an edge case transfer will revert despite having sufficient funds | Accepted | Low | |
F-2025-8050 | Missing event emissions | Fixed | Observation | |
F-2025-8051 | Unfinished development TODOs in codebase | Fixed | Observation |
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
- 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
- Commit
- 8d4b098701f84dc440ed88a6dfc2ce61e0ca9067
- Whitepaper
- -
- Technical Requirements
- -
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.