Q1 2025 Web3 Security ReportAccess control failures led to $1.63 billion in losses
Discover report insights
  • Hacken
  • Audits
  • dexalot
  • [SCA] Dexalot / Solana / Mar2025

Dexalot

Audit name:

[SCA] Dexalot / Solana / Mar2025

Date:

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

Dexalot is a revolutionary decentralized exchange that features an on-chain Central Limit Order Book (CLOB), providing a trading experience similar to traditional centralized exchanges. Operating on its own dedicated Avalanche subnet and expanding cross-chain, Dexalot offers enhanced trading efficiency and accessibility across multiple blockchain ecosystems.

Document

NameSmart Contract Code Review and Security Analysis Report for Dexalot
Audited ByStepan Chekhovskoi, Ataberk Yavuzer
Approved ByIvan Bondar
Websitehttps://dexalot.com→
Changelog24/04/2025 - Preliminary Report
04/06/2025 - Final Report
PlatformSolana
LanguageRust
TagsDeX, DeFi, Bridge
Methodologyhttps://hackenio.cc/sc_methodology→

  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Dexalot
    Audited By
    Stepan Chekhovskoi, Ataberk Yavuzer
    Approved By
    Ivan Bondar
    Website
    https://dexalot.com→
    Changelog
    24/04/2025 - Preliminary Report
    04/06/2025 - Final Report
    Platform
    Solana
    Language
    Rust
    Tags
    DeX, DeFi, Bridge
    Methodology
    https://hackenio.cc/sc_methodology→

Review Scope

Repositoryhttps://github.com/Dexalot/contracts→
Initial Commit09afb2bbb15fe9d36a180152149d8aa056d99db8
Final Commite5ead8e310da5638909a0e33f3f4493c324463fd

Audit Summary

10Total Findings
10Resolved
0Accepted
0Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • The program is provided with basic instruction description and build instructions.

  • Documentation covers EVM implementation which is not directly related to the audit.

Code quality

  • Development environment is configured.

  • Accounts are mostly not validated in instruction contexts, the checks are implemented manually.

  • The code contains some duplications such as similar logic and unnecessary validations.

  • Two different ownership validation methods are used across the contract.

Test coverage

Unit tests code coverage is 74% (region coverage).

  • While the unit tests has significant coverage, cross contract calls cannot be tested in the environment.

  • Integration tests cover basic functionality.

  • Several tests are failing out of the box.

  • LayerZero integration – critical project part – is not thoroughly tested.

System Overview

Dexalot is a decentralized exchange (DEX) built on its own subnet, Dexalot L1, offering secure and efficient trading across multiple blockchain networks like Avalanche C-Chain, Arbitrum, Base, Gunzilla L1, and Solana L1. Unlike traditional exchanges, Dexalot’s architecture eliminates the need to deploy ERC20 contracts on Dexalot L1 or physically bridge tokens between chains. Its bridge-agnostic design supports interoperability by working with multiple bridge providers, such as Avalanche's Interchain Messaging (ICM) and LayerZero. This enables users to deposit assets through one bridge and withdraw through another, offering enhanced flexibility across the ecosystem.

The core mechanism involves locking user assets in the PortfolioMain contract on the originating chain (e.g., Avalanche C-Chain). User portfolio data is then communicated to Dexalot L1 via bridge aggregators like PortfolioBridgeMain and PortfolioBridgeSub, ensuring secure cross-chain communication without the need for token movement. On Dexalot L1, the PortfolioSub contract manages user balances for trading without holding the actual ERC20 tokens.

At the heart of Dexalot’s trading operations is the TradePairs contract, which functions as a central limit order book (CLOB). It manages all trade pairs, such as AVAX/USDT, and operates the matching engine for processing trades. This contract allows the creation, modification, and deletion of trade pairs, as well as managing orders within the system.

Smart contracts, including Portfolio and TradePairs, ensure robust asset and trade management, while strict access controls and role-based permissions safeguard sensitive operations. Cross-chain interactions are made seamless through bridge aggregators that handle communication with supported bridge providers, allowing for secure and flexible multi-chain trading.

The audit covers Dexalot on Solana implementation. The contract provides ability to deposit funds into the Protocol from Solana L1. Native coin airdrop for covering Gas fees functionality is implemented. Additional in-place swap functionality is implemented to cover simple swap requests with a lower Gas expenses.

Privileged roles

  • The protocol owner is able to upgrade the smart contract

  • The protocol owner is able to setup LayerZero integration parameters

  • The protocol administrators are able to manage tokens allowed for deposit

  • The protocol administrators are able to pause deposits and most of the contract functionality

  • The protocol rebalancers are able to rebalance liquidity pools to cover the in-place swap requests

Potential Risks

System Reliance on External Contracts: The functioning of the system significantly relies on LayerZero Protocol and Dexalot Protocol EVM implementations. Any flaws or vulnerabilities in the protocol contracts adversely affect the audited project, potentially leading to security breaches or loss of funds.

Single Points of Failure and Control: The project is mostly centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.

Bridge Message Rejection: The protocol operates over multiple chains using LayerZero as connector. The protocol does not implement any fallback functionality, in case a message is rejected by the smart contract at Avalanche Subnet or Solana side, the funds would not be automatically returned to the user.

Flexibility and Risk in Contract Upgrades: The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.

Findings

Code
―
Title
Status
Severity
F-2025-1073Arbitrary Funds Destination due to Lack of Accounts Validation in LzReceive
fixed

High
F-2025-1010Pause Functionality Implemented Partially
fixed

Medium
F-2025-1010Arbitrary LayerZero Endpoint Program
fixed

Medium
F-2025-1010Supported Tokens List Functionality Implemented Partially
fixed

Medium
F-2025-1010Redundant Bumps Recalculation
fixed

Low
F-2025-1010Inconsistent Deposit Pause Functionality
fixed

Observation
F-2025-1010Redundant Getter Instruction
fixed

Observation
F-2025-1010Redundant Account Initializations
fixed

Observation
F-2025-1010Redundant Portfolio PDA Fields
fixed

Observation
F-2025-1011Floating Toolchain Version
fixed

Observation
1-10 of 10 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/Dexalot/contracts→
Initial Commit09afb2bbb15fe9d36a180152149d8aa056d99db8
Final Commite5ead8e310da5638909a0e33f3f4493c324463fd
Whitepaperhttps://docs.dexalot.com/en/articles/litepaper→
Requirementshttps://docs.dexalot.com→
Technical Requirementssolana/README.md

Assets in Scope

programs
dexalot
Cargo.toml - programs/dexalot/Cargo.toml
src
consts.rs - programs/dexalot/src/consts.rs
cpi_utils.rs - programs/dexalot/src/cpi_utils.rs
errors.rs - programs/dexalot/src/errors.rs
events.rs - programs/dexalot/src/events.rs
instructions
banned_account.rs - programs/dexalot/src/instructions/banned_account.rs
claim_balance.rs - programs/dexalot/src/instructions/claim_balance.rs
create_account.rs - programs/dexalot/src/instructions/create_account.rs
create_ata.rs - programs/dexalot/src/instructions/create_ata.rs
deposit.rs - programs/dexalot/src/instructions/deposit.rs
fund.rs - programs/dexalot/src/instructions/fund.rs
global_config.rs - programs/dexalot/src/instructions/global_config.rs
initialize.rs - programs/dexalot/src/instructions/initialize.rs
lz_receive.rs - programs/dexalot/src/instructions/lz_receive.rs
lz_receive_types.rs - programs/dexalot/src/instructions/lz_receive_types.rs
mod.rs - programs/dexalot/src/instructions/mod.rs
process_xfer_payload.rs - programs/dexalot/src/instructions/process_xfer_payload.rs
roles.rs - programs/dexalot/src/instructions/roles.rs

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