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

Dexalot

Audit name:

[SCA] Dexalot | Bridge | Jan2026

Date:

Feb 26, 2026

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 an omni-chain, ERC20-less decentralized exchange protocol that operates across multiple EVM-compatible chains including Avalanche C-Chain, Dexalot L1, Arbitrum, Base, and Gunzilla.

Document

NameSmart Contract Code Review and Security Analysis Report for Dexalot
Audited ByOlesia Bilenka, Ivan Bondar
Approved ByKhrystyna Tkachuk
Websitehttps://dexalot.com/→
Changelog16/02/2026 - Preliminary Report
13/03/2026 - Final Report
PlatformAvalanche C-Chain; Dexalot L1; Arbitrum; Base; Gunzilla
LanguageSolidity
TagsDEX; Bridge; Upgradable; Centralization; OrderBook; Vault
Methodologyhttps://docs.hacken.io/methodologies/smart-contracts→

  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Dexalot
    Audited By
    Olesia Bilenka, Ivan Bondar
    Approved By
    Khrystyna Tkachuk
    Website
    https://dexalot.com/→
    Changelog
    16/02/2026 - Preliminary Report
    13/03/2026 - Final Report
    Platform
    Avalanche C-Chain; Dexalot L1; Arbitrum; Base; Gunzilla
    Language
    Solidity
    Tags
    DEX; Bridge; Upgradable; Centralization; OrderBook; Vault
    Methodology
    https://docs.hacken.io/methodologies/smart-contracts→

Review Scope

Repositoryhttps://github.com/Dexalot/contracts/→
Commit396ddde
Final Commit40fde87

Audit Summary

55Total Findings
37Resolved
2Accepted
16Mitigated

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 detailed.

    • Project overview is detailed

    • All roles in the system are described.

    • Use cases are described and detailed.

    • For each contract, all futures are described.

    • All interactions are described.

  • Technical description is detailed.

    • Run instructions are provided.

    • Technical specification is provided.

    • The NatSpec documentation is sufficient.

Code quality

  • The development environment is configured.

Test coverage

The project demonstrates a high level of automated test coverage. Due to the combined use of Foundry and Hardhat within the same codebase, a single consolidated coverage metric cannot be reliably derived.

  • Deployment and basic user interactions are covered with tests.

  • Negative cases coverage is present.

  • Interactions by several users are tested.

System Overview

Dexalot is an omni-chain, ERC20-less decentralized exchange protocol that operates across multiple EVM-compatible chains including Avalanche C-Chain, Dexalot L1, Arbitrum, Base, and Gunzilla. The protocol implements a unique architecture where tokens are locked in mainnet Portfolio contracts and their virtual representations are traded on the Dexalot L1 using Central Limit Order Books (CLOB) without deploying ERC20 contracts on the L1.

The system supports multiple cross-chain bridges (ICM - Avalanche's Inter-Chain Messaging and LayerZero) for deposits and withdrawals, enabling users to deposit with one bridge and withdraw with another. The architecture implements gas abstraction through a GasStation contract that automatically swaps deposited tokens for native gas tokens, eliminating the need for users to manage gas tokens on Dexalot L1.

Dexalot also features a Request-For-Quote (RFQ) system for single-chain and cross-chain token swaps using off-chain price discovery from the Dexalot L1 orderbook. Additionally, the protocol introduces OmniVaults - managed vaults that allow automated trading strategies through whitelisted executor contracts.

The protocol aims to provide professional-grade trading with price-time priority orderbooks, maker/taker fee structures with volume-based rebates, auction mechanisms for token launches, and sophisticated inventory management across chains.

Files in Scope

Core Trading Contracts:

  • TradePairs.sol - Manages trade pairs with Central Limit Order Books, handling order creation, matching, cancellation, and execution with support for LIMIT/MARKET orders, auction modes, and self-trade prevention (STP).

  • OrderBooks.sol - Implements Red-Black-Tree based orderbooks with price-time priority, maintaining buy/sell books for each trade pair.

  • PortfolioSub.sol - Dexalot L1 portfolio managing virtual token balances, trade executions, fee calculations, gas abstraction (AutoFill), and withdrawal processing.

  • PortfolioSubHelper.sol - Helper contract managing rate overrides, volume-based rebates, admin accounts for rates, and taker fee collectors.

Mainnet Contracts:

  • PortfolioMain.sol - Gateway for deposits to Dexalot L1, processes withdrawal messages, maintains ERC20 token mappings, and handles trusted contracts.

  • Portfolio.sol - Abstract base contract for portfolio functionality shared between PortfolioMain and PortfolioSub.

Bridge Contracts:

  • PortfolioBridgeMain.sol - Bridge aggregator on mainnets supporting multiple bridge providers (ICM, LayerZero), handling cross-chain message encoding/decoding.

  • PortfolioBridgeSub.sol - Dexalot L1 bridge aggregator with symbol mapping, inventory management integration, delayed transfers, and dynamic bridge fee calculations.

  • DefaultBridgeApp.sol - Abstract base implementation for bridge providers with remote chain configuration.

  • ICMApp.sol - Avalanche ICM bridge implementation using Teleporter for inter-chain messaging.

RFQ Contracts:

  • MainnetRFQ.sol - Upgradeable RFQ contract for same-chain and cross-chain swaps with signed quotes, slippage protection, and swap queuing.

  • DexalotRFQ.sol - Non-upgradeable RFQ contract with immutable swap signer and wrapped native token configuration.

  • DexalotRouter.sol - Router contract facilitating aggregator swaps via RFQ order execution with multi-hop swap support.

OmniVault Contracts:

  • OmniVaultManager.sol - Manages OmniVaults, handling deposit/withdrawal requests in batches, vault registration, and share token operations.

  • OmniVaultCreator.sol - Facilitates vault creation with initial deposits, fee collection, and request lifecycle management.

  • OmniVaultExecutor.sol - Executor contract allowing EOA trading bots to interact with whitelisted functions on trusted contracts.

  • OmniVaultExecutorSub.sol - Dexalot L1 executor for dispatching assets from OmniVaults back to users.

  • OmniVaultShare.sol - ERC20 vault share tokens with LayerZero OFT cross-chain functionality.

  • OmniVaultRegistry.sol - Registry for OmniVault contracts and configurations.

Supporting Contracts:

  • DelayedTransfers.sol - Implements withdrawal delays and volume caps for security on large transfers.

  • InventoryManager.sol - Manages multi-chain token inventory, calculates withdrawal fees based on liquidity distribution.

Libraries:

  • UtilsLibrary.sol - Utility functions for byte conversions, decimal handling, and auction mode checks.

  • InventoryFeeCalculatorLibrary.sol - Calculates inventory-based withdrawal fees using invariant formulas.

Privileged roles

  • TradePairs.sol

    • DEFAULT_ADMIN_ROLE: Can pause/unpause contract, pause/unpause individual trade pairs, add/remove order types, set auction mode/price, set min/max trade amounts, set maker/taker rates, set display decimals, set slippage percent, remove trade pairs, and execute unsolicited cancels.

    • EXCHANGE_ROLE: Can add new trade pairs.

  • PortfolioSub.sol

    • DEFAULT_ADMIN_ROLE: Can add/remove tokens, set fee address, set gas station, set treasury, set portfolio minter, set portfolio bridge, set portfolio sub helper, set auction mode, pause/unpause contract, pause deposits, and set bridge parameters.

    • EXECUTOR_ROLE: Can execute trades (addExecution), adjust available balances, set auction mode, and trigger autoFill gas operations.

    • PORTFOLIO_BRIDGE_ROLE: Can process cross-chain transfer payloads (deposits).

    • TRUSTED_TRANSFER_ROLE: Can perform bulk transfers on behalf of other users.

  • PortfolioMain.sol

    • DEFAULT_ADMIN_ROLE: Can add/remove tokens, set banned accounts, add/remove trusted contracts, collect bridge fees, set wrapped native, set min deposit multiplier, pause/unpause, and set bridge parameters.

    • PORTFOLIO_BRIDGE_ROLE: Can process cross-chain transfer payloads (withdrawals).

  • Portfolio.sol (Base)

    • DEFAULT_ADMIN_ROLE: Can set portfolio bridge, pause/unpause, pause deposits, set bridge parameters, and set L1 decimals.

    • PORTFOLIO_BRIDGE_ROLE: Can set bridge parameters.

  • PortfolioBridgeMain.sol

    • DEFAULT_ADMIN_ROLE: Can enable/disable bridge providers, set trusted remote addresses, set default destination chain, set user pays fee settings, set portfolio, set gas airdrop, refund native balance, and enable cross-chain swap destinations.

    • BRIDGE_USER_ROLE: Can pause/unpause, send cross-chain messages (held by Portfolio and MainnetRFQ).

    • BRIDGE_ADMIN_ROLE: Can set bridge parameters on portfolio.

    • BRIDGE_PROVIDER_ROLE: Can process incoming cross-chain payloads (held by bridge app contracts).

  • PortfolioBridgeSub.sol

    • DEFAULT_ADMIN_ROLE: Same as PortfolioBridgeMain plus set delayed transfers, set inventory manager, set bridge fee multiplier, set max bridge fee caps, set option gas costs, and set L1 decimals.

    • BRIDGE_USER_ROLE: Can add/remove tokens, send cross-chain messages.

    • BRIDGE_ADMIN_ROLE: Can set bridge fees, execute delayed transfers.

    • BRIDGE_PROVIDER_ROLE: Can process incoming cross-chain payloads.

  • DexalotRFQ.sol

    • DEFAULT_ADMIN_ROLE: Can set portfolio bridge, set portfolio main, add/remove admins, add/remove rebalancers, add/remove volatility admins.

    • REBALANCER_ADMIN_ROLE: Can claim/withdraw assets, send token balance, receive native tokens.

    • PORTFOLIO_BRIDGE_ROLE: Can process cross-chain trade payloads.

    • VOLATILITY_ADMIN_ROLE: Can set slippage points.

  • DexalotRouter.sol

    • DEFAULT_ADMIN_ROLE: Can set allowed RFQ contracts and retrieve tokens.

  • OrderBooks.sol

    • DEFAULT_ADMIN_ROLE: Can set trade pairs contract.

    • EXECUTOR_ROLE: Can add orderbooks, add/remove orders, match trades (held by TradePairs).

  • DelayedTransfers.sol

    • DEFAULT_ADMIN_ROLE: Can check thresholds, execute delayed transfers, set delay thresholds, set delay period, set epoch length, set epoch volume caps, update volume.

  • InventoryManager.sol

    • DEFAULT_ADMIN_ROLE: Can update PortfolioBridgeSub, set scaling factors, remove scaling factors, update future K value, update K value.

    • PORTFOLIO_BRIDGE_ROLE: Can increment/decrement inventory, remove tokens.

  • PortfolioSubHelper.sol

    • DEFAULT_ADMIN_ROLE: Can set min taker rate, add/remove admin accounts for rates, add/remove volume based rebates, add/remove rate overrides, set taker fee collectors.

  • OmniVaultManager.sol

    • DEFAULT_ADMIN_ROLE: Can register vaults, pause/unpause vaults, update vault details, add/update token details, pause/unpause contract, set portfolio.

    • SETTLER_ROLE: Can bulk settle deposit and withdrawal requests.

  • OmniVaultCreator.sol

    • DEFAULT_ADMIN_ROLE: Can accept and fund vaults, reject vault requests, set fee token, set fee amount, set reclaim delay, withdraw collected fees.

  • OmniVaultExecutor.sol / OmniVaultExecutorSub.sol

    • DEFAULT_ADMIN_ROLE: Can set whitelisted functions, set trusted contracts, set portfolio.

    • OMNITRADER_ROLE: Can execute whitelisted functions via fallback, send native, approve tokens, dispatch assets.

  • OmniVaultShare.sol

    • owner: Can set OmniVaultManager, configure LayerZero settings.

  • ICMApp.sol

    • owner: Can set portfolio bridge, set relayers, add/clear relayers, set gas limits, set native bridge fees.

  • DefaultBridgeApp.sol

    • portfolioBridge (modifier): Can send messages and set remote chains.

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.

Upgradability and Future Version Modifications: The contract's upgradable nature means that its implementation can be modified in future versions. This flexibility allows for necessary updates and improvements but also introduces uncertainty for users regarding future changes in the contract's behavior and rules. Users should stay informed about any contract upgrades and understand their implications.

Cross-Chain Communication Risks: Operating across multiple chains (Avalanche, Ethereum, Arbitrum, Gunzilla) introduces risks associated with cross-chain communication and bridging. This includes potential delays, miscommunications, or exploits that target the bridge mechanisms.

Governance and Access Control Risks: The system relies heavily on role-based access control for administrative tasks. Mismanagement of these roles or exploitation of these privileges could lead to unauthorized actions, including pausing key functionalities or misconfiguring critical parameters.

Unbounded Loops in TradePairs Contract: The TradePairs contract contains unbounded loops, which can result in transactions running out of gas when processing large numbers of orders. This could lead to failed transactions and wasted gas. Users, particularly market makers, should be mindful of the potential for gas exhaustion when submitting multiple orders in a single transaction.

Inventory-Based Withdrawal Limitations: There's a risk associated with user deposits not being withdrawable to the originally deposited chain if the inventory on that chain drops significantly. This could lead to situations where users are unable to access their funds on their preferred chain, potentially causing liquidity and user experience issues.

Maximum Fee Cap: Users are advised to remain aware of the potential for high withdrawal fees, particularly in scenarios where inventory is low on their desired withdrawal chain. They should also pay attention to frontend notifications and consider alternative options provided by the platform to minimize fees. Users should stay informed about any future updates or changes to the fee structure and amplification coefficient management.

Unpredictable Withdrawal Fees Due to Sensitivity Exponent (K) and Inventory Fluctuations: The sensitivity exponent K (range 8-32) and per-token target ratios can be adjusted by the protocol, influencing withdrawal fees that range from 0.01% to 5%. Fees are calculated dynamically based on real-time inventory distribution across chains, meaning users may face variable costs depending on current inventory imbalance at withdrawal time. While users who deposited from a specific chain receive fee exemption up to their deposited amount, others should remain aware that fees fluctuate based on inventory state and configured parameters.

Elevated Privileges of Trusted Contracts in Dexalot's Ecosystem: Trusted Contracts, particularly those used for auction coordination, are granted significant powers, including the ability to deposit tokens on behalf of users. While these contracts are currently limited to auction-related activities, the broad privileges they hold could lead to unintended consequences if compromised or misused. Though Dexalot ensures these contracts are used specifically for auction activities, users should be aware of the elevated control these contracts possess and the reliance on their security.

Decimal Variation in Cross-Chain Transactions: The protocol is designed to support tokens with differing decimal places across various blockchains. The protocol takes on the responsibility of correctly setting, validating, and managing these decimal variations to ensure accurate value scaling during cross-chain transfers and fee calculations. This approach introduces additional complexity, particularly in the truncation and scaling logic, but significantly increases flexibility and token supportability across networks.

Upgrade Routine Risk: Inserting new variables or changing types in structs used in mappings can alter the storage layout. In some scenarios, differences in optimizer settings may modify struct packing or mapping lookups, inadvertently leading to data misalignment during an upgrade. Since the upgrade process is outside the audit scope, the project team must validate any upgrades in staging or test environments to ensure storage remains consistent and no data corruption occurs.

Findings

Code
―
Title
Status
Severity
F-2026-1487Inverted isDirect Flag Logic Causes ERC20 Tokens to Not Be Collected in Direct Swaps
fixed

Critical
F-2026-1486Missing Gas Tank Auto-Fill for Recipients in Bulk Transfers
fixed

Medium
F-2026-1486Front-Running DoS on Batch Settlement via Rolling Hash Invalidation
fixed

Medium
F-2026-1484Untrusted Contract Remains Callable via Whitelisted Function After Trust Revocation
mitigated

Medium
F-2026-1493Auction Mode Bypass in bulkTransferTokens Allows Transfers During Active Auctions
fixed

Medium
F-2026-1499depositTokenFromContract Cannot Pay Bridge Fees
fixed

Medium
F-2026-1488Removal of Swap Expiry Mechanism Prevents Server-Side Quote Invalidation
mitigated

Low
F-2026-1487Immutable swapSigner Prevents Key Rotation and Creates Irrecoverable Compromise Risk
mitigated

Low
F-2026-1487Removal of Pause Functionality Eliminates Emergency Response Capability
mitigated

Low
F-2026-1486TRUSTEDTRANSFERROLE Allows Arbitrary Fund Transfers
mitigated

Low
1-10 of 55 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/→
Commit396dddee7c99c809b9599bec94c42823306abbcd
Final Commit40fde8718d115398db4f026b7254da2ee0093b7c
Whitepaperhttps://dexalot.com/docs/DEXALOT-Litepaper.pdf→
Requirementshttps://docs.dexalot.com/en/contracts/→
Technical Requirementshttps://docs.dexalot.com/en/contracts/→

Assets in Scope

contracts
bridgeApps
DefaultBridgeApp.sol - contracts › bridgeApps › DefaultBridgeApp.sol
ICMApp.sol - contracts › bridgeApps › ICMApp.sol
DexalotRFQ.sol - contracts › DexalotRFQ.sol
DexalotRouter.sol - contracts › DexalotRouter.sol
InventoryManager.sol - contracts › InventoryManager.sol
library
InventoryFeeCalculatorLibrary.sol - contracts › library › InventoryFeeCalculatorLibrary.sol
UtilsLibrary.sol - contracts › library › UtilsLibrary.sol
OrderBooks.sol - contracts › OrderBooks.sol
Portfolio.sol - contracts › Portfolio.sol
PortfolioBridgeMain.sol - contracts › PortfolioBridgeMain.sol
PortfolioBridgeSub.sol - contracts › PortfolioBridgeSub.sol
PortfolioMain.sol - contracts › PortfolioMain.sol
PortfolioSub.sol - contracts › PortfolioSub.sol
PortfolioSubHelper.sol - contracts › PortfolioSubHelper.sol
TradePairs.sol - contracts › TradePairs.sol
vaults
OmniVaultCreator.sol - contracts › vaults › OmniVaultCreator.sol
OmniVaultExecutor.sol - contracts › vaults › OmniVaultExecutor.sol
OmniVaultExecutorSub.sol - contracts › vaults › OmniVaultExecutorSub.sol

Appendix 3. Additional Valuables

Verification of System Invariants

During the audit of Dexalot, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.

Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Foundry fuzzing suite was prepared for this task, and throughout the assessment, 22 invariants were tested over 256 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.

Invariant

Test Result

Run Count

INV-1 invariant_kBounds — K within [8, 32]Passed256
INV-2 invariant_futureKTimelock — futureKTime respects 1h minimumPassed256
INV-3 invariant_inventoryAccounting — ghost inventory matches on-chainPassed256
INV-4 invariant_totalInventoryConsistency— ghost inventory matches on-chainPassed256
INV-5 handler_updateKEarly — updateK reverts before futureKTimePassed256
INV-6 handler_decrementOverflow — decrement reverts on underflowPassed256
INV-7 handler_remove — remove succeeds iff inventory 0Passed256
INV-8 handler_calculateWithdrawalFee — fee 0 single chainPassed256
INV-9 handler_calculateWithdrawalFee — fee 0 empty chainPassed256
INV-10 handler_calculateWithdrawalFee — fee 0 user liquidity covers qtyPassed256
INV-11 handler_calculateWithdrawalFee — fee <= 5.01% of effective qtyPassed256
INV-12 handler_aclBridgeRevert — bridge functions revert without rolePassed256
INV-13 handler_aclAdminRevert — admin functions revert without rolePassed256
INV-14 handler_decrementFullLiquidity — liquidity slot deleted at zeroPassed256
INV-15 handler_setScalingFactorsInvalid — revert on unregistered tokenPassed256
INV-16 handler_updatePortfolioBridgeSub — role transfer on bridge swapPassed256
INV-17 handler_verifyDefaultRatio — default ratio is BPS/numChainsPassed256
INV-18 invariant_kMultipleOf4 — K multiple of 4Failed256
INV-19 invariant_userLiquidityAccounting — ghost liquidity matches on-chainPassed256
INV-20 invariant_futureKBounds — futureK within [8, 32]Passed256
INV-21 invariant_bridgeNonZero — bridge address never zeroPassed256
INV-22 invariant_bridgeHasRole — current bridge holds its rolePassed256

  • Invariant

    INV-1 invariant_kBounds — K within [8, 32]

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-2 invariant_futureKTimelock — futureKTime respects 1h minimum

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-3 invariant_inventoryAccounting — ghost inventory matches on-chain

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-4 invariant_totalInventoryConsistency— ghost inventory matches on-chain

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-5 handler_updateKEarly — updateK reverts before futureKTime

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-6 handler_decrementOverflow — decrement reverts on underflow

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-7 handler_remove — remove succeeds iff inventory 0

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-8 handler_calculateWithdrawalFee — fee 0 single chain

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-9 handler_calculateWithdrawalFee — fee 0 empty chain

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-10 handler_calculateWithdrawalFee — fee 0 user liquidity covers qty

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-11 handler_calculateWithdrawalFee — fee <= 5.01% of effective qty

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-12 handler_aclBridgeRevert — bridge functions revert without role

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-13 handler_aclAdminRevert — admin functions revert without role

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-14 handler_decrementFullLiquidity — liquidity slot deleted at zero

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-15 handler_setScalingFactorsInvalid — revert on unregistered token

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-16 handler_updatePortfolioBridgeSub — role transfer on bridge swap

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-17 handler_verifyDefaultRatio — default ratio is BPS/numChains

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-18 invariant_kMultipleOf4 — K multiple of 4

    Test Result

    Failed

    Run Count

    256

    Invariant

    INV-19 invariant_userLiquidityAccounting — ghost liquidity matches on-chain

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-20 invariant_futureKBounds — futureK within [8, 32]

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-21 invariant_bridgeNonZero — bridge address never zero

    Test Result

    Passed

    Run Count

    256

    Invariant

    INV-22 invariant_bridgeHasRole — current bridge holds its role

    Test Result

    Passed

    Run Count

    256

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.

Frameworks and Methodologies

This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.

Disclaimer

Dexalot audit by Hacken