High Findings
Lack of Minimum Liquidity Constraint
Severity: High
Ecosystem: Sui
Protocol: Solend Steam
Auditor: OtterSec
Report: https://www.notion.so/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Feb 2025
Description: Insufficient minimum liquidity may expose the protocol to inflation attacks, enabling malicious actors to manipulate the value of bToken. If bToken value exceeds a 1:1 ratio, burning bToken and increasing the underlying token amount can trigger zero mint on user deposits, causing losses.
Inconsistencies Due to Zero Share Amount Value
Severity: High
Ecosystem: Sui
Protocol: Mysten Walrus
Auditor: OtterSec
Report: https://www.notion.so/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Feb 2025
Description: The staking_inner::request_withdraw_stake function does not explicitly prevent withdrawal requests with a share_amount of zero. This oversight allows malicious users to manipulate the staking pool's share-to-asset ratio by withdrawing a small principal or leaving it, potentially causing denial of service.
Unfair Rewards via Incorrect Supply Pool Instance
Severity: High
Ecosystem: Sui
Protocol: Kuna Labs
Auditor: OtterSec
Report: https://www.notion.so/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: June 2025
Description: If a user borrows from SupplyPool<X, SX0> to create a position, a malicious liquidator can exploit this by passing a different SupplyPool instance than the one used when the position was created, enabling extraction of extra rewards.
Trade Proof Bypass
Severity: High
Ecosystem: Sui
Protocol: Mysten Deepbook
Auditor: OtterSec
Report: https://www.notion.so/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Aug 2024
Description: If balances_in and balances_out are equal, the trade proof can be bypassed, allowing invalid trades to be executed without proper validation.
Bypass of the id_leak_verifier stage of suiverifier may occur
Severity: High
Ecosystem: Sui
Protocol: MystenLabs Sui
Auditor: OtterSec
Report: https://www.notion.so/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: May 2023
Description: Capabilities can be added during upgrades, potentially bypassing the id_leak_verifier stage of suiverifier, allowing unauthorized modifications to the protocol.
Pending Order Fee Tokens not Tied to Valid Tokens
Severity: High
Ecosystem: Sui
Protocol: ABEx Labs
Auditor: MoveBit
Report: https://movebit.xyz/reports/Abex-Smart-Contract-Audit-Report.pdf
Report Date: Aug 2023
Description: The fee token can be a fake coin minted by the attacker. When a pending order executor comes to execute the pending order, they receive the fake fee instead of the real token, causing losses to the executor.
May Be Wrong Parameters In flash function
Severity: High
Ecosystem: Sui
Protocol: FlowX Finance
Auditor: MoveBit
Report: https://movebit.xyz/reports/FlowX-Final-Audit-Report.pdf
Report Date: May 2024
Description: Multiple issues exist in the flash function: (1) if borrowed money exceeds existing pool funds, it automatically borrows the available amount instead of the requested amount; (2) the handling fee is calculated from user input rather than actual borrowed amount; (3) the FlashReceipt uses input parameters rather than actual output values, potentially causing repayment to fail with large losses.
Lack of Validation for the Generic Parameter CoinType
Severity: High
Ecosystem: Sui
Protocol: Navi
Auditor: MoveBit
Report Date: Jul 2023
Description: All functions in lending.move lack CoinType validation. Incorrect CoinType parameters cause incorrect asset calculations in Storage, potentially preventing the entire contract from functioning properly.
Lack of Validation for Campaign and Whitelist ID in invest function
Severity: High
Ecosystem: Sui
Protocol: SuiPad
Auditor: MoveBit
Report Date: Apr 2023
Description: The invest function lacks checks for campaign or whitelist ID, allowing users from one whitelist to participate in another campaign, bypassing access controls.
Lack of Validation for Funding Status in fund function
Severity: High
Ecosystem: Sui
Protocol: SuiPad
Auditor: MoveBit
Report Date: Apr 2023
Description: The fund function lacks a "fund already full" check, allowing multiple funding transactions. However, upon distribution, only a fixed amount can be distributed.
Lack of Parameter Check
Severity: High
Ecosystem: Sui
Protocol: SuiPad
Auditor: MoveBit
Report Date: Apr 2023
Description: In the withdraw function, penalty calculation may exceed lock.amount, preventing users from withdrawing their stake coins.
Lack of Market Version Check
Severity: High
Ecosystem: Sui
Protocol: Aries Market
Auditor: MoveBit
Report Date: June 2023
Description: The set_reserveconfig_obj function doesn't check for market version, which may result in incorrect market information being set or used.
Missing Market Checks
Severity: High
Ecosystem: Sui
Protocol: Aries Market
Auditor: MoveBit
Report Date: June 2023
Description: The liquidate function may cause the market to not match the current profile due to missing validation checks.
PackMessage is not bound to token type
Severity: High
Ecosystem: Sui
Protocol: MiniMiners
Auditor: MoveBit
Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mini-Miners-Contract-Audit.pdf
Report Date: Apr 2023
Description: PackMessage only checks the number and not the token type, allowing users to exchange different coin types provided that the game ID has corresponding coin types available, enabling token swaps without proper validation.
Missing Zero Check for Added Liquidity
Severity: High
Ecosystem: Sui
Protocol: Sui AMM
Auditor: MoveBit
Report Date: Nov 2022
Description: The liquidity addition function does not check for adding zero liquidity, allowing users to lose their X and Y coins without receiving CoinLP<X,Y> tokens in return.
Incorrect Integer Parsing
Severity: High
Ecosystem: Aptos
Protocol: Echelon
Auditor: Zellic
Report Date: Apr 2025
Description:
The parse_deposit_payload function has a bug in how it handles integer-value parsing. Solidity stores integer values in big-endian format (most significant byte first, reading right to left). The from_bcs module parses integers in little-endian format (least significant byte first, reading left to right).
Nonexistent Token Pair
Severity: High
Ecosystem: Aptos
Protocol: Baptswap
Auditor: MoveBit
Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf
Report Date: Dec 2023
Description:
In the function swap_v2::swap_exact_fee_to_apt(), it attempts to retrieve information about <TokenPairMetadata<X, APT>>. However, under normal circumstances, such information doesn't exist unless created using the create_pair() function. Doing so would entail creating pairs for all tokens with APT, which clearly doesn't align with logic. <TokenPairReserve<X, APT>> faces a similar issue.
Token Extraction Mismatch in Fee Distribution Logic
Severity: High
Ecosystem: Aptos
Protocol: Baptswap
Auditor: MoveBit
Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf
Report Date: Dec 2023
Description:
The function swap_v2.distribute_dex_fees() is used to ensure proper distribution of DEX fees, regardless of the input token. In the case where type_info::type_of
Unexpected Coin Value (Property 2 Not Hold)
Severity: High
Ecosystem: Aptos
Protocol: Liquidswap
Auditor: MoveBit
Report: https://movebit.xyz/reports/Pontem-Liquidity-Swap-Formal-Verification-Audit-Report.pdf
Report Date: Apr 2024
Description:
The property 2 requires: The coin_x and coin_y of a pool should both be zero (at its initial state) or both be nonzero. The coin_x and coin_y after any operation should not be zero for a non-empty pool. swap_inner, mint, burn, flashloan, pay_flashloan function have violated this property.
Unexpected Coin Value (Property 2 Not Hold)
Severity: High
Ecosystem: Aptos
Protocol: Pontem
Auditor: MoveBit
Report: https://movebit.xyz/reports/Pontem-Liquidity-Swap-Formal-Verification-Audit-Report.pdf
Report Date: Apr 2024
Description:
The property 2 requires: The coin_x and coin_y of a pool should both be zero (at its initial state) or both be nonzero. The coin_x and coin_y after any operation should not be zero for a non-empty pool. swap_inner, mint, burn, flashloan, pay_flashloan function have violated this property.
Wrong Type Parameter
Severity: High
Ecosystem: Aptos
Protocol: vibrantX
Auditor: MoveBit
Report: https://movebit.xyz/reports/vibrantX-Final-Audit-Report.pdf
Report Date:
Description:
The type parameter Token4 received by the get_weighted_reserves function is not passed to the weighted_pool::pool_balances_and_weights function, and there is a duplicate of the type parameter Token, so make sure this is by design.
Disabling Withdrawals by Withdrawing Zero-Value FA
Severity: High
Ecosystem: Aptos
Protocol: Aptos Labs Securitize
Auditor: OtterSec
Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Oct 2024
Description:
The ds_token module relies on an invariant that withdrawals must be coupled with deposits. The system tracks the number of active withdrawals utilizing the WithdrawCount resource, ensuring that multiple withdrawals will not coincide (as enforced by assert_withdraw_count ). However, via dispatchable_fungible_asset::withdraw , a user may withdraw a zero-value fungible asset (FA). Since this FA has a value of zero, it does not represent any meaningful asset transfer. Still, the WithdrawCount is incremented to reflect that a withdrawal has occurred.
Utilization of Proper Assertions for Wallet Creation
Severity: High
Ecosystem: Aptos
Protocol: Aptos Labs Securitize
Auditor: OtterSec
Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Oct 2024
Description:
registry_service::add_wallet directly utilizes create_primary_store to create a new primary store for a specified wallet_addr . However, this function will fail if the address already has a primary store. Thus on calling add_wallet or add_wallet_by_investor , if the wallet already has a primary store it will not be added and the execution will fail. Additionally, there is an incorrect assertion in add_wallet_by_investor, which verifies if wallet_addr is a special wallet, unintentionally allowing only special wallets to be added. This behavior may expose the system to risks. The intended functionality, however, is to prevent the registration of special wallets. Therefore, the assertion should check that wallet_addr is not a special wallet. A similar assertion should also be added to add_wallet to prevent the registration of special wallets.