Welcome to the Move Vulnerability Database (MVD) v3.0!

A comprehensive collection of vulnerability patterns in the Move ecosystem.

What's Inside

Vulnerability Patterns - Categorized security issues with examples and severity ratings
Appendix - Audit reports and protocol references
Learning Resources - Curated materials for learning Move security

This resource consolidates 1000+ security vulnerabilities extracted from 200+ public Move audit reports across multiple firms and auditors. The database categorizes vulnerabilities into common patterns—from Input Validation and Business Logic flaws to Access Control and State Management issues—providing a central reference for developers, auditors, and security researchers to understand, recognize, and learn from real-world mistakes in Move codebases.

Vulnerability Patterns	Findings
Business Logic	296
Input Validation	170
Calculation Errors	148
Coding Mistake	76
Access Control	73
State Management	64
Code Optimization	43
Denial of Service	40
Missing Functions	37
Data Inconsistency	31
Oracle Issues	27
Centralization Risk	25
Constant Definition	21
Cross-Implementation	16
Runtime/Development Issues	15
Missing Version Check	12
Gas-related Issues	11
Looping Issues	10
Front-running	7
Collision	5
Inflation Attacks	5
Documentation Mismatch	3
Signature Replay	3
Third-Party Risk	2
Race Condition	1
Total	1141

Data sourced from public Move audit reports by the following auditors/firms:

Audit Firm/Auditor	Report Links
OtterSec	Sampled Public Audit Reports (OtterSec Notion)
MoveBit	MoveBit — Sampled Audit Reports
MoveJay	MoveJay (Jayfromthe13th)
Zellic	Zellic Reports
Spearbit	Spearbit Reports
Cantina	Cantina Reports
Code4Arena	Code4Arena Reports
Certora	Certora Security Reports
Hacken	Hacken Audits
Pashov Audit Group	Pashov Audit Group — Audits
ExVul Security	ExVul Audits
Quantstamp	Quantstamp Reports
SlowMist	SlowMist Reports
Three Sigma	Three Sigma Reports
Asymptotic	Asymptotic Reports
Sherlock	Sherlock Reports

Refer to the Appendix for the full list of reports and protocols.

⚠️ Disclaimer

All findings and summaries in this database are sourced from publicly available audit reports.

I do not own or claim ownership of any reports, documents, or content referenced here — all rights belong to their respective auditors, firms, and project teams.

This repository is an independent, educational, and non-commercial project created to help the community study and understand common vulnerability patterns in the Move ecosystem.

While I aim for accuracy, there may be typos, errors, broken links, or misattributed information.

If you spot any mistakes or missing details, please open an issue or reach out so I can correct them.

💬 Support & Contributions

If you'd like to learn more about the project or support future development, see the About section.

About the Move Vulnerability Database

The Move Vulnerability Database (MVD), maintained by Maverick Security Research, was created to support the growing field of Move security. The MVD aims to:

Help developers identify and understand common coding mistakes.
Provide security researchers, auditors, and bug hunters with patterns and examples to locate vulnerabilities in Move codebases.

The database consolidates findings from public audits, creating a central resource for the Move ecosystem to learn from real-world vulnerabilities.

💬 Support & Contributions

If you’ve found this database useful, consider supporting its continued development. Contributions help fund:

Ongoing curation of Move ecosystem vulnerability data
Updates to audit mappings
Expansion into cross-chain vulnerability pattern analysis

Donation Addresses:

Sui: 0xda0a78ad38da929d16676c7d64fe195cc4becd2985b68bdda7ab991187085614
Ethereum: 0x5F672E842C15C7A9be40B93c9Eb4F78caE389cd1

Your support directly helps maintain and improve open-source security knowledge for the Web3 community.

Thank you,

— MoveMaverick

Vulnerability Patterns Overview

The table below presents the total number of findings for each vulnerability pattern across all analyzed contracts.

Vulnerability Patterns	Findings
Business Logic	296
Input Validation	170
Calculation Errors	148
Coding Mistake	76
Access Control	73
State Management	64
Code Optimization	43
Denial of Service	40
Missing Functions	37
Data Inconsistency	31
Oracle Issues	27
Centralization Risk	25
Constant Definition	21
Cross-Implementation	16
Runtime/Development Issues	15
Missing Version Check	12
Gas-related Issues	11
Looping Issues	10
Front-running	7
Collision	5
Inflation Attacks	5
Documentation Mismatch	3
Signature Replay	3
Third-Party Risk	2
Race Condition	1
Total	1141

As we can see, business logic vulnerabilities account for more than 25% of the database findings. Input validation was the second most common issue, followed by calculation errors.

Next, let's examine the vulnerability patterns in detail, broken down by severity.

Vulnerability Patterns	C	H	M	L	Total
Business Logic	21	58	89	128	296
Input Validation	16	29	34	91	170
Calculation Errors	13	28	61	46	148
Coding Mistake	0	0	0	76	76
Access Control	13	20	14	26	73
State Management	7	14	19	24	64
Code Optimization	0	0	0	43	43
Denial of Service	2	4	27	7	40
Missing Functions	1	3	15	18	37
Data Inconsistency	2	10	10	9	31
Oracle Issues	3	5	11	8	27
Centralization Risk	0	8	10	7	25
Constant Definition	3	2	5	11	21
Cross-Implementation	0	0	2	14	16
Runtime/Development Issues	0	0	10	5	15
Missing Version Check	0	2	1	9	12
Gas-related Issues	0	0	11	0	11
Looping Issues	0	3	3	4	10
Front-running	0	3	2	2	7
Collision	0	0	1	4	5
Inflation Attacks	0	0	1	4	5
Documentation Mismatch	0	0	0	3	3
Signature Replay	0	0	0	3	3
Third-Party Risk	0	0	0	2	2
Race Condition	0	0	0	1	1
Total	81	189	326	545	1141

Based on Criticals and Highs: Business Logic, Input Validation, Calculation Errors, Access Control, and State Management are the top 5 vulnerability classes.

Based on Mediums: Business Logic, Calculation Errors, and Input Validation are the top 3 most commonly found vulnerability patterns.

Coding Mistakes and Code Optimization were the most commonly found Low severity issues.

💡 Note

The Move Vulnerability Database provides a comprehensive overview of vulnerabilities observed across audited Move protocols and serves as a guide to understanding risk concentration. Readers are encouraged to use the data to draw their own conclusions, identify trends, and consider protocol context, design, and specific use cases when assessing potential vulnerabilities.

Access Control — Overview

Missing or flawed authorization checks allow unauthorized users to perform restricted actions.

Access Control	Findings
Critical	13
High	20
Medium	14
Low	26
Total	73

The swap_v2.set_dex_liquidity_fee() function is marked as public(friend), indicating that it is accessible to modules declared as "friends" of the current module.

However, in the protocol, only baptswap_v2::router_v2 is declared as a friend.

The issue arises because the router_v2 contract does not invoke the set_dex_liquidity_fee() method, preventing the protocol from updating the liquidity fee. The function ser_dex_treasury_fee() set_individual_token_team_fee() and set_individual_token_liquidity_fee() also face a similar issue.

Single-step Ownership Transfer Can be Dangerous

Severity: High

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

Single-step ownership transfer means that if a wrong address was passed when transferring ownership or admin rights it can mean that role is lost forever. If the admin permissions are given to the wrong address within this function, it will cause irreparable damage to the contract.

Set Functions Lack of Access Control

Severity: High

Ecosystem: Aptos

Protocol: Superposition

Auditor: MoveBit

Report: https://movebit.xyz/reports/Superposition-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

The set_tenant_pause and set_tenant_liquidation_fee_address functions have no access controls, allowing anyone to set arbitrary numbers, take the profits of interest rates, etc.

Anyone can reset initial price of pool

Severity: High

Ecosystem: Aptos

Protocol: Cetus Concentrated Liquidity Protocol

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Aptos-Audit-Report.pdf

Report Date: Jan 2023

Description:

reset_init_price is a public function.

Public access to register_collateral can lock out CoinTypes from APD

Severity: High

`execute_config_tx_internal` should be `public(package)`

Severity: Low

Ecosystem: Sui

Protocol: Aeon

Auditor: Asymptotic

Report: https://info.asymptotic.tech/aeon-audit-report#262c1aef2c7042b7816a0015ed4a0051

Report Date: Feb 2025

Description:

execute_config_tx_internal should be public(package).

Severity: Low

Ecosystem: Sui

Protocol: Full Sail CLMM

Auditor: Asymptotic

Report: https://info.asymptotic.tech/full-sail-clmm-audit

Report Date: May 2025

Description:

The receive_ref_fee function in the partner module is declared as public, allowing any user to add arbitrary coins to partner fee balances and trigger corresponding events. Malicious actors can manipulate partner accounting by emitting false events, compromising the reliability of the protocol's fee tracking system.

Unprotected Public Function Has Mutable Access to Shared State

Severity: Low

Ecosystem: Sui

Protocol: Cetus DLMM

Auditor: MoveBit

Report: https://drive.google.com/drive/u/0/folders/1d9nv3nJidsbQ0vDT8D1kEuR3rJzK2ULg

Report Date: Sep 2025

Description:

The public function is_allowed_coin accepts a mutable reference ( &mut GlobalConfig ) to the shared object GlobalConfig . Although the current implementation is read-only, its function signature is misleading and violates the principle of least privilege.

Users may arbitrarily decrease the remaining mixes of their SuiFrens

Severity: Low

Ecosystem: Sui

Protocol: MystenLabs Sui

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description: Users may arbitrarily call decrease_remaining_mixes_by_one. Users may supply their SuiFrens and reduce the remaining mix in the object without minting a new SuiFrens. This function also does not check if the remaining_mix is set to None(), aborting the application.

Unrevokeable Minter Capability

Severity: Low

Ecosystem: Sui

Protocol: Ghost Ivy

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description: The Havencompass admin issues MintCaps to minters to allow minting of new GameKeys.

public fun issue_mint_cap(_cap: &mut AdminCap, ctx: &mut TxContext): MintCap {
let mint_cap = MintCap {
id: object::new(ctx)
};
mint_cap

Issued MintCaps may only be burnt with the full cooperation of MintCap owners.

public fun burn_mintcap(mint_cap: MintCap) {
let MintCap { id } = mint_cap;
object::delete(id)

Thus, if a minter turns malicious due to cases such as wallet compromise, then admins would be unable to perform damage control by revoking mint permissions.

Visibility of burn And claim_specified_amount May Change To Private

Severity: Low

Ecosystem: Sui

Protocol: Aftermath Finance Liquid Staking Derivative

Auditor: MoveBit

Report: https://movebit.xyz/reports/Aftermath-Finance-Liquid-Staking-Derivative-Audit-Report.pdf

Report Date: Nov 2023

Description:

In receipt.move both burn and claim_specified_amount function are declared as public friend function, however, neither lsd::staked_sui_vault_state nor lsd::staked_sui_vault call any of them directly.

Unnecessary friend Privileges

Severity: Low

Ecosystem: Sui

Protocol: Dola Protocol

Auditor: MoveBit

Report: https://movebit.xyz/reports/Dola-Protocol-Final-Audit-Report.pdf

Report Date: Feb 2024

Description:

Some functions in the boots.move module have unnecessary friend privileges, such as withdraw_boost_coin , mint_boost_coin , burn_boost_coin , etc., which are only used in this module, but are still given friend privileges, so it's recommended to remove them.

Missing entry in mint_entry and redeem_entry Functions

Severity: Low

Ecosystem: Sui

Protocol: Scallop

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Scallop-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description:

The functions mint_entry and redeem_entry are missing the entry keyword in their declarations. In the Move language, the entry keyword is used to define a function that can be called from outside of the module.

borrow_proposal_request Missing Permission Control

Severity: Low

Ecosystem: Sui

Protocol: Legend of Arcadia

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Legend-of-Arcadia-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description:

borrow_proposal_request does not add any permission restrictions, but the corresponding permission checks are done in the is_proposal_rejected and is_proposal_approved functions.

Incorrect Function Call Permissions

Severity: Low

Ecosystem: Sui

Protocol: Aries Market (Sui)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description:

The function market::new() is only called in market.move, yet its visibility is public (friend).

Optimization of Function Visibility

Severity: Low

Ecosystem: Sui

Protocol: Aries Market (Sui)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description:

The functions get_reserve_detail_mut_by_address() and get_reserve_detail_mut() return mutable objects. It is best not to set this type of function as a public function, as it may bring risks.

Incongruities in Role Management Checks

Severity: Low

Ecosystem: Aptos

Protocol: Aptos Labs Securitize

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

The role management verifications are flawed in multiple functions, resulting in improper access control and inconsistencies between the actual implementation and the documentation.

Flash Loan Accessibility Restriction

Severity: Low

Ecosystem: Aptos

Protocol: Meso Lending

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: July 2024

Description:

In lending_pool, start_flashloan, and end_flashloan are marked as public(friend), implying they may only be called by other modules or addresses that are designated as friends of the module, not by external users directly. This restriction renders the flash loan functionality unusable to the general public, as they will be restricted from triggering these functions.

Limit Bypass Through Stake Coins Invocation

Severity: Low

Ecosystem: Aptos

Protocol: Tortuga

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: June 2023

Description:

stake_router provides two entry points to stake coins: • stake_router::stake_coins- A permissionless staking endpoint. Takes inCoin and returns Coin. • stake_router::stake - Wrapper over stake_coins. Withdraws coins from the signer, verifies a minimum deposit limit, invokes stake_coins and emits a StakeEvent. Currently, there exists a minimum stake requirement imposed in stake. However, users may invoke stake_coins directly to bypass this limit.

Accessibility Contradiction in the Utilization of swap_exact_x_to_y_direct() Function

Severity: Low

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

The function swap_exact_x_to_y_direct() is a friend function, yet it's only called within the current module and not in any other modules. Therefore, it behaves as a private function, which contradicts the intended access permissions for this function.The function swap_exact_y_to_x_direct() and update_pool() also suffers from the same issue.

Lack of #[test] Attribute

Severity: Low

Ecosystem: Aptos

Protocol: StreamFlow

Auditor: MoveBit

Report: https://movebit.xyz/reports/StreamFlow2-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

The init_module_test function is missing the test #[test] attribute tags, missing them would cause the function to be compiled into the program and, since the permissions are public, any user can call the function.

The Admin Lacks the Permission for the BurnExecuteCapability Capability

Severity: Low

Ecosystem: Aptos

Protocol: Merkle Trade Smart Contract

Auditor: MoveBit

Report: https://movebit.xyz/reports/Merkle-Trade-Smart-Contract-Audit-Report.pdf

Report Date: July 2023

Description:

The admin can only register the ExecuteCapability to other addresses, but the admin lacks permission for the burn ExecuteCapability capability. The following code only allows the executor candidate to burn the ExecuteCapability.

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.1-3.3 Core

Auditor: OtterSec

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Ottersec Aave Aptos V3.1-V3.3 Report.pdf

Report Date: Aug 2025

Description:

The asset listing admin may arbitrarily modify reserve configurations via set_reserve_configuration_with_guard, effectively bypassing role separation and increasing governance risk.

Unauthorized initialization function

Severity: Low

Ecosystem: Aptos

Protocol: Yeap Finance

Auditor: SlowMist

Report: https://github.com/slowmist/Knowledge-Base/blob/master/open-report-V2/smart-contract/aptos-smart-contract/yeap-finance%20-%20SlowMist%20Audit%20Report.pdf

Report Date: July 2025

Description:

The Yeap Finance protocol has multiple critical initialization functions that lack proper access control mechanisms, allowing any user to call these functions for system initialization. Attackers may control configuration objects to set malicious parameters.

Business Logic - Overview

Errors in core logic or assumptions that let users exploit intended protocol behavior.

Business Logic	Findings
Critical	21
High	58
Medium	89
Low	128
Total	296

Pool Creation Logic Flaw Allows Single-Asset Liquidity to Generate Dual-Asset Rewards

Severity: Critical

Ecosystem: IOTA Mainnet

Protocol: Pools Finance

Auditor: Hacken

Report: https://hacken.io/audits/pools-finance/sca-pools-finance-pools-contracts-may2025/

Report Date: June 2025

Description:

The Pools Protocol allows the creation of AMM pools where both tokens are identical (e.g., USDC/USDC, IOTA/IOTA), violating fundamental AMM principles. This occurs due to missing validation in the pool creation logic that should prevent same-token pairs. AMMs are designed to facilitate exchanges between different assets. Same-token pools are economically meaningless and create artificial liquidity that can be exploited for disproportionate rewards.

Missing Activation Epoch Check in Join

Severity: Critical

Ecosystem: Sui

Protocol: Walrus

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2025

Description: StakedWal in the withdrawal state only checks the withdraw_epoch, while the activation epoch check is missing. This oversight causes reward calculation issues and potential exploitation of the reward distribution mechanism.

Severity: Critical

Ecosystem: Aptos

Protocol: Thala

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description:

Logic Flaw in Time Check

Severity: Critical

Ecosystem: Aptos

Protocol: Aptos Labs Securitize

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

is_block_flowback_end_time_ok is checking the condition incorrectly. If block_flowback_end_time is zero, the first condition ( block_flowback_end_time != 0 ) evaluates to false, and the function will never abort, as the second condition ( timestamp < block_flowback_end_time ) will also evaluate to false because timestamp::now_seconds will always be greater than or equal to zero.

Incorrect Issuance Value Recording

Severity: Critical

Ecosystem: Aptos

Protocol: Aptos Labs Securitize

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

compliance_service::create_issuance_information explicitly sets value to zero rather than utilizing the _value parameter, which implies that all recorded issuances will have a value of zero instead of the actual issuance amount. Because every issuance is recorded with a value of zero, the issuance information stored in issuances_values will not accurately represent the actual amounts.

Incorrect Lock Removal Logic

Severity: Critical

Ecosystem: Aptos

Protocol: Aptos Labs Securitize

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

remove_lock_record_for_investor in lock_manager is intended to swap the lock record at lock_index with the last lock in the investor’s lock list, then reduce the count of locks by one. However, the implementation incorrectly overwrites the lock at lock_index with itself, which implies that the last lock is removed instead of the one at lock_index .

Severity: High

Ecosystem: Sui

Protocol: Aeon

Auditor: Asymptotic

Report: https://info.asymptotic.tech/aeon-audit-report#262c1aef2c7042b7816a0015ed4a0051

Report Date: Feb 2025

Description: get_vault_id_by_address assumes that NetworkAddress can be in only one vault , but that is not checked by execute_config_add_vault or execute_config_vault_edit.

This allows an address to be inadvertently or maliciously be set into two different vaults — when approving configs, it is easy to miss that an address has been added somewhere in the past. This can easily lead to bypassing policies which black- or white- list vaults.

Severity: High

Ecosystem: Sui

Protocol: Mayan Sui

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2025

Description: The addr_dest parameter is not a real address and cannot receive funds, leading to loss of funds.

Repeated Invocation Resulting in Excessive Claims

Severity: High

Ecosystem: Sui

Protocol: Mysten Republic Security Token

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2025

Description: Users can invoke the claim function multiple times for the same entitlement, allowing them to drain more tokens than intended from the protocol.

Flawed Version Validation Check

Severity: High

Ecosystem: Sui

Protocol: Hop Aggregator

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description: The version validation check incorrectly compares config.version against itself, making the validation ineffective and potentially allowing incompatible versions to be used.

Missing Invariant Checks

Severity: High

Ecosystem: Sui

Protocol: Aftermath

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description: The protocol does not verify that new_invariant is equal to or greater than old_invariant, which could lead to protocol state inconsistencies and potential value extraction.

Minting of Suifrens with Insufficient Mixing Limit

Severity: High

Ecosystem: Sui

Protocol: MystenLabs Sui

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description: Due to a typo during mixing, the function uses the wrong mixing limit, potentially allowing users to mint Suifrens beyond the intended constraints.

Incorrect Domain Name Field Retrieval

Severity: High

Ecosystem: Sui

Protocol: MystenLabs Sui

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description: The helper function for retrieving domain_names fields returns incorrect values under two circumstances: (1) when the domain is a normal domain, it returns an empty string for default_domain_name, and (2) when the domain is a subdomain of addr.reverse, it returns the default domain name without validation.

Cooldown Bypass

Severity: High

Ecosystem: Sui

Protocol: Elixir

Auditor: Pashov

Report: https://github.com/pashov/audits/blob/master/team/pdf/Elixir-security-review_2025-08-17.pdf

Report Date: Aug 2025

Description: An incorrect timestamp comparison allows users to bypass the cooldown period. The assertion assert!(current_time >= cooldown.cooldown_end || management.cooldown_duration == 0, EInvalidCooldown) uses the wrong comparison operator, allowing actions before the cooldown has expired.

Incorrect Function Logic in sub_total_staked_unsafe

Severity: High

Ecosystem: Sui

Protocol: Volo

Auditor: MoveBit

Report: https://movebit.xyz/reports/Volo-Smart-Contract-Audit-Report.pdf

Report Date: Sep 2023

Description: When both branch judgments in the sub_total_staked_unsafe function fall to else cases, last_total_staked is subtracted twice. This affects the value of get_ratio calculation, causing the ratio to become larger and subsequently impacting reward calculations.

Incorrect Sort Function Implementation

Severity: High

Ecosystem: Sui

Protocol: Volo

Auditor: MoveBit

Report: https://movebit.xyz/reports/Volo-Smart-Contract-Audit-Report.pdf

Report Date: Sep 2023

Description: The sorting logic of the sort_validators function is flawed, resulting in validators not being sorted according to vldr_prior size as intended.

Logic Flaw in minted_buck_amount

Severity: High

Ecosystem: Sui

Protocol: Bucket

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Bucket-Protocol-Smart-Contract-Audit-Report.pdf

Report Date: Jun 2023

Description: There is a critical logic flaw in the calculation of minted_buck_amount that could lead to incorrect token minting amounts.

Wrong Use of new_participants_by_weight

Severity: High

Ecosystem: Sui

Protocol: Legend of Arcadia

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Legend-of-Arcadia-Smart-Contract-Audit-Report.pdf

Report Date: Jun 2023

Description: The participants_by_weight vec_map incorrectly obtains keys from new_participants_by_weight instead of from participants_by_weight, leading to incorrect participant weight calculations.

Authentication Logic Error

Severity: High

Ecosystem: Sui

Protocol: Typus Finance

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Typus-Finance-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: The get_auction_max_size function lacks proper verification, and the remove_authorized_user logic is backwards—it checks if the user does not exist rather than if they exist, causing authentication failures.

Validating Errors When Adding to Whitelist

Severity: High

Ecosystem: Sui

Protocol: KriyaDEX

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/KriyaDEX-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: The assert statement is backwards when adding addresses to the whitelist in set_whitelist_address_config(), preventing new addresses from being added to the whitelist.

Receive Return Values in Incorrect Order

Severity: High

Ecosystem: Sui

Protocol: KriyaDEX

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/KriyaDEX-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: In the get_reserves function, return values are received in the wrong order, causing incorrect calculation of amounts during swapping and liquidity addition operations.

Inconsistent Token Ratios

Severity: High

Ecosystem: Sui

Protocol: MovEX

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/MovEx-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: When adding liquidity, the number of liquidity tokens should be calculated based on the ratio of added tokens to the pool. Currently, excess money is sent to the pool instead of being returned to the user.

LSP Value Should Be Greater Than 0

Severity: High

Ecosystem: Sui

Protocol: MovEX

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/MovEx-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: When adding liquidity, the number of liquidity tokens returned should be greater than 0, otherwise users cannot retrieve their tokens. A validation check needs to be added.

No Limit to Swap

Severity: High

Ecosystem: Sui

Protocol: MovEX

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/MovEx-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: Due to blockchain delays, the price when a swap is submitted may differ from what the user receives. A minimum min_out parameter should be implemented with a condition that the output must be greater than or equal to min_out.

Incorrect Protocol Fee Handling

Severity: High

Ecosystem: Sui

Protocol: MovEX

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/MovEx-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: If protocol fees are not withdrawn, they will be incorrectly withdrawn by users who add liquidity, leading to unfair fee distribution.

Random Design Flaws

Severity: High

Ecosystem: Sui

Protocol: Cetus Concentrated Liquidity Protocol

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Sui-Contract-Audit-Report.pdf

Report Date: Mar 2023

Description: In random.move, when the seed parameter of functions seed and seed_rand is 0, all random numbers generated will be 0. This is used in skip_list, and if misused with a 0 seed, it will lead to an endless loop in the skip_list implementation.

Data Integrity and System Reliability Issue (Missing Data Check)

Severity: High

Ecosystem: Sui

Protocol: Studio Mirai

Auditor: MoveJay

Report: https://github.com/Jayfromthe13th/Studio-Miria-audit

Report Date: Feb 2025

Description: The protocol lacks validation to ensure that object IDs match during critical operations, potentially leading to data integrity issues and system reliability problems.

User can bypass MAX_EXPIRATION when extend expiration

Severity: High

Ecosystem: Initia

Protocol: Initia Move

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-01-initia-move

Report Date: Apr 2025

Description:

In the extend_expiration function, the validation for the duration is incorrect, allowing the user to bypass MAX_EXPIRATION.

Extending a domain’s expiration even after the grace period impacts domain buyers

Severity: High

Ecosystem: Initia

Protocol: Initia Move

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-01-initia-move

Report Date: Apr 2025

Description:

The name_service.move module allows users to register domain names. If anyone wants to register an already purchased domain, they can only do so once the expiration_date + grace_period for that domain has passed. The name_service.move module allows anyone to call extend_expiration for any domain, which is a feature (according to sponsors).

The main issue is that the extend_expiration() function allows users to extend the expiration of a domain even after the grace period has ended, which is unintended behavior.

As a result, users, multi-sig owners of the actual domain name, or attackers can frontrun and attempt to call extend_expiration() after the grace period has ended, even if other users are trying to buy the same domain name using register_domain().

This breaks a key invariant of the protocol, leading to genuine users being negatively impacted and experiencing a poor user experience.

Incorrect Slippage Check

Severity: High

Ecosystem: Aptos

Protocol: Hyperion Smart Contracts

Auditor: ExVul

Report: https://github.com/ExVul-Sec/AuditReport/blob/main/Smartcontract/Hyperion%20Smart%20Contrat%20Audit%20Report-Exvul.pdf

Report Date: Apr 2025

Description:

Slippage protection logic has a backwards condition.

Liquidation logic allows the liquidator to liquidate more than it should

Severity: High

Ecosystem: Aptos

Protocol: AAVE v3.1-3.3

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.1-V3.3%20Report.pdf

Report Date: June 2025

Description:

The Move codebase has incorrectly implemented a feature and will recalculate the debt when the userReserveDebtInBaseCurrency is lower than the totalDefaultLiquidatableDebtInBaseCurrency.

actual_collateral_to_liquidate is burned instead of actual_debt_to_liquidate

Severity: High

Ecosystem: Aptos

Protocol: AAVE v3.1-3.3

Auditor: Certora

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Certora%20Aave%20Aptos%20Core%20V3.1-V3.3%20Report.pdf

Report Date: Apr 2025

Description:

The liquidation_call() function contains an issue in the burn_debt_tokens() function call. It incorrectly passes actual_collateral_to_liquidate as the debt amount to burn, instead of actual_debt_to_liquidate.

This mismatch would lead to incorrect debt burning during liquidations, causing debt tokens to be either overly or insufficiently burned or a denial of service on the liquidation . The amount of debt being burned should correspond to the actual debt being liquidated, not the collateral amount.

Incorrect implementation of reverse iterator

Severity: High

Ecosystem: Aptos

Protocol: Laminar Markets

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Laminar%20-%20Zellic%20Audit%20Report.pdf

Report Date: Oct 2022

Description:

The wrong node is checked.

Duplicate call in coin register

Severity: High

Ecosystem: Aptos

Protocol: Laminar Markets

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Laminar%20-%20Zellic%20Audit%20Report.pdf

Report Date: Oct 2022

Description:

The register_staking_account calls coin::register twice.

Order checker functions use full order size rather than remaining order size

Severity: High

Ecosystem: Aptos

Protocol: Laminar Markets

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Laminar%20-%20Zellic%20Audit%20Report.pdf

Report Date: Oct 2022

Description:

In book::can_bid_be_matched and book::can_ask_be_matched instead of adding remaining size of orders, it adds up full sizes of these orders. Change let bid_size = (order::get_size(bid) as u128); to let bid_size = (order::get_remaining_size(bid) as u128);

Incorrect Assertion in deposit_manager

Severity: High

Ecosystem: Aptos

Protocol: Echelon

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Echelon%20-%20Zellic%20Audit%20Report%20(January).pdf

Report Date: Jan 2025

Description:

There is an assertion that always fails. While the msg length is always greater than 65 bytes, taking the module of the length by 32 will always result in a value less than 32, making it impossible to equal 65.

There is No Slippage Protection During The Distribution of DEX Fees

Severity: High

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

During this exchange process, there is an absence of slippage protection.

Initializing fee_to As ZERO_ACCOUNT May Result In Transferring Fees to The Zero Address

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 init_module function, initializing fee_to as ZERO_ACCOUNT means that if the set_fee_to function is called to set a new address for fee reception, swap fees will be transferred to the zero address.

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() != type_info::type_of(), the line coin_x_out = coin::extract(&mut metadata.balance_x, amount_in) extracts the token amount from metadata.balance_x using the user-input amount_in. However, it seems that the intended behavior might be to use amount_to_liquidity + amount_to_treasury instead of amount_in.

refund_entry Function Can Be Called Multiple Times

Severity: High

Ecosystem: Aptos

Protocol: MoveGPT

Auditor: MoveBit

Report: https://movebit.xyz/reports/MoveGPT-Final-Audit-Report.pdf

Report Date: Apr 2024

Description:

The refund_entry function did not update the user's status after the user was refunded resulting in the user being able to call refund_entry multiple times and reduce the value of total_bought at will. Also the withdraw_round function operator can be called multiple times.

Function Does't Return

Severity: High

Ecosystem: Aptos

Protocol: vibrantX

Auditor: MoveBit

Report: https://movebit.xyz/reports/vibrantX-Final-Audit-Report.pdf

Report Date: Jan 2024

Description:

When the token is not sorted before, the function will be recalled, and the execution of the previous function is not terminated, which will cause the code to be executed twice.

Config update error

Severity: High

Ecosystem: Aptos

Protocol: PatronusFi

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/PatronusFi-Contract-Audit-Report.pdf

Report Date: Mar 2023

Description:

The update function should judge the new_cfg, if new_cfg exceeds limitations of assert, it would be set for the first time, and could not be set later.

Logical Error

Severity: High

Ecosystem: Aptos

Protocol: PatronusFi

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/PatronusFi-Contract-Audit-Report.pdf

Report Date: Mar 2023

Description:

In vault.move, when borrow_cap.temporary is true, vault.paused will be verified as true then set to false, in the next if statement, vault.paused will already be paused and the contract will always panic.

Freeze Bridge with Invalid Sender

Severity: High

Ecosystem: Aptos

Protocol: LayerZero

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Sep 2022

Description:

Only the bridge UA is intended to send messages to the bridge contract. However, this behavior is not enforced at the relayer level. any UA can send messages to any other endpoint.

Amend Order Missing Refund

Severity: High

Ecosystem: Aptos

Protocol: Laminar Markets

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2022

Description:

In the book::amend_bid_order function, when a user tries to decrease the size of an order having the same price, the size of the order gets reduced silently without a refund. Users should be refunded when the size is reduced.

Deducting Vault Interest When Repaying Debt

Severity: High

Ecosystem: Aptos

Protocol: Thala Labs

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2023

Description:

In the protocol module, repay_internal is used to repay amounts borrowed from the vault. However, when repaying the borrowed amount, the interest should also be cleared in addition to the debt.Although the protocol uses fees::absorb_fee to calculate and absorb the repaid interest amount, this amount is not subtracted from the vault.interest. Consequently, a user is unable to clear the interest in their vault, even though it is absorbed from the repayment amount.

Improper Accumulator Updates In V2 Mode

Severity: High

Ecosystem: Aptos

Protocol: Thala

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description:

The stake and unstake functions update the stake amount of the user. These functions also calculate the amount of rewards accrued until that time and store it, and then update the accumulator on the user pool. In the recent changes introducing v2 mode for farming, when v2 mode is enabled, the thl rewards for a user are not accrued in stake and unstake; this results in improper rewards for users.

Deducting Vault Interest When Repaying Debt

Severity: High

Ecosystem: Aptos

Protocol: Thala

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description:

In the protocol module, repay_internalis used to repay amounts borrowedfrom the vault. In addition to the debt, clearing the interest should be done when repaying the borrowed amount. Although the protocol uses fees::absorb_fee to calculate and absorb the repaid interest amount, the protocol does not subtract this amount from vault.interest. Consequently, a user is unable to clear the interest in their vault, even though the protocol absorbs it from the repayment amount.

Removal Of Active Bin

Severity: High

Ecosystem: Aptos

Protocol: Pontem clmm

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Aug 2023

Description:

The vulnerability arises when a liquidity provider becomes the sole provider for a particular price range, i.e., the active bin. This situation may temporarily disrupt the swapping logic of the CLMM. In pool, swap_inner handles the swapping of assets between users, and when it attempts to access the data associated with the active bin utilizing its ID, it assumes that active_bin_id exists in the pool.bins table. However, if a liquidity provider is the only one providing liquidity for this particular active bin, it is possible that they decide to remove their liquidity from that bin. When a liquidity provider removes their liquidity from a bin, it triggers the burn logic, which removes the liquidity providers. This results in the bin being entirely removed from the pool.bins table, effectively erasing the active bin.

Bin Price Manipulation

Severity: High

Ecosystem: Aptos

Protocol: Pontem clmm

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Aug 2023

Description:

In this CLMM, there are multiple bins, each having its price range where users may add liquidity. This vulnerability allows a malicious user to manipulate the price of shares in a specific bin within the CLMM. This manipulation may be exploited to artificially inflate the price of shares in that bin to extremely high values, creating unfavorable conditions for other participants and potentially blocking or monopolizing that bin. The user may profit by burning the last share in the manipulated bin.

ThalaSwapV2

Severity: High

Ecosystem: Aptos

Protocol: ThalaSwapV2

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Aug 2024

Description:

The vulnerability concerns the lack of slippage checks within the entry functions in pool. Slippage parameters protect the protocol from accepting values that are drastically different from the current market conditions due to market volatility or large trades in the pool. This can result in inaccurate transactions within the pool, potentially affecting users unfairly.

Flaw in Full Transfer Checks

Severity: High

Ecosystem: Aptos

Protocol: Aptos Securitize

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

In compliance_service::pre_deposit_check_regulated , the get_force_full_transfer condition checks if full transfers are enforced when the transfer originates from the US. If this condition is true, the function immediately aborts the transfer with the error code EONLY_FULL_TRANSFER. If get_force_full_transfer is enabled and the transfer originates from the US, any transfer to the platform wallet is rejected, regardless of whether the transfer satisfies the required full transfer conditions. As a result, valid transactions may be blocked.

Incorrect Reward Initialization

Severity: High

Ecosystem: Aptos

Protocol: Aptos Securitize

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

The issue in the lending core farming module occurs when a user is accruing a specific reward for the first time. When a user first starts accruing a reward, their last_acc_rewards_per_share is set to pool_acc_reward_per_share . This is problematic, as users who had staked before the reward was introduced will not receive any rewards for the period between their staking and their first accrue_user_pool_reward call.

Missing Solvency Check

Severity: High

Ecosystem: Aptos

Protocol: Echleon

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2025

Description:

isolated_lending::withdraw_internal lacks a check for bad debt, allowing users to withdraw supplied assets even if their position is underwater. This creates a vulnerability where users may extract value even though they are insolvent. If the borrowed value exceeds collateral, supply shares should not be withdrawable, as they may be needed to cover the shortfall.

kAPT Double Minting

Severity: High

Ecosystem: Aptos

Protocol: Kofi Finance Contacts

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2025

Description:

rewards_manager::update_rewards calculation does not account for minting fees. When stake is added to a delegation pool, an add_stake fee is deducted if the validator being delegated to is producing rewards for that epoch. This fee is temporarily subtracted from the delegator’s active stake and is refunded in the next epoch. The protocol tracks this fee separately and allows the admin to collect it asynchronously. Despite this, the staked APTs are still marked as rewards by the update_rewards function, causing it to mint kAPT on their behalf. Later, when the admin collects these fees, kAPT is re-minted for the same amount, resulting in double-minting and an immediate depegging of kAPT .

Absence of Verification for Reward Start Timestamp

Severity: High

Severity: Medium

Ecosystem: Sui

Protocol: Cetus DLMM

Auditor: MoveBit

Report: https://drive.google.com/drive/u/0/folders/1d9nv3nJidsbQ0vDT8D1kEuR3rJzK2ULg

Report Date: Sep 2025

Description:

A critical fee allocation error has been identified in the swap operation's fee handling logic. The issue arises from inconsistent fee processing between the bin level and the pool level.

Bin Level: accumulate_fee(fee_amount, 0) allocates the entire swap fee to liquidity providers. Pool Level: Simultaneously, the protocol fee is calculated and collected from the same fee. Result: The protocol fee is effectively double-charged, meaning an additional fee is levied on users.

Collect-Fee/Reward Pause Can Be Bypassed By Closing Positions

Severity: Medium

Ecosystem: Sui

Protocol: Cetus DLMM

Auditor: CertiK

Report: https://drive.google.com/drive/u/0/folders/1d9nv3nJidsbQ0vDT8D1kEuR3rJzK2ULg

Report Date: Sep 2025

Description:

The close_position function implicitly performs three actions at once: it removes liquidity, collects trading fees, and collects accrued rewards (the close certificate carries rewards that can be withdrawn later). However, close_position calls operation_check with only restriction::remove_kind() . Because operation_check only checks disable_remove for REMOVE and does not also check the collect toggles, a user can collect fees and rewards by closing their position even when the pool has collect operations paused (disable_collect_fee = true and/or disable_collect_reward = true).

Severity: Medium

Ecosystem: Sui

Protocol: Cetus DLMM

Auditor: CertiK

Report: https://drive.google.com/drive/u/0/folders/1d9nv3nJidsbQ0vDT8D1kEuR3rJzK2ULg

Report Date: Sep 2025

Description:

In pool.move, the reward_settle function checks pool.bin_manager.is_active_bin_empty(pool.active_id) before it checks pool.reward_manager.emergency_reward_pause() . This branch order makes the pause ineffective whenever the active bin is empty. In that case, the code calls rollover_refunds_into_remaining_time(accumulated_rewards, clk) and returns without ever consulting the emergency pause flag.

Incorrect Fee Rate Used in flash loan

Severity: Medium

Ecosystem: Sui

Protocol: Momentum CLMM

Auditor: Asymptotic

Report: https://1760493472-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvMYfd5Y4I2ZxHbqdOD88%2Fuploads%2FVUTBtknlPDNNKXFHp9zw%2FAsymptotic Audit of Momentum CLMM.pdf?alt=media&token=e58fb859-d4be-4b65-ac1d-92df0790b6cf

Report Date: Aug 2025

Description:

The flash loan function currently applies the pool’s swap fee rate when calculating flash loan fees, instead of the dedicated flash loan fee rate. By design, flash loan fee rate is initialized to zero when the pool is created, while swap fee rate is always set to a nonzero value. As a result, users are incorrectly charged swap fees for flash loans. Furthermore, the flash loan fee rate is hardcoded at pool creation and cannot be updated. This immutability makes the existence of a separate flash loan fee rate parameter largely redundant.

Handling Unopened Pools to Prevent User Interaction Failures

Severity: Medium

Ecosystem: Sui

Protocol: Momentum

Auditor: MoveBit

Report: https://1760493472-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvMYfd5Y4I2ZxHbqdOD88%2Fuploads%2FKo0UYHCVcSEui2ZTJSA6%2FMMT Audit Report-2025-11-13.pdf?alt=media&token=8f2d91ba-2a20-43d6-8dd9-c9aa7abf8f91

Report Date: Nov 2025

Description:

When a pool has not yet been opened (i.e., when admin::init_reward sets the start_time to a future timestamp), user interactions may cause pool.last_update_at to exceed effective_update_time . This results in an underflow protection error in the subtraction effective_update_time - pool.last_update_at within the sync_or_advance_epoch function, causing user interactions to fail.

Users can deposit before the pool is initialized

Severity: Medium

Ecosystem: Sui

Protocol: Momentum

Auditor: Sherlock

Report: https://1760493472-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvMYfd5Y4I2ZxHbqdOD88%2Fuploads%2FCoI611HTaCx34uzF6O8j%2F2025_11_12_Final_Momentum_Collaborative_Audit_Report_1762918494.pdf?alt=media&token=216a66b1-491d-405a-a57f-b1b9f530ab78

Report Date: Nov 2025

Description:

With default zeros on deployment, sync_or_advance_epoch early-returns and deposit still passes the “synced” check because last_update_at == reward_end_at which are both zero, allowing deposits before epoch_data is seeded.

Single epoch claim can target a not-yetcreated epoch id and abort

Severity: Medium

Ecosystem: Sui

Protocol: Momentum

Auditor: Sherlock

Report Date: Nov 2025

Description:

The claim_reward_single_epoch can compute claim_epoch_id = last_claimed_epoch + 1 within the same epoch and immediately try to read epoch_data for that future epoch. If the next epoch hasn’t been finalized or created yet, this path aborts.

Type Order Validation Bypass in Pool Key Generation

Severity: Medium

Ecosystem: Sui

Protocol: Full Sail CLMM

Auditor: Asymptotic

Report: https://info.asymptotic.tech/full-sail-clmm-audit

Report Date: May 2025

Description:

The new_pool_key function in the factory module contains a critical flaw in its type order validation logic. The issue occurs because the function modifies the comparison buffer (bytes_a) during processing but uses the modified length for validation checks, rather than the original length.

Severity: Medium

Ecosystem: Supra

Protocol: Dexlyn Perp DEX

Auditor: Hacken

Report: https://hacken.io/audits/dexlyn/sca-dexlyn-perp-dex-jul2025/

Report Date: Sep 2025

Description:

The Dexlyn perpetual DEX protocol has a leverage boundary calculation inconsistency that causes valid user positions to be unexpectedly rejected. Users who believe they are opening positions within the advertised 150x leverage limit experience transaction failures due to fees being deducted from collateral before leverage validation.

The protocol calculates leverage using effective collateral (user collateral minus fees) rather than provided , causing the actual leverage to exceed the 151x buffer limit even when users offer what appears to be adequate collateral for 150x leverage.

Blocklisted Status is Not Persistent Across Committee Rotations

Severity: Medium

Ecosystem: IOTA Mainnet

Protocol: Echo Protocol Bridge

Auditor: Hacken

Report: https://hacken.io/audits/echo-protocol/sca-echo-protocol-bridge-iota-jul2025/

Report Date: Aug 2025

Description: A committee member's blocklisted status is not persistent. If a committee rotation were possible, any previously blocklisted member would be automatically reinstated as a fully trusted member in the new committee. This flaw would force governance to re-apply blocklists for known bad actors after every single epoch, an operationally fragile and unrealistic security practice.

Initial Liqudity Price Manipulation

Severity: Medium

Ecosystem: IOTA Mainnet

Protocol: Pools Finance

Auditor: Hacken

Report: https://hacken.io/audits/pools-finance/sca-pools-finance-pools-contracts-may2025/

Report Date: June 2025

Description:

The issue is located in the calculate_amount_for_liquidity_internal function. When a pool has zero liquidity (i.e., reservea 0 && reserveb 0), the function does not enforce any price ratio. It simply returns the amount_a_desired and amount_b_desired values provided by the user, setting them as the official starting price for the pool.

Malicious attacker can make messages sent through the bridge unfinalized

Severity: Medium

Ecosystem: Supra Chain

Protocol: Dexlyn Hyperlane

Auditor: Hacken

Report: https://hacken.io/audits/dexlyn/sca-dexlyn-hyperlane-monorepo-dec2024/

Report Date: Dec 2024

Description:

It was identified that on the MOVE side the relayer directly calls handle_message in the recipient contract address and the recipient contract in turns calls handle_message of the mailbox for verification and validation. However, there is no way to assert in the mailbox that the message that is going to get verified was actually being called from the intended recipient contract or not.

As a consequence, a potential attacker is able to create a malicious contract, handling the call to handle_message, which will be called by him in the context of a completely correct message. The recipient is not verified - it may therefore be different than the intended message recipient.

Fee Manipulation via Improper LP Coin Split

Severity: Medium

Ecosystem: Sui

Protocol: Aftermath Market Making

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Jan 2025

Description:

New coin value can be set to 0, causing issues. When the UserLpCoin with a non-zero LP balance but zero provided_value_usd is introduced, although this UserLpCoin has no contribution to the provided_value_usd , it is still entitled to a withdrawal of funds based on its LP balance. This withdrawal bypasses the fee calculation mechanism, since the fees are determined by the profits derived from balance_to_withdraw and provided_value_usd .

Blocklist Validation Order Mismatch

Severity: Medium

Ecosystem: Sui

Protocol: Sui Bridge

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2024

Description:

Because it scans through vector, if stored out of order, then it may not find. In committee::execute_blocklist, the member_idx variable is not reset to zero at the beginning of each iteration of the outer while loop. Thus, if a blocklist contains Ethereum addresses in a different order than the order of committee members stored in self.members, the function may fail to find the corresponding committee member even though the member is present in the list.

Incorrect Function Call

Severity: Medium

Ecosystem: Sui

Protocol: Sui Axelar Gateway V2

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2024

Description:

Within estimate function, get_estimate is called rather than obtaining true balances.

Unsafe Role Removal

Severity: Medium

Ecosystem: Sui

Protocol: Cetus

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2024

Description:

Uses subtraction to remove roles, additional roles may be added or subtracted by removing an unset role.

Reward Accumulation During Inactive Time Period

Severity: Medium

Ecosystem: Sui

Protocol: Bluefin Spot

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Nov 2024

Description:

Rewards are account for during between previous reward time and new start time and also during inactive time.

Lack of Configurable Delay Setting in Timelock

Severity: Medium

Ecosystem: Sui

Protocol: Lombard Finance

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Dec 2024

Description:

Has feature to set delay, but within code uses hard-coded variable of MS_24_HOURS.

Arbitrary Delete Of Orders

Severity: Medium

Ecosystem: Sui

Protocol: Maven

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2023

Description:

In maven.move, any user can call execute_object_operation with the incorrect ASSET generic and pop the order from execution without properly executing it, as the precheck fails and returns false. This allows anyone to stop others from executing the object operations.

Minimum Stake Bypass in delegation_service

Severity: Medium

Ecosystem: Aptos

Protocol: Tortuga

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2022

Description:

The Tortuga protocol operates on top of the delegation_service module which operates the pools and computes rewards for the validators and delegators. While most users will delegate indirectly through Tortuga (stake_router), validators can also receive direct delegations through the delegation_service API. Users who want to delegate directly can invoke delegation_service::delegate and provide an amount. Internally, this function ensures that the amount provided meets a minimum delegation amount (which is configurable by the pool owner). While this check ensures that the instantaneous delegation amount is above the required minimum, this limit is not imposed upon withdrawals. Therefore, a user can simply delegate some amount of stake higher than min_delegation_amount and then immediately withdraw a large portion to effectively bypass this limit.

Validators can Manipulate Commission Rates

Severity: Medium

Ecosystem: Aptos

Protocol: Tortuga

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2022

Description:

Registered validators can receive stake from the protocol or directly from individual delegators. Either way, a commission, set by the validator, must be paid. The protocol_commission must be smaller than current_commission, and both have to be smaller or equal to ManagedStakePool max_commission, which is set by the protocol in delegation_service::initialize. The issue is that validators have the ability to drastically increase the commission percentage at any given time. This allows a malicious validator to set a very small commission and later on increase it by a large margin. Given that the stakes are locked via lockup periods (30 days), the validator can profit from a large commission for a long period of time

Liquidate Minimum Debt Vaults

Severity: Medium

Ecosystem: Aptos

Protocol: Argo

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2022

Description:

Argo enforces a minimum debt threshold when repaying vaults. Unfortunately, liquidate_repay also enforces that the collateral ratio of the vault isn’t repaid fully. This means that vaults that are close to the minimum debt threshold cannot be liquidated.

Issue While Starting New Epoch In Farming

Severity: Medium

Ecosystem: Aptos

Protocol: Thala

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description:

If an epoch ends earlier than epoch_end_seconds, the code sets farming.epoch_end_seconds to epoch_now. If the current epoch’s starting time is in the future and ending this epoch is attempted, farming.epoch_end_seconds is set to farming.epoch_start_seconds, which is the future time even though the epoch has ended immediately. Now, starting another epoch is impossible until we reach farming.epoch_start_seconds.

Minimum Stake Bypass

Severity: Medium

Ecosystem: Aptos

Protocol: Tortuga

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: June 2023

Description:

A user may delegate some amount of stake higher than min_delegation_amount, then immediately withdraw a large portion to effectively bypass this limit.

Validators Manipulating Commission Rates

Severity: Medium

Ecosystem: Aptos

Protocol: Tortuga

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: June 2023

Description:

This allows a malicious validator to set a very small commission and increase it by a large margin later on. Since 30-day lockup periods lock the stakes, the validator may profit from a large commission for a long time.

Reward Distribution Inconsistency

Severity: Medium

Ecosystem: Aptos

Protocol: Aries Markets

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2024

Description:

When updating the reward configuration with a new reward_per_day, the reward_per_share value, which represents the reward per share, should be adjusted to reflect the new configuration. However, the update_reward_config function fails to calculate the previous unclaimed rewards and update the farm.timestamp based on the old reward_per_day prior to updating the reward_per_share before applying the new configuration.

Potential Deposit Lockup

Severity: Medium

Ecosystem: Aptos

Protocol: Aries Markets

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2024

Description:

There is a potential vulnerability in the logic of deposit_coin_to_reserve. It prioritizes repaying existing loans with the repay_coin before utilizing it for minting liquidity provider tokens. The issue arises because some coins may not be allowed as collateral within the Aries Markets protocol. If the repay_coin is one such coin, it gets utilized for repayment first. But since the minted liquidity provider tokens represent the remaining deposit_coin (of the same type as repay_coin), adding them as collateral fails. Thus, even if repay_coin amount is enough to cover the entire loan, the call will fail, because it may not be utilized as collateral, rendering the user without standing debt and potential liquidation penalties.There is a potential vulnerability in the logic of deposit_coin_to_reserve. It prioritizes repaying existing loans with the repay_coin before utilizing it for minting liquidity provider tokens. The issue arises because some coins may not be allowed as collateral within the Aries Markets protocol. If the repay_coin is one such coin, it gets utilized for repayment first. But since the minted liquidity provider tokens represent the remaining deposit_coin (of the same type as repay_coin), adding them as collateral fails. Thus, even if repay_coin amount is enough to cover the entire loan, the call will fail, because it may not be utilized as collateral, rendering the user without standing debt and potential liquidation penalties.

Inconsistency in Swap Route Validation

Severity: Medium

Ecosystem: Aptos

Protocol: Echelon

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2025

Description:

lending_leverage::loop_supply_x_borrow_y_fa , there is a pool_route and an associated asset_out_route . These define how the borrowed asset Y is swapped back to the supplied asset X via a multi-hop route. loop_supply_x_borrow_y_fa contains incorrect assertions that check the start of the swap route against the input token and the end against an un-utilized out_metadata parameter. This logic is reversed and unnecessary. The route should instead start with the borrowed token ( Y ) and end with the input token ( X ), since the goal is to loop borrowed assets back into the original collateral.

Lack of two-step ownership transfer

Severity: Medium

Ecosystem: Sui

Protocol: Matrixdock

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Matrixdock%20XAUm%20-%20Zellic%20Audit%20Report.pdf

Report Date: July 2025

Description:

The protocol lacks a two-step ownership transfer and validation of the new owner’s address; should include an address validity check.

Blacklist Logic Inconsistencies

Severity: Medium

Ecosystem: Sui

Protocol: Elixir

Auditor: Pashov

Report: https://github.com/pashov/audits/blob/master/team/pdf/Elixir-security-review_2025-08-17.pdf

Report Date: Aug 2025

Description:

The implementation of full/soft restrictions in sdeusd.move shows some inconsistencies that may allow bypasses of it.

Orphaned Rewards Captured by First Staker

Severity: Medium

Ecosystem: Sui

Protocol: Elixir

Auditor: Pashov

Report: https://github.com/pashov/audits/blob/master/team/pdf/Elixir-security-review_2025-08-17.pdf

Report Date: Aug 2025

Description:

Rewards can be distributed when no active stakers exist.

Incorrect Role Revocation Logic May Grant Unauthorized Roles

Severity: Medium

Ecosystem: Supra

Protocol: DexLyn Smart Contract

Auditor: HackenProof Contest SRs

Report: https://hackenproof.com/reports/DEXLYNCA-28

Report Date: Sep 2025

Description:

Revoking a role that doesn’t exist may grant permissions to another role.

Wrong Event Value

Severity: Medium

Ecosystem: Sui

Protocol: Dola

Auditor: MoveBit

Report: https://movebit.xyz/reports/Dola-Protocol-Final-Audit-Report.pdf

Report Date: Feb 2024

Description:

In the emit_reserve_stats function, the supply_index field incorrectly uses the return value of the get_borrow_index function, which is the same as the borrow_index , as the value of the event, which may cause confusion in analyzing the data off the chain. Also the UpdateUserRewardEvent event in the claim_reward function, old_reward_index and new_reward_index also use user_reward.last_update_reward_index as a value.

Valid Prizes Can Be Collected As Expired

Severity: Medium

Ecosystem: Sui

Protocol: Random-Vault

Auditor: MoveBit

Report: https://movebit.xyz/reports/Random-Vault-Final-Audit-Report.pdf

Report Date: Feb 2024

Description:

In the collect_expired_prize function, anyone can collect the prize that is over the round.end_time. This means, that if the time difference is large enough, the valid prize may be collected.

Incomplete Handling of Fully Repaid Loans in the Loan List

Severity: Medium

Ecosystem: Sui

Protocol: Scallop

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Scallop-Smart-Contract-Audit-Report.pdf

Report Date: Jun 2023

Description:

Fully repaid loans remain in the loan list with zero amount, causing redundant computations and indicating missing loan list maintenance.

bottle_table might be out of order

Severity: Medium

Ecosystem: Sui

Protocol: Bucket Protocol

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Bucket-Protocol-Smart-Contract-Audit-Report.pdf

Report Date: Jun 2023

Description:

In handle_redeem, if buck_input_amount is fully repaid for a part of Bottle, Bottle debt is 0. If it pushes to end of list, linked_table will be out of order.

Logical Loophole

Severity: Medium

Ecosystem: Sui

Protocol: Turbos Finance-TurboStar

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/TurboStar-Smart-Contract-Audit-Report.pdf

Report Date: May 2023

Description:

Sale_balance can be transferred to reduce raise goal, fund function to give more people an opportunity to participate in IDO.

proposal_request can be extracted at any time

Severity: Medium

Ecosystem: Sui

Protocol: Legend of Arcadia

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Legend-of-Arcadia-Smart-Contract-Audit-Report.pdf

Report Date: Jun 2023

Description:

Missing check if proposal is approved or rejected, any user of MultiSignature can take away the request object in the proposal.

burn function Design flaw

Severity: Medium

Ecosystem: Sui

Protocol: Legend of Arcadia

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Legend-of-Arcadia-Smart-Contract-Audit-Report.pdf

Report Date: Jun 2023

Description:

Missing check for amount = none, which may burn all coins. Change burn_request to first use coin::split to separate the coins in params according to amount.

approved_weight and reject_weight are not compared

Severity: Medium

Ecosystem: Sui

Protocol: Legend of Arcadia

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Legend-of-Arcadia-Smart-Contract-Audit-Report.pdf

Report Date: Jun 2023

Description:

approved_weight and reject_weight are not compared, acknowledged as is optional.

Lack of Minimum Liquidity

Severity: Medium

Ecosystem: Sui

Protocol: KriyaDEX

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/KriyaDEX-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

In the add_liquidity function, there is no min the first time adding liquidity. Add min liquidity and lock it in the pool.

Missing K Value Verification

Severity: Medium

Ecosystem: Sui

Protocol: KriyaDEX

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/KriyaDEX-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

Missing check, after swap, the value of k should be greater than or equal to the previous value of k.

Lack of K-Value Check

Severity: Medium

Ecosystem: Sui

Protocol: MovEX

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/MovEx-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

Missing check, after swap, the value of k should be greater than or equal to the previous value of k.

Lack of Minimum Liquidity Requirement

Severity: Medium

Ecosystem: Sui

Protocol: MovEX

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/MovEx-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

In the add_liquidity function, there is no min the first time adding liquidity. Add min liquidity and lock it in the pool.

Incorrect Protocol Fee Handling

Severity: Medium

Ecosystem: Sui

Protocol: MovEX

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/MovEx-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

If fee is not withdrawn, fee will be withdrawn by person who adds liquidity. This may also cause asset losses for some users who provide liquidity.

Missing K Check

Severity: Medium

Ecosystem: Sui

Protocol: Sui AMM Swap

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Sui-AMM-swap-Contracts-Audit-Report.pdf

Report Date: Nov 2022

Description:

Missing check, after swap, the value of k should be greater than or equal to the previous value of k.

No minting of minimum liquidity

Severity: Medium

Ecosystem: Sui

Protocol: Sui AMM Swap

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Sui-AMM-swap-Contracts-Audit-Report.pdf

Report Date: Nov 2022

Description:

In the function add_liquidity(), if it is the first injection of liquidity, the number of lp tokens obtained will be subtracted from the minimum liquidity value (MINIMAL_LIQUIDITY). The function of MINIMAL_LIQUIDITY is to limit the lower limit of lp supply, thereby reducing the unit price of lp token and increasing the attack cost of lp price manipulation.

This value is directly subtracted in the code, so the value of lp_supply does not increase, and this part should be mint and stored in an address instead of being directly subtracted.

Missing Key Validation in ReserveConfig

Severity: Medium

Ecosystem: Sui

Protocol: Aries Market

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description:

No check if liquidation_threshold > loan_to_value. If threshold is lower, asset can be liquidated immediately when borrowing amount is close to borrowing capacity, resulting in loss to user.

Unreasonable Repayment of Logic for Flash Loans

Severity: Medium

Ecosystem: Sui

Protocol: Aries Market

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description:

In the end_flash_loan() function within controller.move, when repayment is made for a flash loan, if the amount in coin_src exceeds the outstanding payment amount of the flash loan, the excess amount is used to repay other debts or make deposits. This is not a reasonable logic for flash loans.

Missing Reward Collection Check in burn_position Leads to Permanent Reward Loss

Severity: Medium

Ecosystem: Sui

Protocol: Magma DEX

Auditor: Three Sigma

Report: https://cdn.sanity.io/files/qoqld077/staging/9566473c444a6cfd99c7a6556fa4857950b41de3.pdf

Report Date: July 2025

Description:

The almm_pair::burn_position function allows users to completely destroy their liquidity positions without ensuring that accumulated rewards from the RewarderGlobalVault have been collected first. This function is designed to withdraw all liquidity from all bins in a position and destroy the position object, but it lacks a critical validation step to check if the position has unclaimed rewards from the rewarder system.

factory::revoke_protocol_fee_cap function is implemented incorrectly

Severity: Medium

Ecosystem: Sui

Protocol: Magma DEX

Auditor: Three Sigma

Report: https://cdn.sanity.io/files/qoqld077/staging/9566473c444a6cfd99c7a6556fa4857950b41de3.pdf

Report Date: July 2025

Description:

When revoking protocol_fee_cap, instead of removing the cap from allowed_protocol_fee_cap vector, we remove the cap from the allowed_admin, which will result in preventing of removing protocol_fee_cap as the Id is not added into allowed_admin.

Last Holder Can’t Exit, Zero‑Supply Unstake Reverts

Severity: Medium

Ecosystem: Initia

Protocol: Cabal Liquid Staking

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-04-cabal-liquid-staking-token

Report Date: May 2025

Description:

When a user burns the entire remaining supply of a Cabal LST ( sxINIT or Cabal LPT) via initiate_unstake, the follow‑up processing step always aborts with a divide‑by‑zero and the user can never exit.

get_cost_amount allows unlimited free domain registrations

Severity: Medium

Ecosystem: Initia

Protocol: Initia Move

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-01-initia-move

Report Date: Apr 2025

Description:

The get_cost_amount function unintentionally sets the price for domain names of length greater than or equal to 7 to zero. FREE_LENGTH is defined as 7. When the length of the domain name is greater than or equal to 7, the else branch is executed, setting the price_per_year to 0. While this behavior may be intentional to make longer domain names free, it opens the system to abuse.

The proposal expiration logic is incorrect

Severity: Medium

Ecosystem: Initia

Protocol: Initia Move

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-01-initia-move

Report Date: Apr 2025

Description:

The is_proposal_expired function uses incorrect comparison logic that causes proposals to be marked as expired when they should still be active, and vice versa. This is as a result of the reversed comparison operator in the expiration check. The impact of this bug is high because valid proposals are incorrectly marked as expired which prevents legitimate voting. Also the voting period enforcement is effectively reversed. This effectively creates a DoS because any multisig wallet created would be unable to execute proposals.

Missing Token Order and Identity Validation in LP Token

Severity: Medium

Ecosystem: Aptos

Protocol: Hyperion Smart Contracts

Auditor: ExVul

Report: https://github.com/ExVul-Sec/AuditReport/blob/main/Smartcontract/Hyperion%20Smart%20Contrat%20Audit%20Report-Exvul.pdf

Report Date: Apr 2025

Description:

Two validation issues exist in the lp.move contract's LP token creation functions:

Token Pair Order Issue in get_pool_seeds Function

The get_pool_seeds function generates seeds directly from token_a and token_b without sorting. This can create different LP tokens for the same pair in different orders, potentially splitting liquidity pools.

Lack of Token Identity Check in LP Creation

The create_share_token function doesn't verify if token_a and token_b are the same, allowing creation of invalid single-token LP tokens.

Missing Tick Range Validation in Vault Creation

Severity: Medium

Ecosystem: Aptos

Protocol: Hyperion Smart Contracts

Auditor: ExVul

Report: https://github.com/ExVul-Sec/AuditReport/blob/main/Smartcontract/Hyperion%20Smart%20Contrat%20Audit%20Report-Exvul.pdf

Report Date: Apr 2025

Description:

The create_vault function allows users to specify tick_lower and tick_upper without any validation. This leads to two critical problems:

Invalid Tick Order:

There is no check ensuring that tick_lower < tick_upper. This violates the core design of Uniswap V3-style tick ranges, potentially resulting in vaults that cannot function properly due to misconfigured tick boundaries.

Lack of Tick Bound Checks:

Neither tick_lower nor tick_upper are validated against the protocol's global minimum/maximum tick bounds. This may allow the creation of positions outside the valid price range supported by the underlying pool, which could cause failures in liquidity provisioning or swaps.

set_next_variable_borrow_index() used instead of set_next_scaled_variable_debt()

Severity: Medium

Ecosystem: Aptos

Protocol: AAVE v3.1-3.3 Core

Auditor: Certora

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Certora%20Aave%20Aptos%20Core%20V3.1-V3.3%20Report.pdf

Report Date: Apr 2025

Description:

In the function liquidation_logic::burn_debt_tokens() a call to set_next_variable_borrow_index() has been wrongly introduced in the place of set_next_scaled_variable_debt(). This approach fails to update the relevant variable next_scaled_variable_debt and falsely updates next_variable_borrow_index, leading to the total_variable_debt and consequently, the current_liquidity_rate and current_variable_borrow_rate being updated to much lower values than they should.

Health factor check is too low

Severity: Medium

Ecosystem: Aptos

Protocol: AAVE v3.0.2

Auditor: Certora

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Certora%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Apr 2025

Description:

validate_liquidation_call first checks if health_factor is less than 0.95e18, then again if health_factor is less than 1e18. The second check is redundant.

Retroactive windfall for first time users

Severity: Medium

Ecosystem: Aptos

Protocol: AAVE V3

Auditor: Cantina Contest SRs

Report: https://cantina.xyz/code/ad445d42-9d39-4bcf-becb-0c6c8689b767/findings/192

Report Date: Jun 2025

Description:

In update_user_data, the code does:

if (!simple_map::contains_key(&reward_data.users_data, &user)) { simple_map::add(&mut reward_data.users_data, user, UserData { index: 0, accrued: 0 });}let (rewards_accrued, _) = calculate_rewards( user_balance, new_asset_index, (user_data.index as u256), asset_unit);

Because UserData.index is always initialized to 0, the very first call computes

rewards_accrued = user_balance * (new_asset_index – 0) / asset_unit

granting the newcomer the full cumulative rewards per token ever emitted. In Aave’s Solidity _updateUserAssetInternal, a fresh user’s stored index is immediately set to newAssetIndex and rewards are only calculated if their prior stake is nonzero, so first‐time participants never receive back-pay .

First-time users instantly drain the entire historical reward pool, diluting legitimate stakers and depleting treasury funds.

Partially filled APD redemptions always charge the full redemption fees

Severity: Medium

Ecosystem: Aptos

Protocol: Thala Labs Aptos Dollar

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Thala%20Labs%20Move%20Dollar%20-%20Zellic%20Audit%20Report.pdf

Report Date: Oct 2022

Description:

Because the variable redemption_fee_coin is not adjusted to account for partial redemptions, users who call vault::redeem_collateral are always charged full redemption fee.

Unable to unregister collateral CoinTypes

Severity: Medium

Ecosystem: Aptos

Protocol: Thala Labs Aptos Dollar

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Thala%20Labs%20Move%20Dollar%20-%20Zellic%20Audit%20Report.pdf

Report Date: Oct 2022

Description:

Collateral CoinTypes cannot be unregistered, and there’s no disincentive for borrowing against assets outside Thala’s risk framework. A freezing mechanism was added but requires further review.

Potentially incorrect implementation of multiple queue operations

Severity: Medium

Ecosystem: Aptos

Protocol: Laminar Markets

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2022

Description:

Coding mistakes in flow:queue. In the case index_to_remove is neither there is an assert, assert should also be there if index_to_remove is tail. queue::remove cannot handle length of 1 and in queue::in_next there is an assertion followed by an if and a second assert that will never fail.

Update the Reserves within the swap() Function

Severity: Medium

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

In the swap_exact_x_to_y_direct() function, the protocol swaps token X to token Y and subsequently calls update_reserves() to update the constant product. However, a best practice, as exemplified in the PancakeSwap code, is to call the update() function within the swap() function to handle the updates. This ensures that the reserves are consistently and efficiently updated during the swapping process.

Some View Function Logic Errors

Severity: Medium

Ecosystem: Aptos

Protocol: MoveGPT

Auditor: MoveBit

Report: https://movebit.xyz/reports/MoveGPT-Final-Audit-Report.pdf

Report Date: Apr 2024

Description:

The view function to get information about private_round is still retrieved from the ido_round field.

claim Function Can Be Called Multiple Times

Severity: Medium

Ecosystem: Aptos

Protocol: MoveGPT

Auditor: MoveBit

Report: https://movebit.xyz/reports/MoveGPT-Final-Audit-Report.pdf

Report Date: Apr 2024

Description:

Claim related functions can be called multiple times by the user.

Logic Error in Claim Function

Severity: Medium

Ecosystem: Aptos

Protocol: MoveGPT

Auditor: MoveBit

Report: https://movebit.xyz/reports/MoveGPT-Final-Audit-Report.pdf

Report Date: Apr 2024

Description:

The assertion function current_time > vesting_config.start causes the claim function to never reach the if branch of the vesting_config.start > current_time condition.

Insufficient Validation for amounts_out

Severity: Medium

Ecosystem: Aptos

Protocol: Cellena

Auditor: MoveBit

Report: https://movebit.xyz/reports/Cellana-Smart-Contract-Final-Audit-Report.pdf

Report Date: Feb 2024

Description:

In the swap_route_entry function, the assertion at L130 only validates the last value in the amounts_out array, which is insufficient to verify that all values in the array are correct.

Incorrect Condition Statement

Severity: Medium

Ecosystem: Aptos

Protocol: Cellena

Auditor: MoveBit

Report: https://movebit.xyz/reports/Cellana-Smart-Contract-Final-Audit-Report.pdf

Report Date: Feb 2024

Description:

In the optimal_liquidity_amounts function, the conditional statement if (amount_2 <= amount_2_desired) is always true. According to the context logic, the parameter amount_2 should be changed to amount_2_optimal.

Logic Design of The swap_route_entry Function

Severity: Medium

Ecosystem: Aptos

Protocol: Cellena

Auditor: MoveBit

Report: https://movebit.xyz/reports/Cellana-Smart-Contract-Final-Audit-Report.pdf

Report Date: Feb 2024

Description:

The swap_route_entry function first swaps the first token from the from_token array with the first token from the to_token array. Then, it swaps the resulting token with the second token from the to_token array, and so on. Finally, it transfers the token from the last swap to the recipient. The correct design should be to swap each token in the from_token array with the corresponding token in the to_token array.

Limit Orders Cannot Be Executed

Severity: Medium

Ecosystem: Aptos

Protocol: Merkle Trade Smart Contract

Auditor: MoveBit

Report: https://movebit.xyz/reports/Merkle-Trade-Smart-Contract-Audit-Report.pdf

Report Date: July 2023

Description:

The function execute_order() is used to execute an order. Inside the function, it checks if more than 30 seconds have passed since the order was created. If the condition is met, it cancels the order by calling cancel_order_internal(). However, if the order is a limit order, it means that the order has a specific price set by the trader at which they are willing to buy or sell the asset, if this timeout has elapsed, the order is considered expired.

view_broker Should Not Return False Bool Directly

Severity: Medium

Ecosystem: Aptos

Protocol: Superposition

Auditor: MoveBit

Report: https://movebit.xyz/reports/Superposition-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

In broker.move, the view_broker is a function that reads the current state of the broker. However, instead of reading the bool values from the broker, several values directly return false. This will send wrong values for not only this view function but also other functions that call it, for example: borrow_with_ticket, lend_with_ticket, etc.

Fixed Slippage

Severity: Medium

Ecosystem: Aptos

Protocol: vibrantX

Auditor: MoveBit

Report: https://movebit.xyz/reports/vibrantX-Final-Audit-Report.pdf

Report Date: Jan 2024

Description:

Slippage protects users from losing tokens in some paris, but the fixed slippage settings can also lead to failed trades with high price volatility.

Wrong condition in assert

Severity: Medium

Ecosystem: Aptos

Protocol: Mokshya/Wapal Aptos NFT Mint

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mokshya-Wapal-Aptos-NFT-Mint-Smart-Contract-Audit.pdf

Report Date: Mar 2023

Description:

In the update_candy function, the royalty_points_denominator judges the wrong condition here, which will never be able to update candy_data.royal_points_denominator.

Unverified public_sale_mint_time must be greater than presale_mint_time

Severity: Medium

Ecosystem: Aptos

Protocol: Mokshya/Wapal Aptos NFT Mint

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mokshya-Wapal-Aptos-NFT-Mint-Smart-Contract-Audit.pdf

Report Date: Mar 2023

Description:

In candymachine::mint_from_merkle, public_sale_mint_time must be greater than presale_mint_time, but it is not verified when creating or modifying CandyMachine.

Business logic structure is too complex

Severity: Medium

Ecosystem: Aptos

Protocol: Transit Finance

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Transit-Finance-Audit-Report.pdf

Report Date: Nov 2022

Description:

batch_swap_five has 27 type parameters and 15 function parameters. Incovenient for code maintenance, user command line execution, and function call, gas consumption will also be higher.

Code readability needs to be improved in the get_intermediate_out_from_dex functions

Severity: Medium

Ecosystem: Aptos

Protocol: Transit Finance

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Transit-Finance-Audit-Report.pdf

Report Date: Nov 2022

Description:

Dex swap logic of six different branches can be split into six functions to improve readbility.

Common code should be encapsulated as a function to be called

Severity: Medium

Ecosystem: Aptos

Protocol: Transit Finance

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Transit-Finance-Audit-Report.pdf

Report Date: Nov 2022

Description:

batch_swap_three and batch_swap_five have roughly the same code except for the number of type parameters.

Excessive reliance on external dex contract calls and no way to control or suspend external dex

Severity: Medium

Ecosystem: Aptos

Protocol: Transit Finance

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Transit-Finance-Audit-Report.pdf

Report Date: Nov 2022

Description:

No security measures in external contract calls to get_intermediate_out_from_dex exist.

Wrong event type emitted

Severity: Medium

Ecosystem: Aptos

Protocol: Cetus Concentrated Liquidity Protocol

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Aptos-Audit-Report.pdf

Report Date: Jan 2023

Description:

In create_pool, it emits CreatePoolEvent.coin_type_b with CoinTypeA.

The pool Coin Order Handle

Severity: Medium

Ecosystem: Aptos

Protocol: Cetus Concentrated Liquidity Protocol

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Aptos-Audit-Report.pdf

Report Date: Jan 2023

Description:

In create_pool, you can create a pool with CoinA, CoinB and CoinB, CoinA. This will cause confusion. Force user to create pool with coins in order, by adding an assert.

Liquidate Minimum Debt Vaults

Severity: Medium

Ecosystem: OL Network

Protocol: StakeSphere

Auditor: MoveJay

Report: https://github.com/Jayfromthe13th/StakeSphere-stealth-/blob/Wallet/Audit.md

Report Date: Apr 2024

Description:

StakeSphere enforces a minimum debt threshold when repaying vaults. That being said, liquidate_repay also enforces that the collateral ratio of the vault isn’t repaid fully. This means that vaults that are close to the minimum debt threshold cannot be liquidated.

No Check for Account Registration

Severity: Medium

Severity: Low

Ecosystem: Supra Chain

Protocol: Dexlyn Hyperlane

Auditor: Hacken

Report: https://hacken.io/audits/dexlyn/sca-dexlyn-hyperlane-monorepo-dec2024/

Report Date: Dec 2024

Description:

In move/igps/sources/igps.move, the pay_for_gas function's balance check uses a strict greater than (>) comparison instead of greater than or equal to (>=). This causes transactions to revert when a user has exactly the required amount:

assert!(coin::balance<AptosCoin>(account_address) > required_amount, ERROR_INSUFFICIENT_INTERCHAIN_GAS);

Transactions will fail even when users have exactly the required amount of funds to pay for interchain gas. While not a security vulnerability, this creates unnecessary friction and may confuse users who have allocated precisely the required amount.

Zero-Stake Period Leads to Reward Loss

Severity: Low

Ecosystem: IOTA Mainnet

Protocol: Pools Finance

Auditor: Hacken

Report: https://hacken.io/audits/pools-finance/sca-pools-finance-pools-contracts-may2025/

Report Date: June 2025

Description:

A vulnerability exists in the staking protocol's reward accumulation mechanism that causes permanent loss of rewards during periods when no users have staked tokens. The issue stems from the protocol's division-by-zero protection logic that returns zero accumulated rewards when total_staked 0, effectively discarding rewards that should be distributed to future stakers.

Bug in condition when checking we borrowed enough

Severity: Low

Ecosystem: Sui

Protocol: Kai Finance

Auditor: Asymptotic

Report: https://info.asymptotic.tech/kai-leverage-verification-report-6ec808dd2adc4b55a4e30f0512260a70

Report Date: Aug 2024

Description:

It checks for borrowed_x while the function refers to position y(github) . It is not critical because create_position rechecks correctly.

Incorrect treasury empty check

Severity: Low

Ecosystem: Sui

Protocol: Kai Finance

Auditor: Asymptotic

Report: https://info.asymptotic.tech/kai-leverage-verification-report-6ec808dd2adc4b55a4e30f0512260a70

Report Date: Aug 2024

Description:

The treasury check is incomplete in add_lend_facil (github). The condition should be registry.supply_x64() == 0 && registry.underlying_value_x64() == 0 .

create_pool is an example of the correct condition (github).

Not major because it is a function used by the owner of the pool — it just protects against silly mistakes.

Can delete non-empty action group

Severity: Low

Ecosystem: Sui

Protocol: Aeon

Auditor: Asymptotic

Report: https://info.asymptotic.tech/aeon-audit-report#262c1aef2c7042b7816a0015ed4a0051

Report Date: Feb 2025

Description:

execute_config_delete_action_group, does not assert that the group is empty, like execute_config_user_delete_group and execute_config_address_book_delete_group

`view_mpc_ready_signing_tx_signable` is a getter/viewer so it shouldn't have any asserts

Severity: Low

Ecosystem: Sui

Protocol: Aeon

Auditor: Asymptotic

Report: https://info.asymptotic.tech/aeon-audit-report#262c1aef2c7042b7816a0015ed4a0051

Report Date: Feb 2025

Description:

Can they be moved in process_module_action_result or create_module_action_result?

Cosmos transactions cannot be updated

Severity: Low

Ecosystem: Sui

Protocol: Aeon

Auditor: Asymptotic

Report: https://info.asymptotic.tech/aeon-audit-report#262c1aef2c7042b7816a0015ed4a0051

Report Date: Feb 2025

Description:

In aeon-chains/sources/cosmos_module.move, prepare_signing doesn’t call add_transaction as it should, which means that prepare_signing_accelerate calls get_transaction_borrow_mut and fails.

Missing check in `process_vault_module_changes`

Severity: Low

Ecosystem: Sui

Protocol: Aeon

Auditor: Asymptotic

Report: https://info.asymptotic.tech/aeon-audit-report#262c1aef2c7042b7816a0015ed4a0051

Report Date: Feb 2025

Description:

In custody/sources/vault.move, process_vault_module_changes should assert!(added_chain_state_data_id_opt.is_some(), EMissingChainState), like the existing assert!(updated_chain_state_data_id_opt.is_some(), EMissingChainState)

`set_manager` incorrectly logs old manager

Severity: Low

Ecosystem: Sui

Protocol: Bluefin RFQ

Auditor: Asymptotic

Report: https://bluefin.io/blog/doc/bluefin_rfq_audit.pdf

Report Date: Feb 2025

Description:

let old_manager = manager; actually records the new manager instead of the old one.

Incorrect Cooldown Check in `withdraw` Function

Severity: Low

Ecosystem: Sui

Protocol: SatLayer Sui

Auditor: Asymptotic

Report: https://info.asymptotic.tech/satlayer-audit

Report Date: Mar 2025

Description:

Severity: Low

Ecosystem: Sui

Protocol: Full Sail CLMM

Auditor: Asymptotic

Report: https://info.asymptotic.tech/full-sail-clmm-audit

Report Date: May 2025

Description:

repay_flash_swap called after flash_swap_with_partner ignores the partner_id, but this is not an issue, because it checks that ref_rate == 0. Still, I would recommend to change the type of partner_id in FlashSwapReceipt to Optionsui::object::ID, and in repay_flash_swap check that it is None.

Pause bypass for reward updates

Severity: Low

Ecosystem: Sui

Protocol: Momentum

Auditor: Sherlock

Report Date: Nov 2025

Description:

The admin entry points uses a pause flag on VeMMT to freeze critical state changes during incidents. Functions that initialize a schedule or extend its duration explicitly check is_paused and abort when true. The emission returning function like update_pool_reward_emission lacks this guard and still calls into the pool to update rate and end-time accounting.

The get_user_claim_reward_amount overestimates claimable reward

Severity: Low

Ecosystem: Sui

Protocol: Momentum

Auditor: Sherlock

Report Date: Nov 2025

Description:

The read path computes the user’s claim by iterating epochs and calculating each epoch’s accrual from index deltas and vote power. For each epoch, it caps the computed value by the current pool balance. Because it does not model a running “remaining pool balance,” it may cap multiple epochs against the same balance snapshot and sum a total larger than the coin the pool can transfer atomically. Additionally, the view reads time-sensitive fields like current index or end-of-epoch markers without first calling the pool’s sync_or_advance_epoch sync routine, so the calculation can be stale within an epoch.

View helpers abort for unstaked ve-tokens

Severity: Low

Ecosystem: Sui

Protocol: Momentum

Auditor: Sherlock

Report Date: Nov 2025

Description:

The build_ve_token_data view builder composes a position object by pulling claimable rewards, last-claimed markers, and other reward fields via helpers that borrow the UserRe wardData dynamic field from the VeToken. That dynamic field exists only for staked tokens that have been deposited through deposit. The builder computes “staked or not” later in the flow using is_ve_staked, so the early attempt to borrow UserRewardData on an unstaked token aborts the view call. Read-only endpoints that rely on build_ve_token_data inherit the same failure mode.

Initialization Function Can be Called Multiple Times

Severity: Low

Ecosystem: Sui

Protocol: Momentum

Auditor: MoveBit

Report Date: Nov 2025

Description:

The initialization function of the StakingPool can be invoked multiple times. Repeated initialization may result in the loss of user funds.

Incorrect Return Value in Binary Search for Optimal Swap Amount

Severity: Low

Ecosystem: Sui

Protocol: Momentum CLMM

Auditor: Asymptotic

Report Date: Aug 2025

Description:

The get optimal swap amount for single sided liquidity function uses a binary search to find the swap amount that best matches the optimal token ratio. While the function correctly tracks the best ratio found during the search, it does not return the swap amount corresponding to this best ratio. Instead, it returns the value calculated for the next iteration, that never runs and may not be optimal. Additionally, the binary search logic can be optimized, as it runs in a loop with some redundant assignments and unnecessarily steps. Simplifying the logic and removing redundant operations would improve both code clarity and execution efficiency.

Incorrect Validation Order: check tick range Called Before Tick Order Check

Severity: Low

Ecosystem: Sui

Protocol: Momentum CLMM

Auditor: Asymptotic

Report Date: Aug 2025

Description:

In open position, check tick range is called before verify tick. However, check tick range assumes tick upper ¿ tick lower but does not check this.

Severity: Low

Ecosystem: Sui

Protocol: Aftermath

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description:

In the geometric_mean_calculations.move module within the following functions: calc_swap_fixed_in, calc_swap_fixed_out, calc_withdraw_fixed_amounts, and calc_deposit_fixed_amounts, the convergence between prev_t and t is checked after the while loop. However, this approach will properly execute because the t value is copied into the prev_t variable at the end of the loop.

Improper Token Weight Calculation

Severity: Low

Ecosystem: Sui

Protocol: Bucket

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: June 2023

Description: get_token_weight in the tank module calculates the weight of the user’s deposit. Calculating the amount able to be withdrawn by the user uses this token weight. In this function, if the total calculated compound_stake of the user for the two scales is less than token.deposit_amount/constants::scale_factor() value, zero is returned. This results in unnecessarily reducing the user’s compounded stake.

Incorrect Key Check

Severity: Low

Ecosystem: Sui

Protocol: Scallop

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: June 2023

Description:

obligation::lock is designed to lock the obligation functionality. Currently, the function invokes assert_reward_key_in_store, which is inconsistent with its intended purpose. Instead, assert_lock_key_in_store should be invoked, as the function should handle the locking of the obligation, not the rewards management.

Excessive Withdrawal Of Staked Amount

Severity: Low

Ecosystem: Sui

Protocol: Haedel LSD

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Nov 2023

Description: The issue stems from the existing implementation of get_split_amount, where a modest need_amount (e.g., 1 MIST) has the potential to trigger the withdrawal of the entire StakedSui, even if the total staked SUI amount is considerably high, instead of withdrawing only a portion of the staked amount as intended, and keeping the rest staked.

Non-Ascending Epoch Claims

Severity: Low

Ecosystem: Sui

Protocol: Haedel LSD

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Nov 2023

Description:

The issue is with regards to set_withdraw_time_limit, which grants administrators the ability to define the time limit for withdrawing staked tokens. To elaborate, should the administrator elevate the withdraw_time_limit to surpass the present timestamp calculated from the inception of the epoch, it may result in a scenario where a user generates two UnstakeTicket objects within the same epoch. In particular, if the timestamp (X) of the first ticket exceeds epoch_timestamp_ms + old_limit, and the timestamp (Y) of the second ticket falls below epoch_timestamp_ms + new_limit, the resultant EpochClaim for these two tickets will correspond to epochs E+2 and E+1, respectively. This creates a scenario where the epoch claims are in a non-ascending order, which is problematic as epoch claims should be in ascending order. This non-ascending order may disrupt the normal flow of epochbased operations.

Invalid Parameters

Severity: Low

Ecosystem: Sui

Protocol: Drife Technologies

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Dec 2023

Description: The issue is related to the fact that both stop_ride and resume_ride functions expect Driver and Rider objects to be passed as arguments at the same time. It should be impossible for the user to own both Driver and Rider objects.

Arrival Confirmation

Severity: Low

Ecosystem: Sui

Protocol: Drife Technologies

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Dec 2023

Code: N/A

Description:

In its current implementation, the system allows a driver to start a ride without confirmation from the rider that they have arrived at the pickup point. This lack of confirmation can lead to potential issues such as miscommunication or misunderstandings between the rider and the driver, affecting the system’s overall customer experience and functionality.

Improper Fee Configuration

Severity: Low

Ecosystem: Sui

Protocol: Aftermath Orderbook

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2024

Description: Fees could be negative, giving collateral to user instead of paying fees.

Rewards State Abort

Severity: Low

Ecosystem: Sui

Protocol: Suilend

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2024

Description: An edge case occurs when the length of the rewards vector in user_reward_manager is less than or equal to the current index i. This implies that there are fewer entries in the rewards vector than expected based on the iteration index. However, the if condition vector::length(&user_reward_manager.rewards) == i) only executes when the pool rewards is initialized. If the pool reward array is not contiguous, this could trigger an abort.

Ownership Transferring Not Tracked

Severity: Low

Ecosystem: Sui

Protocol: Sui Axelar(Gateway V2)

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2024

Description: There is an issue within process_commands in the Cross-Chain Gateway Protocol, specifically in the handling of ownership transfer calls (SELECTOR_TRANSFER_OPERATORSHIP). Currently, the function only records approved token transfer calls and does not record calls that transfer ownership. This omission opens up the possibility of relay attacks.

Potential Balance Misallocation

Severity: Low

Ecosystem: Sui

Protocol: Sui Axelar(Gateway V2)

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2024

Description: In get_transaction, the call to sweep is not explicitly enforced to occur after the call to swap. If the program calls SWAP_TYPE_SWEEP_DUST before SWAP_TYPE_DEEPBOOK_V2, or if there is no SWAP_TYPE_DEEPBOOK_V2 call at all, all balances of the base coin (which are supposed to be the remaining coins after the swap) will be stored in the coin_bag of the Squid router during sweep. As a result, if sweep is called before swap, all balances of coin T1 will be moved to the coin_bag of the Squid router, and neither the source nor the destination address will receive any coins. The finalize function includes a safeguard to ensure that the balance value (balance.value()) is greater than or equal to self.min_out. However, this safeguard is ineffective if min_out is set to zero.

Incorrect Whitelist Check

Severity: Low

Ecosystem: Sui

Protocol: Cetus

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2024

Description: config::check_token_and_min_trade_amount misuses the return value of find_token_and_min_trade_amount when require_check_token_white_list is true. The is_existed flag indicates the presence of the token in the whitelist. If it is true, the function should verify the minimum trade amount. Conversely, if is_existed is false, meaning the token is absent from the whitelist, the function should immediately return false.

Double Counting Rewards

Severity: Low

Ecosystem: Sui

Protocol: Turbos Finance

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2024

Description: When strategy_rewards_settle calls accumulate_rewarder_released for each rewarder, it updates the total_reward_released for the entire rewarder based on the current time and the elapsed time since the rewarder’s last_reward_time. The subsequent call to accumulate_strategy_reward also calculates elapsed time using the strategy’s last_reward_time, which may differ from the rewarder’s last_reward_time. Since accumulate_strategy_reward does not update the rewarder’s last_reward_time, the elapsed time it calculates may include a period already accounted for in the previous call to accumulate_rewarder_released. As a result, the total_reward_released for the rewarder may be incremented twice for the same elapsed period, effectively double-counting the reward.

Unhandled Proposal Removal

Severity: Low

Ecosystem: Sui

Protocol: Mysten Deepbook

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Aug 2024

Description: In governance::adjust_vote, when a proposal is removed by remove_lowest_proposal and a new proposal is subsequently created by the same account, certain issues may arise. After a proposal is removed, its ID becomes invalid in the self.proposals map. If the same account creates a new proposal, it may be assigned the same proposal_id; however, the vote count for this new proposal starts at zero.

Imbalance in LST Supply

Severity: Low

Ecosystem: Sui

Protocol: Solend Liquid Staking

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

Currently, create_lst_with_stake does not validate the relationship between the SUI, fungible_staked_sui, and lst_treasury_cap.total_supply values. The function only ensures that lst_treasury_cap.total_supply and the total staked SUI in the system are greater than zero.

The LST created should ideally represent a proportional claim on the underlying staked SUI assets. If there is no relationship between the total LST supply and the staked SUI, users may receive LST tokens that over- or under-represent the actual value of the staked assets. The misalignment between LST and staked SUI may result in incorrect pricing when users interact with the protocol.

Abort due to Failed Assertion Check

Severity: Low

Ecosystem: Sui

Protocol: Solend Liquid Staking

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

The assertion in mint within liquid_staking , while intended to maintain the balance between Liquid Staking Tokens ( LST ) and SUI, may abort under certain conditions. If old_lst_supply == 0 and old_sui_supply > 0 , the assertion will always fail. In this case, the conversion of the provided SUI amount to LST utilizing sui_amount_to_lst_amount will return the sui_amount itself.

Incorrect Price Boundary Checks

Severity: Low

Ecosystem: Sui

Protocol: Bluefin Spot

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Nov 2024

Description:

Utilizing >= and <= in the boundary checks is not appropriate, as allowing the price to hit the exact minimum or maximum boundaries will result in attempts to execute swaps that lead to invalid price states.

Incorrect Role Check

Severity: Low

Ecosystem: Sui

Protocol: Matrixdock

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Matrixdock XAUm - Zellic Audit Report.pdf

Report Date: July 2025

Description: In the revoke_set_revoker function, it checks if the sender is the operator. While all functions with the revoke_ prefix are only callable by the revoker, when setting the revoker, it would be more appropriate to check if the sender is the owner. This is because the operator is only responsible for operations related to minting and burning coins.

Improper Zero Mint Check

Severity: Low

Ecosystem: Sui

Protocol: Aftermath Market Making

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Jan 2025

Description: In end_deposit_session, the check assert!(lp_to_mint != 0 only ensures that the lp_to_mint value, as calculated before the conversion to a fixed-point format ( to_balance ), is non-zero. However, the conversion process itself (specifically the call to ifixed::to_balance ) may still result in a minted amount of zero liquidity provider (LP) tokens, even if the value of lp_to_mint is non-zero prior to conversion.

Risk of Excess Recall Amount

Severity: Low

Ecosystem: Sui

Protocol: Solend Steamm

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2025

Description:

The logic in bank::recall may result in a situation where the amount_to_recall becomes greater than the available reserves due to the utilization of max(bank.min_token_block_size). The amount_to_recall is adjusted to ensure it is at least the size of bank.min_token_block_size. On recalling an amount smaller than the min_token_block_size , the function will automatically increase the recall amount to the minimum block size. The issue occurs if the available funds (the reserves in the bank) are not large enough to accommodate the adjusted amount_to_recall.

Bypassing Stake Threshold Check

Severity: Low

Ecosystem: Sui

Protocol: Mysten Walrus

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Mar 2025

Description:

ActiveSet::update does not enforce a minimum stake threshold ( set.threshold_stake ), unlike insert . This introduces a vulnerability where a user may manipulate their stake to gain a position in the active set below the required threshold.

For example, a user may stake an amount greater than set.threshold_stake, ensuring that their node is successfully inserted via ActiveSet::insert. If the active set is full, the node with the lowest stake is removed to accommodate the new entry. After successfully inserting, the user immediately calls ActiveSet::update to lower their stake below set.threshold_stake. As a result, the attacker secures a place in the active set without the required stake amount.

collect function Parameter Checking May Fail

Severity: Low

Ecosystem: Sui

Protocol: FlowX Finance

Auditor: MoveBit

Report: https://movebit.xyz/reports/FlowX-Final-Audit-Report.pdf

Report Date: May 2024

Description:

The collect function only allows the count_x_requested and count_y_requested to both be non-zero in order to pass the check_zero_amount function and if the user's position has only one token in it, he must be forced to pass one of them as an arbitrary value in order to call the collect function.

Lack of Events Emit

Severity: Low

Ecosystem: Sui

Protocol: FlowX Finance

Auditor: MoveBit

Report: https://movebit.xyz/reports/FlowX-Final-Audit-Report.pdf

Report Date: May 2024

Description:

The contract lacks appropriate events for monitoring sensitive operations, which could make it difficult to track sensitive actions or detect potential issues.

Severity: Low

Ecosystem: Aptos

Protocol: Wormhole Aptos

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2022

Description:

In both wormhole and token-bridge, contract upgrade via governance is a two step process:

A user invokescontract_upgrade::submit_vaawith a governance VAA that includes ahash of the intended upgrade code.
A user invokescontract_upgrade::upgradewith the actualmodule code which subsequently invokes code::publish_package_txn to upgrade the contract. Both of these calls are permissionless (can be invoked by any user). Integrity is protected in the first call by verifying the guardian signatures on the VAA. Integrity is protected in the second call by ensuring the provided module code matches the hash. However, in the original implementation, we identified two issues that would allow an attacker to provide alternative module code that still matches the stored hash:

Serialized Metadata A module upgrade package contains a list of code modules (vector<vector>) and serialized metadata (vector). In the original implementation, metadata_serialized was not included in the hash. Therefore, an attacker could provide any arbitrary metadata that would not cause the deployment to abort.

Module Boundaries The original hash was computed by first concatenating the code modules and then taking the hash of the concatenated structure. However, this implementation does not properly validate module code boundaries. Specifically, moving N bytes of code from the end of one module to the start of another would not affect the hash:

It is unclear whether an attacker could exploit this collision to deploy a malformed version of the module. However, since the fix is simple, it is preferable to reduce the attack surface as much as possible.

The Necessity of Controlling Return Value Order in the token_reserves() Function

Severity: Low

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

The function token_reserves() adjusts the order of returned values by sorting currencies, which might not be necessary. As the order has already been adjusted before calling this function within the current contract, the if statement is executed every time. To prevent confusion, we believe that the control over the sequence should occur when receiving the return values of this function, rather than within the current function. We also compared this to PancakeSwap's code, which similarly does not control the sequence within the current function.

tp_percent Should Be Less Than or Equal to pair_info.maximum_profit

Severity: Low

Ecosystem: Aptos

Protocol: Merkle Trade Smart Contract

Auditor: MoveBit

Report: https://movebit.xyz/reports/Merkle-Trade-Smart-Contract-Audit-Report.pdf

Report Date: July 2023

Description:

The function execute_increase_order_internal() is responsible for executing an increase order in a trading pair. Inside the function, the stop-loss and take-profit prices of the position are updated based on the order's type and the specified conditions. If the order's take-profit trigger price and the maximum take-profit price are the same, the code will assign that value to the take-profit trigger price of the position. In other words, there is no preference for either value in this scenario, and they are considered equal. However, inside the update_position_tp_sl() , an assertion is made to validate that the calculated take-profit percentage is less than the maximum allowed profit percentage specified in the pair's information. The business logic of this function, update_position_tp_sl() , is different from execute_increase_order_internal() .

Vault Amount Checks Are Not Implemented In Every Operation

Severity: Low

Ecosystem: Aptos

Protocol: Superposition

Auditor: MoveBit

Report: https://movebit.xyz/reports/Superposition-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

In super postion , the user can perform different operations such as borrow, redeem, repay . And each operation will affect the vault amount differently. However, some operations (repay, redeem) don't have vault checks before and after the operation. And the pre-vault amount calculations are not the same for the other. This would lower the security of the vault and cause misalignment in design.

The verification conditions of assert and if are repeated

Severity: Low

Ecosystem: Aptos

Protocol: Mokshya/Wapal Aptos NFT Mint Smart Contract

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mokshya-Wapal-Aptos-NFT-Mint-Smart-Contract-Audit.pdf

Report Date: Mar 2023

Description:

In the function candymachine::mint_from_merkle, use assert to verify that is_whitelist_mint is true to continue to execute the code, and then repeat the judgment through if. In the function candymachine::update_candy , assert has been used to verify that publ ic_sale_mint_time >= now && presale_mint_time >= now, and the judgment is repeated through if below.

The assert judgment condition is inaccurate

Severity: Low

Ecosystem: Aptos

Protocol: Aries Market(Aptos)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Market-Contracts-Audit-Report.pdf

Report Date: Feb 2023

Description:

In the function validate_oracle_info , when sb_weight=0 , pyth_weight=U64_MAX , or sb_weight=U64_MAX , pyth_weight=0 , the assertion condition is not met, causing oracle verification to fail.

Inaccurate judgment on deposit and loan restrictions

Severity: Low

Ecosystem: Aptos

Protocol: Aries Market(Aptos)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Market-Contracts-Audit-Report.pdf

Report Date: Feb 2023

Description:

In the following functions, when determining whether the deposit and loan amount exceeds the limit, the numerical comparison is inaccurate, and the numerical value should be less than or equal to the limit, not less than.

Incorrect check for minimum order size

Severity: Low

Ecosystem: Aptos

Protocol: Econia

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Econia - Zellic Audit Report.pdf

Report Date: Jan 2023

Description:

After performing the order book match to attempt to fill a new limit order, the place_limit_order function returns early without placing an order for the remaining unfilled size only if the order is of type IMMEDIATE_OR_CANCEL or if the remaining order size is zero. This is incorrect, as the remaining order size can be lower than the minimum order size configured for the market.

The sendOFT function call can be blocked

Severity: Low

Ecosystem: Aptos

Protocol: Layer Zero OFT Wrapper

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/LayerZero OFT Wrapper Audit (January 19th 2023) - Zellic Audit Report.pdf

Report Date: Nov 2022

Description:

The contract owner can set any bps value of the variables defaultBps and the oftBps [_oft] in the range from 0 to the maximum BPS_DENOMINATOR inclusive. But during the sendOFT function call, the getAmountAndFees function will check that the final bps value is less than BPS_DENOMINATOR and revert the transaction if it equals or more.

Missing assertion checks for critical protocol parameters

Severity: Low

Ecosystem: Aptos

Protocol: Aptos Dollar

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Thala Labs Move Dollar - Zellic Audit Report.pdf

Report Date: Oct 2022

Description:

There are no checks in place to enforce that params::set_params has been called for a given CoinType prior to calling vault::initialize.

The ascending insertion search fails to return the tail

Severity: Low

Ecosystem: Aptos

Protocol: Aptos Dollar

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Thala Labs Move Dollar - Zellic Audit Report.pdf

Report Date: Oct 2022

Description:

The sorted_vaults::find_insert_position_ascending search algorithm fails to return the tail position.

Instances of none in VaultStore.vault

Severity: Low

Ecosystem: Aptos

Protocol: Aptos Dollar

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Thala Labs Move Dollar - Zellic Audit Report.pdf

Report Date: Oct 2022

Description:

Calls to vault::close_vault leave the vault store with a none vault.

Emode LTV & LT invariants can be broken

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

Entering an emode category as a user should never be worse for the user's health. Therefore, functions like pool_configurator::set_emode_category check that the following reserve <>emode[reserve.emodeCategroy] invariant holds.

However, this invariant does not hold because not all functions that can change the reserve's / emode's LTV/LT enforce it.

set_user_emode health check always needs to be performed

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The emode_logic::set_user_emode function skips the health check when the user goes from noemode to new emode.

The idea is likely that if the following invariants hold, the health can only increase, and therefore set_user_emode cannot be used to turn a healthy user into an unhealthy user.

However, this invariant does not hold because of the finding "Emode LTV & LT invariants can be broken". The impact is that a healthy user can call set_user_emode and end up unhealthy after the call. This is bad for the user as they can be liquidated afterwards. In addition, having a programmatic way for turning any position liquidatable (under the right circumstances) in a single transaction poses security risks (f.i., see the Euler Finance hack analysis by Cyfrin) and protocol bad debt risk.

token_base events do not identify the token used

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The token_base module is used by all aTokens and vTokens to perform the base token actions like transfers. The emitted Transfer, Mint, Burn events do not identify the actual tokens these events were emitted for. The events are currently not useful for data processing because one can't identify if the Transfer was for aUSDC, aAPT, etc

init_reserves does not support yet the deployment of a reserve with preconfigured incentives_controllers

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The current implementation of pool_configurator::init_reserves does not include the input parameter incentives_controllers which is passed "empty" (option::none()) to the pool_token_logic::init_reserve. This means that every reserve will always be initialized with an empty incentive controller that needs to be configured later on.

"Same" events are defined multiple times across modules

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

In Aptos, events with the same names and struct fields that are defined in separate modules will be treated as separate events. This makes it hard to query for the event as the event needs to be queried across all modules it is defined in and the results must be merged. The proper approach is to have the event defined in a single module. Some events that represent a single event in Aave Solidity are defined across several modules in Aave Move.

token_base allows A/V token to de-sync the incentive controllers

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

When the reserve is deployed, the caller provides only one common (empty or not) incentive controller to be used for both the AToken and VariableDebtToken. The set_incentives_controller allows the caller to set a new (empty or not) incentives_controller for the single AToken or VariableDebtToken. This behavior allows the system to de-sync the tokens incentive controller that should be the same given the assumption used during the reserve's initialization. With the current logic, we could end up with: • A/V tokens are configured with different incentive controllers. • One of the two token have the incentive controller configured and the other not.

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.1-3.3 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit Aave Aptos Core V3.1-V3.3 Report.pdf

Report Date: Jun 2025

Description:

Aave 3.3 introduced new minimum position size thresholds that must exist after liquidations if the entire balance cannot be cleared. This is to prevent position sizes of small amounts that are not unprofitable to liquidate, for example, because of gas costs. • The MIN_BASE_MAX_CLOSE_FACTOR_THRESHOLD is currently set to 2000$. • The "dust value" is half of that, set to MIN_LEFTOVER_BASE = 1000$. The rules are as follows: • Full-liquidation: The max close factor is 50% of the user's total debt value (no full liquidation) if-and-only-if HF > 95% AND debt$ >= 2000$ AND collateral$ >= 2000$. Otherwise, the close factor is 100%. • Liquidation failures due to dust position sizes: Liquidation fails if both collateral and debt balances are non-zero after the liquidation and any of the balances is less than 1000$: collateral_left$ > 0 AND debt_left$ > 0 AND (collateral_left$ < 1000$ OR debt_left$ < 1000$).

Arithmetic mistakes like rounding, overflow, or precision loss impacting balances or rewards.

Calculation Errors	Findings
Critical	13
High	28
Medium	61
Low	46
Total	148

The code is incorrectly assigning the scaled-down data_amount directly to amount, resulting in users being charged less tokens than they should be on the source chain.

Severity: Critical

Ecosystem: Sui

Protocol: Bluefin Spot

Auditor: OtterSec

Report: https://www.notion.so/a296e98838aa4fdb8f3b192663400772

Report Date: Nov 2024

Description: The bluefin_vault contract is vulnerable to rounding manipulation attacks due to improper handling of token-to-share conversion rates, allowing exploitation of precision errors in share valuation. Additionally, inconsistent conditions in the shares calculation logic may cause deposits to yield zero shares when vault balances are mismatched, leading to potential fund loss.

Interest Rate Calculation Error

Severity: Critical

Ecosystem: Sui

Protocol: Navi

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Navi-Smart-Contract-Audit-Report.pdf

Report Date: Jul 2023

Description: The SECOND_PER_YEAR constant is sometimes incorrectly calculated with milliseconds, resulting in a value 1000 times larger than intended, causing significant interest rate miscalculations.

Numerical Precision Error

Severity: Critical

Ecosystem: Sui

Protocol: Navi

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Navi-Smart-Contract-Audit-Report.pdf

Report Date: July 2023

Description: In the repay function, the excess amount after repayment is returned through pool::withdraw, but excess_amount is not converted to decimal precision, causing incorrect amounts to be returned to users.

Flawed Validations Lead To Inaccuracies

Severity: Critical

Ecosystem: Sui

Protocol: Navi

Auditor: OtterSec

Report: https://www.notion.so/a296e98838aa4fdb8f3b192663400772

Report Date: June 2023

Description: In validator.move, validation functions for lending operations use scaled balances (supply and borrow) in conjunction with unscaled amounts, leading to calculation inconsistencies and inaccuracies across multiple functions.

Improper Conversion

Severity: Critical

Ecosystem: Sui

Protocol: Bucket

Auditor: OtterSec

Report: https://www.notion.so/a296e98838aa4fdb8f3b192663400772

Report Date: June 2023

Description: When repay_amount is greater than or equal to Bottle debt, the returned collateral is calculated as 1.1 times the debt amount. However, the debt amount is not adjusted based on the collateral token's decimals during conversion, resulting in improper collateral values (return_sui_amount).

Calculation Formula Error when Adding Liquidity

Severity: Critical

Ecosystem: Sui

Protocol: KriyaDEX

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/KriyaDEX-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: In the get_amount_for_add_liquidity function, the formula for obtaining the other token quantity through one token quantity is incorrect, directly affecting the liquidity addition functionality for users.

Severity: High

Ecosystem: Supra

Protocol: Dexlyn Perp DEX

Auditor: Hacken

Report: https://hacken.io/audits/dexlyn/sca-dexlyn-perp-dex-jul2025/

Report Date: Sep 2025

Description:

Recommendation:

The fee model must be updated to account for all types of position modifications, preventing fee-free value extraction. Modify the fee calculation for decrease orders. When size_delta is zero, the exit_fee should be calculated based on a percentage of the collateral_delta. This ensures that withdrawing funds from a position always incurs a cost.

Incorrect Stable Swap Invariant Recalculation Leads to Incorrect Pricing

Severity: High

Ecosystem: IOTA Mainnet

Protocol: Pools Finance

Auditor: Hacken

Report: https://hacken.io/audits/pools-finance/sca-pools-finance-pools-contracts-may2025/

Report Date: June 2025

Description:

The vulnerability exists in all four swap functions within the amm_router contract. After a swap is completed but before the function returns, the code explicitly calls a function to set a new invariant, fundamentally violating the mathematical basis of a stable swap. By recalculating D on every trade, the contract is not preserving the invariant; it is actively changing it. This action effectively "rebases" the entire pricing curve after each transaction based on the new post-swap reserves. This process introduces small but definite errors, causing the pool's value representation to "drift" away from its true state with each transaction.

Risk of Arithmetic Overflow

Severity: High

Ecosystem: Sui

Protocol: Aftermath Orderbook

Auditor: OtterSec

Report: https://www.notion.so/a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2024

Description: In ticks_per_lot_to_quote_per_base, a multiplication operation between ticks_per_lot and tick_size can overflow if the result exceeds the maximum representable value of a u64, resulting in an integer overflow vulnerability.

Fund Loss Due to Unchecked Conversion

Severity: High

Ecosystem: Sui

Protocol: Aftermath

Auditor: OtterSec

Report: https://www.notion.so/a296e98838aa4fdb8f3b192663400772

Report Date: Jan 2025

Description: An incorrect calculation turns negative values into positive values, causing unexpected profit and fund loss. The conversion is not properly validated, leading to unintended financial outcomes.

Incorrect Price Calculation

Severity: High

Ecosystem: Sui

Protocol: Aftermath

Auditor: OtterSec

Report: https://www.notion.so/a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2023

Description: In math.move, the functions calc_oracle_price and calc_spot_price are intended to calculate the price of BASE coin in terms of QUOTE coin. However, calc_spot_price_fixed incorrectly computes the price of out-coin in terms of in-coin, inverting the intended calculation.

Inconsistent Assert Statement

Severity: High

Ecosystem: Sui

Protocol: Bluefin

Auditor: OtterSec

Report: https://www.notion.so/a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2024

Description: The request_profit_withdraw_from_vault function fails to account for vault.pending_profit_amount in its withdrawal validation, allowing the holding account to inflate pending profits and bypass balance checks. As a result, withdrawals can exceed the actual available profit, leading to potential fund misallocation or loss.

Round Up Shares

Severity: High

Ecosystem: Sui

Protocol: Volo

Auditor: OtterSec

Report: https://www.notion.so/a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2023

Description: By staking the minimum number of Sui repeatedly, due to rounding errors, users can receive more Cert tokens when unstaking than intended, effectively exploiting the protocol.

Precision Loss Results in Rewards being Left in the Contract and Unable to be Withdrawn

Severity: High

Ecosystem: Sui

Protocol: Cetus Farming

Auditor: MoveBit

Report: https://movebit.xyz/reports/Cetus-Farming-Smart-Contract-Final-Audit-Report.pdf

Report Date: Jan 2024

Description: The accumulate_pool_reward() function experiences two instances of precision loss: once when calculating rewards for each pool based on proportion, and again when calculating acc_per_share using pool_acc_reward/total_pool_share. This results in residual rewards that cannot be withdrawn after all users claim their rewards.

pending_reward Is Not Compatible

Severity: High

Ecosystem: Sui

Protocol: Cetus Farming

Auditor: MoveBit

Report: https://movebit.xyz/reports/Cetus-Farming-Smart-Contract-Final-Audit-Report.pdf

Report Date: Jan 2024

Description: In both add_liquidity_fix_coin and remove_liquidity functions, without the addition of pos_info.reward, the pending_reward calculation would be incorrect, causing major problems in reward distribution.

Erroneous Calculation Leads To Unfair Liquidation

Severity: High

Ecosystem: Sui

Protocol: Navi

Auditor: OtterSec

Report: https://www.notion.so/a296e98838aa4fdb8f3b192663400772

Report Date: Jun 2023

Description: In logic.move, the calculate_max_liquidation function has calculation inaccuracies when retrieving max_liquidable_collateral and max_liquidable_debt. These calculation errors create exploitable opportunities for attackers to profit from improper liquidation scenarios.

Accuracy Loss

Severity: High

Ecosystem: Sui

Protocol: SuiPad

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/SuiPad-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: In the claim_rewards function, amount_to_claim is incorrectly calculated, potentially resulting in 0 or unclaimable funds. The calculation should multiply before dividing to reduce accuracy loss.

Incorrect Calculation in amount_to_claim in claim function

Severity: High

Ecosystem: Sui

Protocol: SuiPad

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/SuiPad-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: A calculation error in the condition for amount_to_claim in the claim function causes incorrect reward amounts to be claimed.

Overflow Risk in i64::sub

Severity: High

Ecosystem: Sui

Protocol: Typus Finance

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Typus-Finance-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: The i64::sub operation has an overflow risk, potentially causing unexpected behavior or contract failure.

Improper Reward Calculations in reward_distributor.move

Severity: High

Ecosystem: Unknown

Protocol: Project Zenith

Auditor: MoveJay

Report: https://github.com/Jayfromthe13th/Project-Z-Security-Audit-Report/blob/Wallet/audit.md

Report Date: Mar 2024

Description: The accumulated_gain function inaccurately calculates token earnings, neglecting contributions to subsequent scales, leading to incorrect reward distributions.

Severity: High

Ecosystem: Aptos

Protocol: PancakeSwap

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/PancakeSwap%20Aptos%20-%20Zellic%20Audit%20Report.pdf

Report Date: Nov 2022

Description:

The precision_factor used to avoid division precision errors is not large enough to mitigate truncation to zero errors.

Potential overflow in the add_reward function

Severity: High

Ecosystem: Aptos

Protocol: PancakeSwap

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/PancakeSwap%20Aptos%20-%20Zellic%20Audit%20Report.pdf

Report Date: Nov 2022

Description:

In the add_rewards function there is an assert that may cause an overflow by multiplying two u64 values.

Severity: High

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

Wwhen users unstake, the protocol also updates the magnified dividends per share. The calculation involves adding ((amount as u128) * pool_info.precision_factor / (pool_info.staked_tokens as u128)) to the original per share x or per share y values.

This is incorrect, as it causes the pool_info.magnified_dividends_per_share_x or pool_info.magnified_dividends_per_share_y values to increase without actual rewards being distributed to the rewards pool.

When Calculating Fees for Token Info Y Only, There is An Incorrect Passing of rewards_coins

Severity: High

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

rewards_coins is extracted from metadata.balance_y, but when calling the update_pool() function, it passes these rewards coins to reward_x,causing confusion in calculation logic.

Unstrict Swap Invariant

Severity: High

Ecosystem: Aptos

Protocol: Pontem (Liquidswap)

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Sep 2022

Description:

When dealing with an uncorrelated curve, the program introduced an error by reporting an incorrect swap if the lp_value after the swap is strictly smaller than the lp_value before the swap. The swap should be valid only when the value after is greater than the value before. Otherwise, swapping would be able to exploit potential rounding errors, depending on the precision of the relevant curves.

Improper Calculation in Liquidation

Severity: High

Ecosystem: Aptos

Protocol: Aries Markets

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Nov 2022

Description:

In the else case of the liquidation function, the settle_share_amount should be calculated from the repay_amount using the get_share_amount_from_borrow_amount function. Instead, the repay amount is directly returned as the settle share amount.

Improper Reward Calculations

Severity: High

Ecosystem: Aptos

Protocol: Thala Labs

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2023

Description:

In the protocol module, accumulated_gain calculates the earnings of a token based solely on the scale of the snapshot. However, it is possible for a user’s amount to have participated in the distribution of the next scale as well. As a result, the failure to account for this may lead to incorrect calculations of token earnings.

Improper Reward Calculations

Severity: High

Ecosystem: Aptos

Protocol: Thala

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description:

In the protocol module, accumulated_gain calculates the earnings of a token solely based on the scale of the snapshot. However, a user’s amount may have participated in the distribution of the subsequent scale as well. As a result, the failure to account for this may lead to incorrect calculations of token earnings.

Utilization Of Unsuitable Rounding Direction

Severity: High

Ecosystem: Aptos

Protocol: Meso Lending

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: July 2024

Description:

When calculate_shares performs a floor rounding (rounding down) in share calculations in borrow_internal and withdraw , the user may end up with fewer debt shares than they are entitled to, resulting in them owing more assets than the value represented by their shares. As a result, users will effectively earn funds for free because they are receiving fewer debt shares for their borrowings. The pool’s total debt increases without the user receiving proportional debt shares.

Abort Due to Underflow in Difference Calculation

Severity: High

Severity: Medium

Ecosystem: Sui

Protocol: Mysten Deepbook V3

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2025

Description:

When the user chooses to pay the fee in DEEP, deep_quantity is calculated from fee_quantity. However, if deep_quantity turns out to be 0, the fee may be incorrectly calculated in base or quote instead, resulting in the fee being paid in a way that does not match the user’s intention.

Severity: Medium

Ecosystem: Sui

Protocol: BlueFin

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2024

Description:

In withdraw_from_vault, when a user withdraws funds, the share count vault.total_shares is appropriately reduced. However, a critical vulnerability arises as no corresponding adjustment occurs to vault_total_balance. Although vault_total_balance is calculated based on the current vault balance, it fails to account for the reduced shares resulting from the withdrawal. Consequently, the share price may experience temporary inflation, given that vault_total_balance remains unchanged despite the reduction in total shares.

Price Manipulation

Severity: Medium

Ecosystem: Sui

Protocol: Aftermath Orderbook

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2024

Description:

Currently, during the calculation of premium_twap and spread_twap, lip_max_book_index_spread confines the book_price within a range of plus five to negative five percent of the index_price. Nevertheless, it remains possible to influence the time-weighted average price by manipulating the mark_price within the same percentage range of the index_price.

Incorrectly Calculated Reward Period

Severity: Medium

Ecosystem: Sui

Protocol: Turbos

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2024

Description:

total_elapsed_time skipped if emission = 0.

Missing Tick Step Validation

Severity: Medium

Ecosystem: Sui

Protocol: Turbos

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2024

Description:

Overflow and abort since base_tick_step and limit_tick_step are user inputted.

Volume Overflow Risk

Severity: Medium

Ecosystem: Sui

Protocol: Mysten Deepbook

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Aug 2024

Description:

Self-trading and flash loans can cause overflow.

Improper Order Quantity Calculation

Severity: Medium

Ecosystem: Sui

Protocol: Mysten Deepbook

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Aug 2024

Description:

get_quantity_out and get_level2_range_and_ticks do not account for the remaining quantity of orders.

BigVector Size Overflow

Severity: Medium

Ecosystem: Sui

Protocol: Mysten Deepbook

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Aug 2024

Description:

This is especially relevant due to the Sui Move runtime’s limitation on maximum object size, which is 256000 bytes. If the leaf objects in the BigVector exceed this limit, the Move runtime will throw an error, preventing the order book from functioning correctly.

Prevention of Pool Closure Due to Rounding

Severity: Medium

Ecosystem: Sui

Protocol: Hop Aggregator

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

max_amount_in and amount_out round down. Pool could remain in OPEN state, even though empty.

Withdrawals from staking pools may result in rounding errors, which results in lost rewards

Severity: Medium

Ecosystem: Sui

Protocol: Mysten Labs Sui

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description:

Rounding down issue, if user attempts to withdraw small number of tokens, could round down to nothing.

Precision Loss In Redistribution

Severity: Medium

Ecosystem: Sui

Protocol: Bucket

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: June 2023

Description:

Since the accumulators are not factored by some value, directly dividing the collateral and debt amounts with total stake leads to less precise rounded-down values, which the accumulators add and lead to imprecise accumulation.

Improper Tank Value Update

Severity: Medium

Ecosystem: Sui

Protocol: Bucket

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: June 2023

Description:

start_s and start_g incorrectly updated.

Overflow In Calculation Of Delta A

Severity: Medium

Ecosystem: Aptos

Protocol: Cetus

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Jan 2023

Description:

The numberator value is not validated before running u256::shlw on it. As a result, the non-zero bytes might be removed, which leads to an incorrect calculation of the value.

Precision Loss Issue In Weighted Math

Severity: Medium

Ecosystem: Aptos

Protocol: Thala Labs

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2023

Description:

In the math module, the calculation of the amount taken in during a swap is based on the amount given out, the balances in the pool, and the weights of the assets. calc_in_given_out_internal is responsible for this calculation, which involves using log_exp_math::pow to perform the required exponentiation. log_exp_math::pow used by calc_in_given_out_internal is vulnerable to precision errors, which may return incorrect values. For instance, the function may incorrectly calculate 1.0000000002 ** 1 = 1.0. This precision issue can be exploited in calc_in_given_out_internal, leading to a return value of zero despite a non-zero amount_out value.

Improper Price Deviation Calculation Formula

Severity: Medium

Ecosystem: Aptos

Protocol: Thala Labs

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2023

Description:

get_price_diff_ is responsible for computing price deviation. However, to calculate the percentage of price deviation, the formula should be (diff(new_price, old_price) / old_price) * 100. The current implementation uses new_price as the denominator if new_price > old_price. Use b (old_price) as the denominator in both cases.

Including Interest In Vault CR Calculation

Severity: Medium

Ecosystem: Aptos

Protocol: Thala Labs

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2023

Description:

redeem_collateral and liquidate calculate the collateral ratio (CR) for a vault, however CR is calculated without considering the vault.interest, leading to the use of an incorrect CR value in other calculations.

Incorrect Withdraw Fee Calculation On Update

Severity: Medium

Ecosystem: Aptos

Protocol: Steamflow

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Mar 2023

Description:

In protocol::update, the change in the amount_per_period triggers an additional fee calculation using withdrawal_fees based on contract.start. However, using the start time for fee calculation results in the fee being recalculated for the period.

Improper Fee Amount Calculation With Zero Fees

Severity: Medium

Ecosystem: Aptos

Protocol: Steamflow

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Mar 2023

Description:

protocol::fee_amount is used to calculate the fee for a given amount using the input parameter fees as basis points (bps). However, the case of fees == 0 incorrectly returns the total amount as the fee. Instead, the function should check for fees == 10000 to return the total amount as the fee correctly.

Precision Loss Issue In Weighted Math

Severity: Medium

Ecosystem: Aptos

Protocol: Thala

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description:

log_exp_math::pow used by calc_in_given_out_internal is vulnerable to precision errors, which may return incorrect values.

Severity: Medium

Ecosystem: Aptos

Protocol: Propbase

Auditor: Hacken

Report: https://hacken.io/audits/propbase/sca-propbase-staking-feb2024/

Report Date: Feb 2024

Description:

The Propbase protocol uses $PROPS token for staking operations. The protocol distributes staking rewards as $PROPS to stakeholders. In addition, admin of the protocol sets a penalty_rate during the pool creation. The penalty rate amount can be set between 1 and 50. The purpose of this variable is to penalize early withdrawals.

The penalty calculation can be seen at below:

let penalty = amount / 100 * stake_pool_config.penalty_rate;

Currently, there is no lower bound for withdraw amount in the code. Therefore, it is possible to chunk the total withdraw amount by 99 in order to bypass this penalty according to the formula above.

let penalty = 99 / 100 * stake_pool_config.penalty_rate (0-50);
penalty = 0;

As a result, it is possible to bypass the early withdrawal penalty due to this precision loss.

Incorrect Fee Calculation in Quoter Function Leads to Underestimated Input Amounts

Severity: Medium

Ecosystem: Sui

Protocol: Magma DEX

Auditor: Three Sigma

Report: https://cdn.sanity.io/files/qoqld077/staging/9566473c444a6cfd99c7a6556fa4857950b41de3.pdf

Report Date: July 2025

Description:

The almm_pair::get_swap_in function serves as a quoter function that calculates the required input amount for a given output amount in the ALMM protocol. This function is critical for frontend applications to provide accurate swap quotes and enable proper slippage calculations. The function iterates through bins to calculate the total input amount needed for a desired output. For each bin, it calculates amount_in_without_fee based on the bin's price and then adds the fee amount. However, the function incorrectly uses fee::get_fee_amount_from instead of fee::get_fee_amount for fee calculations.

Unstaking from LP pools will cause underflow and lock user funds

Severity: Medium

Ecosystem: Initia

Protocol: Cabal Liquid Staking

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-04-cabal-liquid-staking-token

Report Date: May 2025

Description:

If the last pool is empty or with insufficient funds an underflow will occur.

The liquidator will incur a loss when performing liquidationCall

Severity: Medium

Ecosystem: Aptos

Protocol: AAVE V3

Auditor: Cantina Contest SRs

Report: https://cantina.xyz/code/ad445d42-9d39-4bcf-becb-0c6c8689b767/findings/192

Report Date: Jun 2025

Description:

ccording to the Aave documentation, the liquidation_bonus must be above 100%.

However, the current calculations result in values below 100% :

(5 * math_utils::get_percentage_factor()) / 100*// (5 * 10000) / 100 = 500* (85 * math_utils::get_percentage_factor()) / 1000*// (85 * 10000) / 1000 = 850*

These values are far below the expected minimum of 10000 (which represents 100%). To be valid, the value must be greater than 10000.

Incorrect Calculation of share_proportion

Severity: Medium

Ecosystem: Aptos

Protocol: Echelon

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Echelon%20-%20Zellic%20Audit%20Report%20(January).pdf

Report Date: Jan 2025

Description:

asset_amounts * BPS_BASE / deposit_amounts will not properly calculate the percentage of the deposit. Currently, the number of users is divided by the total number of tokens, so the exact ratio is not calculated.

The operator can Evade The Fees When Loaning Assets

Severity: Medium

Ecosystem: Aptos

Protocol: Amnis

Auditor: MoveBit

Report: https://movebit.xyz/reports/Amnis-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

The function pegging.loan_apt() allows the operator to withdraw funds from the protocol, but a certain fee is required when returning the funds. The fee calculation is as follows: math64::mul_div(amount, pegging().loan_fee, BPS_MAX) According to the protocol configuration, we found that loan_fee is 10, and BPS_MAX is 10000. When amount * 10 < 10000 , users will not have to pay any fees. Therefore, the operator can repeatedly borrow 999 to avoid the fees. It is recommended to set a minimum loan amount or to check if the fee is 0, in which case borrowing assets should not be allowed.

Rounding Errors Handling Is Not Best Practice

Severity: Medium

Ecosystem: Aptos

Protocol: Superposition

Auditor: MoveBit

Report: https://movebit.xyz/reports/Superposition-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

In both borrow and repay functions, a rounding handling increases amount by one. However, this brutal force method is not a good practice since it may add one extra layer to the rounding (if it is already rounded up).

Assert condition is not accurate

Severity: Medium

Ecosystem: Aptos

Protocol: Aries Market

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Market-Contracts-Audit-Report.pdf

Report Date: Mar 2023

Description:

In decimal.move, an assert is provided to prevent overflow, but the conditions are not strict and U64_MAX * U64_MAX does not equal U128_MAX.

Additionally, first if statement inside calculate_fees function directly reads pool.fullsail_distribution_staked_liquidity instead of passed-in staked_liquidity parameter and split_fee lacks validation for total_growth != 0 before performing divisions.

Incorrect Overflow Handling in overflow add

Severity: Low

Ecosystem: Sui

Protocol: Momentum CLMM

Auditor: Asymptotic

Report Date: Aug 2025

Description:

The overflow add function in integer-mate/math u256.move is meant to safely add two u256 values with wrapping. However, a precedence bug in the overflow branch causes an unintended underflow and immediate abort. When an overflow is detected, the function computes value2 - MAX U256 - value1 - 1, which causes an abort on the first subtraction due to underflow. The function is currently only used in oracle::transform, where overflow is not expected given typical input values, so this bug is unlikely to be triggered in practice. If the function is reused in other contexts or if the oracle logic changes, this bug could lead to unexpected aborts.

Severity: Low

Ecosystem: Sui

Protocol: Solend Steamm

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2025

Description:

pool_math::tokens_to_deposit attempts to calculate the optimal deposit amounts a_star (for token A) and b_star (for token B) based on the current reserve ratios while adhering to user-specified maximum constraints max_a and max_b. However, the approach may overestimate the required tokens under certain conditions. When calculating b_star, if max_a * reserve_b is not divisible by reserve_a , the returned values may include a dust amount. This implies that users may inadvertently attempt to supply more tokens than necessary to maintain the correct reserve balance.

Division by Zero Error

Severity: Low

Ecosystem: Sui

Protocol: Solend Steamm

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2025

Description:

In the current implementation, it is possible for the pool to have one of the reserves fully drained. In pool_math::tokens_to_deposit, the core logic calculates the amount of token B ( b_star ) a user should deposit based on the current ratio between the reserves of token A and token B. The function utilizes the safe_mul_div_up helper function to scale the deposit amounts accordingly. If reserve_a == 0, the division in safe_mul_div_up will attempt to divide by zero, resulting in an abort.

Similarly, lp_tokens_to_mint calculates the number of LP tokens to mint based on the user’s deposit relative to the pool’s existing reserves. If one of the reserves ( reserve_a and reserve_b is zero, it will result in division by zero in safe_mul_div.

Precision Loss in Calculation of Token X Amount

Severity: Low

Ecosystem: Sui

Protocol: Kuna Labs

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: June 2025

Description:

When computing the amount of token X locked in the LP position for a given price and liquidity, position_model::x_by_liquidity_x64 performs the calculation by dividing before multiplying ( x_x64 = delta_l * (num / denom) ). This may result in a loss of precision when num < denom , resulting in (num / denom) to round down to zero. As a result, x_x64 becomes zero even if delta_l is large, incorrectly implying no X is in the position. This affects margin calculations, deleveraging, and liquidation logic.

Users Cannot Unstake Small Amounts In request_unstake_instant Due To Service Fee

Severity: Low

Ecosystem: Sui

Protocol: Haedel

Auditor: MoveBit

Report: https://movebit.xyz/reports/Haedal-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

In request_unstake_instant users can unstake any amount from the vault balance and there's some service fee being taken from users. However, this design will prohibit small amount unstakes.Since there are no min unstaking threshold, users can unstake as small as 1 mist. However, let's say if max_exchange_sui_amount = 10 mist, then take service_fee as the default one which is 90.

let fee_amount = ((max_exchange_sui_amount as u128) * (service_fee as u128) /
(FEE_DENOMINATOR as u128) as u64);

fee_amount = 10*90/1000 = 0. And this will fail the below assertion even though service_fee is certainly above 0.

Improve Precision With sqrt_u128

Severity: Low

Ecosystem: Sui

Protocol: MovEX

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/MovEx-Smart-Contract-Audit-Report.pdf

Report Date: May 2023

Description:

In Sui Framework, there are two kinds of inclusions, sqrt, and sqrt_u128 . When calculating share, multiplying two u64 can use sqrt_u128 to improve the accuracy.

Severity: Low

Ecosystem: Aptos

Protocol: Amnis Finance

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2024

Description:

router::request_withdraw handles rounding errors that may occur during the unstaking process. However, instead of charging the user for the rounding error, the protocol currently pays for it by burning amAPT tokens from the treasury. By having the protocol cover rounding errors, users are relieved of the financial burden of these discrepancies. As a result, users may exploit the system.

Although small individually, rounding errors accumulate over time and can become a significant drain on the protocol’s resources if consistently subsidized. This behavior may deplete the treasury or introduce long-term imbalances in the token economy.

Improper Interest Accumulation Calculation

Severity: Low

Ecosystem: Aptos

Protocol: Thala Labs

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Code Snippet: N/A

Description:

In sync_interest_rate, the value of days_elapsed is derived by dividing seconds_elapsed by the number of seconds in a day. This calculation results in the truncation of any remaining seconds, which can cause the value of days_elapsed to be rounded down. As a result, if seconds_elapsed is equal to 1 day, 23 hours, and 59 minutes, the value of days_elapsed would be rounded down to 1. This causes the new interest index to be calculated for only 1 day, and the last updated timestamp would be incorrect by 23:59 hours. Consequently, the global interest index ratio and interest on vaults may be lower than expected.

Improper Withdrawal Fee Calculation Formula

Severity: Low

Ecosystem: Aptos

Protocol: Thala Labs

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description:

The withdrawal fee calculation is handled by withdraw_mod. To determine the withdrawal fee amount, the intended formula should utilize the (1 - (elapsed_time / withdrawal_fee_period)) * withdrawal_fee_max_ratio formula, which is designed to proportionally decrease the withdrawal fee over time. However, in the implemented formula, the cover_ratio is not subtracted from one when calculating the fee_ratio value. As a result, users who withdraw shortly after depositing may encounter almost zero withdrawal fees, while those who withdraw just before the withdrawal period may face maximum withdrawal fees.

Overflow In Calculation Of Sqrt Price

Severity: Low

Ecosystem: Aptos

Protocol: Cetus

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Jan 2023

Description:

The numberator calculation in get_next_sqrt_price_a_up does not check if the u256::shlw operation removes the non-zero bytes. There is a possibility that sqrt_price multiplied by liquidity will return a result large enough that a shift left by 64 bits will remove the non-zero bits.

Incorrect Repay Rounding

Severity: Low

Ecosystem: Aptos

Protocol: Argo

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2022

Description:

The required USDA repaid is calculated in required_repay_amount_internal. This function should round up instead of down to properly round against the user. Otherwise, for small repayment amounts, it might be possible to further decrease the health of the vault.

Instant Unstake Fee Can Be Bypassed

Severity: Low

Ecosystem: Aptos

Protocol: Ditto

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2022

Description:

Users can unstake their stAPT instantly or delayed. In order to unstake instantly, a fee, which is defined in the configuration parameter instant_unstake_fee_bps , is charged. The fee is computed using the utils::calculate_fee function:

This allows an attacker to pay no fees for small amounts, because the fee rounds down to zero. More specifically, whenever the amount < (BPS_DENOMINATOR / fee_bps), the fee can be avoided.

Residual Coin Unable to be Extracted

Severity: Low

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

Due to precision loss, there is a persistent issue of residual coins in the RewardsPoolUserInfo that cannot be extracted. Every time the update_pool function is called during a transaction to distribute rewards from the rewards_pool to users staking and to update acc_token_per_share, the value of acc_token_per_share is rounded down due to precision loss. As a result, users are consistently unable to claim the full rewards_pool. However, the rewards_pool continues to accumulate in the RewardsPoolUserInfo. This means that with each transaction, if there is precision loss, the unrecoverable portion of the rewards_pool accumulates in the RewardsPoolUserInfo, making it unclaimable.

Computational Precision Loss

Severity: Low

Ecosystem: Aptos

Protocol: Mole

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mole-Aptos-Audit-Report.pdf

Report Date: Feb 2023

Description:

The formula in the code is square extraction first and then multiplication, which can be changed to multiplication first and then square extraction if there is no overflow, or the high-precision sqrt function can improve the accuracy.

Inaccuracy in liquidswap::stable_curve computations

Severity: Low

Ecosystem: Aptos

Protocol: LiquidSwap

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Pontem Liquidswap - Zellic Audit Report.pdf

Report Date: Nov 2022

Description:

Liquidswap provides peripheral modules for interacting with the protocol. The liquidswap::stable_curve module exposes helper functions for computing exchange amounts. Liquidity pools for correlated coins utilize a different curve. Specifically, if the reserves of two coins are x and y, then it maintains that c = x ^ 3 y + y ^ 3 x must increase across exchanges. To help compute quantities, the internal function stable_curve:)g et_y is used to find y given x and c.

Incorrect rounding behavior in router::get_coin_in_with_fees

Severity: Low

Ecosystem: Aptos

Protocol: LiquidSwap

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Pontem Liquidswap - Zellic Audit Report.pdf

Report Date: Nov 2022

Description:

In the function router::get_coin_in_with_fees, the result is rounded up incorrectly for both stable and uncorrelated curves, which can lead to an undue amount being paid in fees. The formula for rounding up integer division is (n - 1)/d + 1 for n > 0.

Implicit precision loss in stable_curve::lp_value

Severity: Low

Ecosystem: Aptos

Protocol: LiquidSwap

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Pontem Liquidswap - Zellic Audit Report.pdf

Report Date: Nov 2022

Description:

In stable_curve::lp_value, coins with more than eight decimals experience implicit precision loss. The current implementation returns the LP value scaled by (10 ^ 8) ^ 4 in order to maintain precision across division. However, this means that stable_curve::lp_value will return inaccurate values when coins have more decimals.

Wrong overflow check in percent_div

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The canonical overflow prevention check for the (value * PERCENTAGE_FACTOR + percentage / 2) / percentage computation should be corrected.

Unnecessary checks in wad_ray_math

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

Some checks in wad_ray_math.move‘ are unnecessary or simply always true.

Potential Overflow in u128 to u64 Conversion

Severity: Low

Ecosystem: Aptos

Protocol: Hyperionxyz Vaults

Auditor: ExVul

Report: https://github.com/ExVul-Sec/AuditReport/blob/main/Smartcontract/Hyperion Smart Contrat Audit Report-Exvul.pdf

Report Date: Apr 2025

Description:

In the mint_to function within the lp.move contract, a u128 value is directly cast to u64 without any bounds checking. This may result in silent truncation or transaction aborts if amount > u64::MAX, which can occur in high-liquidity scenarios or incorrect mint calculations. Such overflows break value consistency and may cause minting fewer LP tokens than intended or runtime panics.

Integer Truncation Risk in LP Minting

Severity: Low

Ecosystem: Aptos

Protocol: Hyperionxyz Vaults

Auditor: ExVul

Report: https://github.com/ExVul-Sec/AuditReport/blob/main/Smartcontract/Hyperion Smart Contrat Audit Report-Exvul.pdf

Report Date: Apr 2025

Description:

In the deposit_with_pair function of the vaults.move contract, the mint_amount is calculated as a u128 using the lp_mint_amount function.

However, it is later cast directly to u64 and added to vault.total_shares.

This direct cast risks integer truncation if mint_amount > u64::MAX, which can silently corrupt share accounting or cause overflows during subsequent additions.

Unnecessary calculations for old stakeholders

Severity: Low

Ecosystem: Aptos

Protocol: Propbase

Auditor: Hacken

Report: https://hacken.io/audits/propbase/sca-propbase-staking-feb2024/

Report Date: Feb 2024

Description:

The implement_unstake function currently lacks proper handling of important state variables when a user withdraws their entire stake. Specifically, the stake_pool_config.staked_addresses variable is not appropriately decreased in such instances. This oversight has implications for functions like calculate_required_rewards() and emergency_asset_distribution(), as they currently consider users with zero stakes in their calculations.

Users with low stake amounts cannot get any rewards due to precision loss

Severity: Low

Ecosystem: Aptos

Protocol: Propbase

Auditor: Hacken

Report: https://hacken.io/audits/propbase/sca-propbase-staking-feb2024/

Report Date: Feb 2024

Description:

The current implementation lacks a lower bound for the min_stake_amount, leading to potential issues for users with stakes lower than seconds_in_year. For instance, if a pool is created with a min_stake_amount of 1000000, there is a risk that the interest_per_rate calculation may consistently return zero due to precision loss.

Overflow Mitigations Removed in `mul_div_rounded()`

Severity: Low

Ecosystem: Aptos, Initia, and Movement

Protocol: Echelon Market

Auditor: Quantstamp

Report: https://certificate.quantstamp.com/full/echelon-market/9ee15c30-6a0f-4a70-b5ce-63b8a887bd4e/index.html

Report Date: Mar 2025

Description:

To prevent overflows, the mul_div_rounded() function contained unsigned integer widenings (... as u128), which, however, have been removed during the code port. This could unnecessarily lead to overflows and failing calls where mul_div_rounded() is being used.

Division Overflow in Float and Double Arithmetic

Severity: Low

Ecosystem: Sui

Protocol: BalancerV2

Auditor: Quantstamp

Report: https://certificate.quantstamp.com/full/bucket-protocol-v-2/abd312d6-1a5e-45c5-963b-a6856daf6621/index.html

Report Date: Aug 2025

Description:

The div() functions in both float and double modules can trigger runtime panics when dividing large values. The division performs (a.value * WAD) / b.value, which overflows when a.value * WAD exceeds the type's maximum value (u128 for float, u256 for double). This creates an overflow threshold of approximately u128::MAX / 10^9 for float operations.

Potential overflow risk in interest rate updates

Severity: Low

Ecosystem: Aptos

Protocol: Yeap Finance

Auditor: SlowMist

Report: https://github.com/slowmist/Knowledge-Base/blob/master/open-report-V2/smart-contract/aptos-smart-contract/yeap-finance%20-%20SlowMist%20Audit%20Report.pdf

Report Date: July 2025

Description:

In the vault_snapshot module, the preview_accure_interest function is used to calculate the protocol's accumulated interest rate. When calculating the multiplier , the pow function is used for exponentiation. This implies that if the protocol's interest rate is not updated for an extended period, timeElapsed could become excessively large, causing the multiplier calculation to overflow and lead to an abort. This would prevent the protocol from performing normal interest rate updates, resulting in a Denial of Service (DoS).

bin::get_amounts is always rounding down

Severity: Low

Ecosystem: Sui

Protocol: Magma DEX

Auditor: Three Sigma

Report: https://cdn.sanity.io/files/qoqld077/staging/9566473c444a6cfd99c7a6556fa4857950b41de3.pdf

Report Date: July 2025

Description:

When getting the maximum input amount for the user to be paid in order for a given output amount. we round the operation down and now Up in Bin::get_amount.

protocol fees calculations are rounded down not up

Severity: Low

Ecosystem: Aptos

Protocol: Magma DEX

Auditor: Three Sigma

Report: https://cdn.sanity.io/files/qoqld077/staging/9566473c444a6cfd99c7a6556fa4857950b41de3.pdf

Report Date: July 2025

Description:

The Protocol uses TradeJoeV2 Order Book AMM. The fees are categorized into two. Base and variable. In tradeJoe calculating the baseFee is by multiplying by 1e10 (no division). And for variable_fee they are dividing by 100 but they add 99 to the numerator first. The fees in TradeJoe is e18 and the calculations ends of a number of 100e18 but they add 99 before dividing to 100. The reason for this is to Round Up the division. This is a comman pattern in Mathematics numerator * (divider - 1) / divider. which is used to end the divide of rounding Up and not Down. So that the calculations goes on behalf of the protocol.

In our implementation, we are not doing this. as even in base_fee we divide to 100 and for variable fee we divide but add 99 only instead of adding divider - 1 which will end up of the calculation rounding down not Up.

Centralization Risk - Overview

Single points of control (e.g., owner-only functions) that undermine decentralization or enable abuse.

Centralization Risk	Findings
High	8
Medium	10
Low	7
Total	25

High Findings

BKT Token Centralization Risk

Severity: High

Ecosystem: Sui

Protocol: Bucket

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Bucket-Protocol-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description:

The allocate_bkt function has too much authority and can be locked up by anyone, in any amount, and at any time, which creates a risk of centralization.

Recommendation:

Manage BktAdminCap with multi-signature account to mitigate the risk.

Centralization Risk (Aftermath Finance)

Severity: High

Ecosystem: Sui

Protocol: Aftermath Finance LSD

Auditor: MoveBit

Report: https://movebit.xyz/reports/Aftermath-Finance-Liquid-Staking-Derivative-Audit-Report.pdf

Report Date: Nov 2023

Description:

The admin account holds multiple powerful permissions. If compromised, an attacker could manipulate the protocol or its assets. See the full report for a detailed list of admin capabilities.

Centralization Risk (KunaLabs)

Severity: High

Ecosystem: Sui

Protocol: KunaLabs Yield Optimizer

Auditor: MoveBit

Report: https://movebit.xyz/reports/Yield-Optimizer-Final-Audit-Report.pdf

Report Date: Nov 2023

Description:

Severity: High

Ecosystem: Sui

Protocol: Volo

Auditor: MoveBit

Report: https://movebit.xyz/reports/Volo-Smart-Contract-Audit-Report.pdf

Report Date: Sep 2023

Description:

There are some risks of centralization in the contract, the admin can set the total_rewards of the NativePool, which will result in a change in the rate calculation of the contract.

Centralization Risk

Severity: High

Severity: Low

Ecosystem: Aptos, Initia, and Movement

Protocol: Echelon Market

Auditor: Quantstamp

Report: https://certificate.quantstamp.com/full/echelon-market/9ee15c30-6a0f-4a70-b5ce-63b8a887bd4e/index.html

Report Date: Mar 2025

Code: N/A

Description:

The protocol allows the administrator to pause different operations independently. One of these operations is liquidations. However, during high volatility, this can lead to huge amounts of bad debt piling up very quickly.

Cross Implementation - Overview

Inconsistencies between contract versions or mirrored implementations causing unexpected outcomes.

Cross-Implementation	Findings
Medium	2
Low	14
Total	16

Medium Findings

collector and AToken treasury incompatibilities

Severity: Medium

Ecosystem: Aptos

Protocol: AAVE Periphery

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.1-V3.3%20Report.pdf

Report Date: Jun 2025

Description:

A few different design issues in the collector.move module compared to the Solidity contracts.

GHO is misconfigured in Aptos Deployment

Severity: Medium

work

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

In Aave's Solidity implementation, the validation_logic::validate_automatic_use_as_collateral function checks whether the msg.sender has the ISOLATED_COLLATERAL_SUPPLIER_ROLE. (As the logic contracts are delegatecalled, the msg.sender is for example the Pool contract). The purpose of the role is for migration contracts to be able to set collateral flags on behalf of users when dealing with isolated assets.

set_reserve_interest_rate_strategy should perform additional sanity checks on the input parameters

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The set_reserve_interest_rate_strategy logic is currently only performing a sanity check on the optimal_usage_ratio input parameter. Following the logic applied by DefaultReserveInterestRateStrategyV2, the set_reserve_interest_rate_- strategy should also implement the following required sanity checks: • optimal_usage_ratio <= MAX_OPTIMAL_POINT. • optimal_usage_ratio >= MIN_OPTIMAL_POINT. • variable_rate_slope1 <= variable_rate_slope2. • base_variable_borrow_rate + variable_rate_slope1 + variable_rate_slope2 <= MAX_BORROW_RATE. On solidity, the above constant values (used as lower/upper bounds) are defined as follows: • uint256 public constant MAX_BORROW_RATE = 1000_00;. • uint256 public constant MIN_OPTIMAL_POINT = 1_00;. • uint256 public constant MAX_OPTIMAL_POINT = 99_00;. Note that in Solidity, the above constant values are expressed in bps and must be converted into the format used by the Aptos implementation (RAY).

validate_flashloan_complex is not reverting when the list of assets have duplicates

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The validate_flashloan_complex is missing a sanity check introduced Aave v3.1.0 (see ValidationLogic.sol#L338-L340) that requires the uniqueness of the asset requested to be flashloaned. This check should be added to the Aptos implementation.

pool_configurator module should expose a getter function for the pending_ltv value of a reserve

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The pool_configurator module defines the pending_ltv in the Global Storage.

In the Solidity implementation, it's possible to fetch such information for a specific asset via the getPendingLtv(address asset) function. This feature is not available in the Aptos codebase and should be implemented.

finalize_transfer should use the scaled_amount and not amount

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The current implementation of pool_token_logic::finalize_transfer performs the transfer validation and user config updates if the amount is greater than zero. This logic has been correctly changed in the Aave Solidity Implementation (see SupplyLogic.sol#L191-L193) to not rely on the non-scaled amount but on the scaled one. While amount could be greater than zero (the one specified by the user), the transfer operation transfers from an account to another the scaled version of that amount, that could be equal to zero because of rounding down. To avoid any possible errors and unexpected behaviors, the Aptos implementation should be aligned to the Solidity one.

Aave Reward System Management, documentation and concerns(further review)

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Periphery

Auditor: Spearbit

Report:

https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit Aave Aptos Periphery V3.0.2 Report.pdf

Report Date: Jun 2025

Description:

On Aave Protocol EVM, the Reward system is currently configured as follows: each reward has its own TransferStrategy which will transfer the rewards (depending on the strategy itself) from a specific REWARDS_- VAULT. From the research done by Spearbit for Aave Reward system on the Ethereum Mainnet, every configured reward uses the same deployed PullRewardsTransferStrategy that will pull from the same REWARDS_VAULT. The REWARDS_VAULT configured is the "ACI multisig address" 0xac140648435d03f784879cd789130F22Ef588Fcd, which in practice can be considered a Smart Wallet. We assume that, on Solidity, the ACI multisig will provide just the allowance needed by the PullRewardsTransferStrategy to correctly limit what an external source (like the strategy) can pull in case of a problem/hack. • Problem 1: lack of proper explanation and documentation relative to the rewards_vault: On the Aptos side, we only know what has been provided as a "dev comment" on top of the rewards_vault attribute itself.

Wrong bounds check in rewards_controller::update_reward_data

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Periphery

Auditor: Spearbit

Report:

https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit Aave Aptos Periphery V3.0.2 Report.pdf

Report Date: Jun 2025

Description:

The rewards_controller::update_reward_data function wants to assert that the new_index fits into 104 bits (to align with the Solidity implementation).

However, it performs a wrong bounds check, the MAX_U104 is 2 ** 104 - 1, not 2 ** 104.

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.1-3.3 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit Aave Aptos Core V3.1-V3.3 Report.pdf

Report Date: Jun 2025

Description:

The current implementation of pool_configurator::set_reserve_freeze is not reverting when the state of the reserve is equal to the freeze input parameter. This issue has been already reported and addressed on the Aave Solidity Implementation codebase (see Cantinacontest-AaveV3.1 and should also be replicated on the Aptos codebase.

Full removal of the admin_controlled_ecosystem_reserve

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.1-3.3 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit Aave Aptos Core V3.1-V3.3 Report.pdf

Report Date: Jun 2025

Description:

By looking at the Aave V3.3 codebase in GitHub relative to the Treasury management, we can see that the "old" AdminControlledEcosystemReserve contract has been fully removed. From our own research, such a contract is not used anymore within the Aave ecosystem, and the removal from the codebase is validating our hypothesis. On every EVM chain, the AToken treasury is deployed as a Collector contract, and the REWARDS_ VAULT of the PullRewardsTransferStrategy contract is configured as the "ACI multisig address" 0xac140648435d03f784879cd789130F22Ef588Fcd. Given all these facts, we think that the aave_pool::admin_controlled_ecosystem_reserve should be fully removed from the Aave Aptos Implementation codebase.

Code Optimization - Overview

Enhancements to modules like removal of duplicate logic, unused functions, or dead code.

Code Optimization	Findings
Low	43
Total	43

Low Findings

`get_coin_type` are `get_fee_coin_type` are redundant

Severity: Low

Ecosystem: Sui

Protocol: Bluefin RFQ

Auditor: Asymptotic

Report: https://bluefin.io/blog/doc/bluefin_rfq_audit.pdf

Report Date: Feb 2025

Description:

Unless we are missing something, get_coin_type is actually idempotent. type_name::into_string just returns the name of the type, does not do any special conversion to ASCII. Further converting from UTF8 to bytes and back to UTF8 is redundant.

But assuming that it would actually do something, it would be potentially harmful: the point is to have a 1-to-1 connection between the coin type keys in Vault and the coin type included in the externally-signed Quote. If somehow two coins would transform to the same string via get_coin_type , this would allow an attacker to pay with a different coin type. Still, even this scenario is not possible as borrow_mut would fail with EFieldTypeMismatch.

Unnecessary public entry modifiers

Severity: Low

Ecosystem: Sui

Protocol: ZO Perps(Sudo)

Auditor: Asymptotic

Report: https://info.asymptotic.tech/sudo-audit-report

Report Date: Mar 2025

Description:

A function should be either public or entry, not both. An entry function can called from a PTB, but not from another module/package. An entry function can change it’s declaration on package upgrades. We recommend deciding on which functions should be called from other packages, which should be public, and the rest should be entry. If you want maximum flexibility, you can create entry functions that call directly the public functions, and call the entry functions from the transactions.

Redundant Code Duplication for Liquidity Calculations

Severity: Low

Ecosystem: Sui

Protocol: Full Sail CLMM

Auditor: Asymptotic

Report: https://info.asymptotic.tech/full-sail-clmm-audit

Report Date: May 2025

Description:

The codebase contains duplicate implementations of critical mathematical functions related to liquidity calculations. Specifically, there is a copy of get_amount_by_liquidity from the clmm_math module directly in the pool module. Additionally, there's a renamed copy of get_liquidity_by_amount (renamed to contain "from" instead of "by"). These duplications create unnecessary maintenance burden and increase the risk of inconsistencies between implementations.

Redundant Math Functions in full math u128 and math u128

Severity: Low

Ecosystem: Sui

Protocol: Momentum CLMM

Auditor: Asymptotic

Report Date: Aug 2025

Description:

The full math u128 module contains several utility functions: • overflowing add / overflowing sub • wrapping add / wrapping sub • min / max These are also present in math u128, where they logically belong. However, only full math u128 is actively used throughout the codebase, while math u128 is not. This duplication increases maintenance overhead and the risk of inconsistencies.

Use of Magic Error Codes and Unused Error

Severity: Low

Ecosystem: Sui

Protocol: Momentum CLMM

Auditor: Asymptotic

Report Date: Aug 2025

Description:

Several modules use hardcoded numeric literals (””magic numbers””) as error codes in assert! statements, rather than referencing named error constants. This practice reduces code clarity and increases the risk of inconsistencies or accidental overlap with actual error codes: • slipppage check.move, lines 5, 7: assert!(arg1 ¡ pool::sqrt price¡T0, T1¿(arg0), 111); • storage/tick.move, line 132: assert!(liquidity gross after ¡= max liquidity, 99); • storage/pool.move, line 293: assert!(enabled, 999); • utils/bit math.move, lines 2, 47: assert!(value ¿ 0, 0); • utils/sqrt price math.move, lines 82, 91: assert!(current price ¿ 0 && liquidity ¿ 0, 4); • storage/tick bitmap.move, lines 7, 80: assert!(mmt v3::i32::abs u32(value) ¡ 256, 0); assert!(mmt v3::i32::abs u32(tick index) % tick spacing == 0, 0); Some of these values overlap with actual error codes defined in error.move. Additionally, the invalid amounts error code is defined but not used anywhere in the codebase.

Severity: Low

Ecosystem: Sui

Protocol: Cetus Concentrated Liquidity Protocol (Sui)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Sui-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: The two functions contains and is_some_and_eq are logically the same.

Multiple Coin Object Support

Severity: Low

Ecosystem: Sui

Protocol: Cetus Concentrated Liquidity Protocol (Sui)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Sui-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

Because each token of Sui is independent, it is recommended to support vector<Coin> , vector<Coin> in functions pool_script::create_pool_with_liquidity*, pool_script::open_position_with_liquidity*, pool_script::add_liquidity*, pool_script::swap*, and follow-up operations after merging.

Remaining TODO

Severity: Low

Ecosystem: Sui

Protocol: Cetus Concentrated Liquidity Protocol (Sui)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Sui-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

There is still a part of TODO in the code, it is recommended to check whether the functions are complete.

Functions with Similar Functionality

Severity: Low

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

Within fee_on_transfer.move , the functions get_info() and get_fee_on_transfer_info() serve the same purpose. The only difference lies in their visibility. get_fee_on_transfer_info() can entirely replace get_info(). Redundant code may lead to increased gas consumption and impact code readability.

Code Refactoring Suggestions in router_v2 Module

Severity: Low

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

In the router_v2 module, lines 40, 54, 69, and 82 can be replaced with a function named assert_pair_is_created() , as they serve the same purpose. This change would enhance readability and understanding while reducing code duplication. Additionally, the code on line 55 is repeated across multiple functions and could be encapsulated into its function for reusability.

The Specification for Assert Statements

Severity: Low

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

The error codes in assert statements show a number of '1's. Best practice suggests using constants, ensuring different error code constants have distinct values.

Optimization through Consolidating claim_rewards() and unstake_tokens() Functions

Severity: Low

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

The functions claim_rewards() and unstake_tokens() within the stake module have almost identical code. Invoking unstake_tokens(sender, 0) within the claim_rewards() function achieves the same effect. Encapsulating the code within the unstake_tokens() function into a common function for caller use reduces redundant code and enhances readability and understanding.

Redundant Operations in the Code

Severity: Low

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.distribute_dex_fees(), it is unnecessary for the protocol to extract liquidity_fee_coins from metadata.balance_y and then immediately merge it back into metadata.balance_y.

Code Redundancy in The toggle_individual_token_liquidity_fee() Function

Severity: Low

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

The code below has redundant blocks of code for both branches where type_info::type_of() == type_info::type_of() and type_info::type_of () == type_info::type_of() . Regardless of which branch is taken, the same logic is executed. This redundancy could be streamlined to improve code readability and maintainability.

Redundant Pair Creation Check in init_rewards_pool() Function

Severity: Low

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

The purpose of the function router_v2.create_rewards_pool () is to create a rewards pool for a pair of tokens (X, Y or Y, X).

After checking whether a pair of tokens (X, Y or Y, X) has been created using swap_v2.is_pair_created() and raising an error (E_PAIR_NOT_CREATED), the code proceeds to call swap_v2.init_rewards_pool() . However, within the init_rewards_pool() function, there is an additional check for the creation of the pair. This redundant pair creation check inside the init_rewards_pool function is unnecessary and duplicates the validation already performed in the calling function.

Unnecessary Boolean Comparison

Severity: Low

Ecosystem: Aptos

Protocol: MoveGPT

Auditor: MoveBit

Report: https://movebit.xyz/reports/MoveGPT-Final-Audit-Report.pdf

Report Date: Apr 2024

Description:

There are statements in the contract that use Boolean variables to compare with Boolean values, such as order_is_exist(order_id,buy_orders) == false , and it is recommended to just use that field's value directly.

Code Optimization

Severity: Low

Ecosystem: Aptos

Protocol: MoveGPT

Auditor: MoveBit

Report: https://movebit.xyz/reports/MoveGPT-Final-Audit-Report.pdf

Report Date: Apr 2024

Description:

There is a lot of duplicate code in the set* function associated with setting global variables, such as vesting_config.start = new_start_time or vesting_config.vesting_duration = new_duration_time, and the same code can be extracted to make the code more readable.

Deprecated Function can Still be Used

Severity: Low

Ecosystem: Aptos

Protocol: StreamFlow

Auditor: MoveBit

Report: https://movebit.xyz/reports/StreamFlow2-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

The comments of the collect_fees function indicate that this function has been deprecated and should not be used, but the function can still be called normally, which may cause unnecessary losses.

Redundant conditional statement

Severity: Low

Ecosystem: Aptos

Protocol: Mokshya/Wapal Aptos NFT Mint Smart Contract

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mokshya-Wapal-Aptos-NFT-Mint-Smart-Contract-Audit.pdf

Report Date: Mar 2023

Description:

Whether to enter the if (nfts < 1024) statement in the function candymach ine::create_bit_mask has no effect on the values of full_buckets and remaining.

Assertions can be optimized

Severity: Low

Ecosystem: Aptos

Protocol: Mole

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mole-Aptos-Audit-Report.pdf

Report Date: Feb 2023

Description:

In the coin::destroy_zero function, it will be judged whether the balance of the coin is 0, and it will only be destroyed when it is 0, so there is no need to judge whether the value is 0 in the source code.

Too many repetitive codes

Severity: Low

Ecosystem: Aptos

Protocol: Mole

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mole-Aptos-Audit-Report.pdf

Report Date: Feb 2023

Description:

The two directories in the screenshot below have more than 90% of the same codes, the code maintenance is more troublesome.

Many TODOs in code

Severity: Low

Ecosystem: Aptos

Protocol: Mole

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mole-Aptos-Audit-Report.pdf

Report Date: Feb 2023

Description:

There are still many TODOs in code, such as spec files, work, and unit tests which should be completed.

pool:: add_liquidity_fix_coin & pool::add_liquidity have many duplicated codes

Severity: Low

Ecosystem: Aptos

Protocol: Cetus Concentrated Liquidity Protocol(Aptos)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Aptos-Audit-Report.pdf

Report Date: Jan 2023

Code Snippet: N/A

Description:

These two functions are very important to add liquidity, but they have 80% duplicated codes, which can be wrapped into a common function, and improve the code maintainability.

Gas cost is higher than other DEX

Severity: Low

Ecosystem: Aptos

Protocol: Cetus Concentrated Liquidity Protocol(Aptos)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Aptos-Audit-Report.pdf

Report Date: Jan 2023

Description:

We tested create_pool, add_liquidity and swap in module clmm_router, and we found the average gas consumption for these operations is 0.0n level. This is somehow higher than other AMM DEX. As a CLMM DEX, Cetus definitely will have higher gas, and we already found some gas-optimization issues which Cetus has already taken, but Cetus still should improve to reduce the gas.

The definition of the variable should be placed where it is used

Severity: Low

Ecosystem: Aptos

Protocol: Transit Finance

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Transit-Finance-Audit-Report.pdf

Report Date: Nov 2022

Description:

The function get_intermediate_out_from_dexs in the aggregator module defines let amount_in_value = coin::value(&x_in); at the beginning, but the amount_in_value is used only under the dex_type == AUX_DEX condition.

All comments starting with the first letter without capitalization

Severity: Low

Ecosystem: Aptos

Protocol: MoveDID

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/MoveDID-Aptos-Contracts-Audit-Report.pdf

Report Date: Nov 2022

Code Snippet: N/A

Description:

The codes have inconsistent comment style with Aptos Framework.

Identical log events

Severity: Low

Ecosystem: Aptos

Protocol: Yeap Finance

Auditor: SlowMist

Report: https://github.com/slowmist/Knowledge-Base/blob/master/open-report-V2/smart-contract/aptos-smart-contract/yeap-finance%20-%20SlowMist%20Audit%20Report.pdf

Report Date: July 2025

Description:

There are multiple instances of identical event emission issues in the Yeap Finance protocol, which can make it difficult for off-chain systems to distinguish the operation functions that trigger the events, potentially leading to errors in off-chain business systems.

Coding Mistake - Overview

Missing events, typos, or other error code mishaps.

Coding Mistake	Findings
Low	76
Total	76

Multiple modules define error codes with overlapping numeric values, leading to potential ambiguity. Error codes are typically defined sequentially, starting from 0 or 1.

This can lead to ambiguous error reporting and make debugging or on-chain analysis more difficult, as the origin of the error may be unclear.

Unnecessary Mutable Pool Parameter in get_position_amounts

Severity: Low

Ecosystem: Sui

Protocol: Full Sail CLMM

Auditor: Asymptotic

Report: https://info.asymptotic.tech/full-sail-clmm-audit

Report Date: May 2025

Description:

The get_position_amounts function declares a mutable reference to a Pool (&mut Pool<CoinTypeA, CoinTypeB>) but does not perform any modifications to this object during execution. It unnecessarily restricts concurrent access to the Pool object by other parts of the system.

Some errors are defined, but never used in the logic

Severity: Low

Ecosystem: Sui

Protocol: Momentum

Auditor: Sherlock

Report Date: Nov 2025

Description:

The error.move contains definitions of all errors used across the whole logic and modules of the solution. Few of them, however, are implemented, but never used in any of the flows described in the codebase. These are: • e_already_has_reward_data • e_invalid_max_bond_bonus

Missing Event in Airdrop

Severity: Low

Ecosystem: Sui

Protocol: Momentum

Auditor: MoveBit

Report Date: Nov 2025

Description:

In Airdrop, deposit_tokens and set_airdrop_end_time are missing event logs.

Missing Event in DeedNft

Severity: Low

Ecosystem: Sui

Protocol: Momentum

Auditor: MoveBit

Report Date: Nov 2025

Description:

In DeedNft, upgrade_version and set_version are missing events.

Lack of Events Emit

Severity: Low

Ecosystem: Sui

Protocol: Momentum CLMM

Auditor: MoveBit

Report Date: Nov 2025

Description:

Some functions in the contract lacks appropriate events for monitoring operations, which could make it difficult to track sensitive actions or detect potential issues.

Variable Naming Errors in Code

Severity: Low

Ecosystem: Sui

Protocol: Cetus DLMM

Auditor: MoveBit

Report: https://drive.google.com/drive/u/0/folders/1d9nv3nJidsbQ0vDT8D1kEuR3rJzK2ULg

Report Date: Sep 2025

Description:

frist_score_for_swap should be first_score_for_swap detal_liquidity should be delta_liquidity

Struct not shared

Severity: Low

Ecosystem: Sui

Protocol: Magma Finance

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Magma Finance - Zellic Audit Report.pdf

Report Date: Jan 2025

Description: The Voter and VotingEscrow objects are not properly shared after their creation. This prevents users from accessing these objects when attempting to create a lock and deposit to a gauge, as these operations require access to both the Voter and VotingEscrow objects.

Severity: Low

Ecosystem: Sui

Protocol: Navi

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Navi-Smart-Contract-Audit-Report.pdf

Report Date: July 2023

Description: There are unused constants in the contract. It is recommended to remove them.

Severity: Low

Ecosystem: Sui

Protocol: Cetus Concentrated Liquidity Protocol (Sui)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Sui-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: There is a private function remove_tick in the tick module that is not used.

Invalid Capability

Severity: Low

Ecosystem: Aptos

Protocol: Tortuga

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: June 2023

Description:

With the inclusion of the delegation_pool feature, several components require updates to facilitate its integration. However, validator_router::set_withdraw_signature and validator_router::verify_withdraw_signature_for_validator are missing the necessary modifications. When public validators sign up, they must provide their DelegationPoolOwnership capability by invoking delegation_pool::get_owned_pool_address. However, the current version incorrectly assumes aSharesDatacapability as proof of owning astake_pool, resulting in invalid validator sign-ups.

Unused Constant

Severity: Low

Ecosystem: Aptos

Protocol: Supra

Auditor: MoveBit

Report: https://movebit.xyz/reports/Supra-Smart-Contract-Audit-Report.pdf

Report Date: Sep 2023

Code Snippet: N/A

Description:

The constant EOWNER is not used in the contract.

Sensitive Operation Lacks Event

Severity: Low

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

In the contract, some sensitive operations lack event listeners, making it difficult for external tracking of changes in related data within the contract. The functions affected by this issue include offer_admin_previliges(), cancel_admin_previliges(), claim_admin_previliges(), and set_dex_liquidity_fee(), among others.

Unused Private Function

Severity: Low

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

The function assert_pair_is_not_created() defined in module router_v2 is not used, which leads to increased gas consumption and reduces the readability and understandability of the code.

The FeeChangeEvent Structure is Not Being Utilized

Severity: Low

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

The FeeChangeEvent structure is intended to monitor changes in various fees, but it's not being utilized within the contract. As a result, there's an inability to promptly track changes in fees.

Unused Constant

Severity: Low

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

The main consequence of the Unused Constants defect is the increase in gas costs during module deployment, leading to gas wastage.

Lack of Events Emit

Severity: Low

Ecosystem: Aptos

Protocol: MoveGPT

Auditor: MoveBit

Report: https://movebit.xyz/reports/MoveGPT-Final-Audit-Report.pdf

Report Date: Apr 2024

Description:

The smart contract lacks appropriate events for monitoring sensitive operations, which could make it difficult to track sensitive actions or detect potential issues.

Missing Events For Important Parameter Updates

Severity: Low

Ecosystem: Aptos

Protocol: StreamFlow

Auditor: MoveBit

Report: https://movebit.xyz/reports/StreamFlow2-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

We found that when important parameters are updated in the project, the function doesn't emit the update event, so we suggest emitting the emit event in time so as to notify the user or chain off programs.

Unused Event Should Be Removed

Severity: Low

Ecosystem: Aptos

Protocol: StreamFlow

Auditor: MoveBit

Report: https://movebit.xyz/reports/StreamFlow2-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

There are unused events that may be removed, such as EscrowInitEvent.

Underutilized Constant EID_INVALID in Pegging Module

Severity: Low

Ecosystem: Aptos

Protocol: Amnis

Auditor: MoveBit

Report: https://movebit.xyz/reports/Amnis-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

The constant EID_INVALID in the pegging module is not utilized, potentially impacting code readability and causing unnecessary gas consumption.

Lack of Events Emit

Severity: Low

Ecosystem: Aptos

Protocol: vibrantX

Auditor: MoveBit

Report: https://movebit.xyz/reports/vibrantX-Final-Audit-Report.pdf

Report Date: Jan 2024

Description:

The smart contract lacks appropriate events for monitoring sensitive operations, which could make it difficult to track sensitive actions or detect potential issues.

Inappropriate borrow

Severity: Low

Ecosystem: Aptos

Protocol: Mokshya/Wapal Aptos NFT Mint Smart Contract

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mokshya-Wapal-Aptos-NFT-Mint-Smart-Contract-Audit.pdf

Report Date: Mar 2023

Description:

In the function candymachine::mint_script , the resource CandyMachine is obtained through borrow_global_mut , but there is no need to modify CandyMachine in this function. Using borrow_global_mut may be risky, and the function candymachine::mi nt_from_merkle also has this problem. The same problem is similar to using table_with_le ngth::borrow_mut in the function candymachine::bucket_table::borrow .

The code specification is not uniform

Severity: Low

Ecosystem: Aptos

Protocol: Aries Market(Aptos)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Market-Contracts-Audit-Report.pdf

Report Date: Feb 2023

Description:

The calling methods of the two iterable_table::contains in the function remove_collateral_profile are inconsistent, one of which lacks the generic parameters, and the error code of assert should be defined as a constant EPROFILE_NO_BORROWED_RESERVE.

Assertion error code is incorrect

Severity: Low

Ecosystem: Aptos

Protocol: Aries Market(Aptos)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Market-Contracts-Audit-Report.pdf

Report Date: Feb 2023

Description:

There is an assertion in the function profile::new whether addr owns Profiles, but the returned error code is EPROFILE_ALREADY_EXIST, which should be EPROFILE_NOT_EXIST.

Wrong error code throw function

Severity: Low

Ecosystem: Aptos

Protocol: Mole

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mole-Aptos-Audit-Report.pdf

Report Date: Feb 2023

Description:

The code uses permission_denied to throw error codes. Different errors are thrown in different ways in the source code. Therefore, it is recommended to use invalid_argument for parameter errors.

TODO labels still remain in the code

Severity: Low

Ecosystem: Aptos

Protocol: Cetus Concentrated Liquidity Protocol(Aptos)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Aptos-Audit-Report.pdf

Report Date: Jan 2023

Description:

There are some TODO labels in clmm_math.move , all the left TODO labels are about tests. TODO often means work is not finished or possibility of defects. If we're not sure about the codes, we should write more tests to ensure the codes work correctly.

Missing ;

Severity: Low

Ecosystem: Aptos

Protocol: MoveDID

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/MoveDID-Aptos-Contracts-Audit-Report.pdf

Report Date: Nov 2022

Description:

The set_sign_and_updated_at function is missing a semicolon at the end of the function. This function does not have a return value, adding a semicolon would make it more readable.

Unused Function

Severity: Low

Ecosystem: Aptos

Protocol: MoveDID

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/MoveDID-Aptos-Contracts-Audit-Report.pdf

Report Date: Nov 2022

Description:

This function is not an entry function and has not been called. Add a comment if you plan to use this afterward, otherwise, delete it.

get_oracle_base_currency view function is acquiring a mutable reference to the Global Storage

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The get_oracle_base_currency function is declared as a view function and should not acquire a mutable reference to the global storage.

Missing Event Emit

Severity: Low

Ecosystem: Sui

Protocol: Volo

Auditor: Hacken

Report: https://hacken.io/audits/volo/sca-volo-liquid-staking-aug2023/

Report Date: Sep 2023

Description:

The functions are considered to perform valuable configuration changes, which users should be notified about.

Unused Variables/Structs

Severity: Low

Ecosystem: Sui

Protocol: Volo

Auditor: Hacken

Report: https://hacken.io/audits/volo/sca-volo-liquid-staking-aug2023/

Report Date: Sep 2023

Description:

Unused variables and structs should be removed from the contracts. Although unused variables and structs are allowed in Move and do not pose a direct security issue, it is best practice to avoid them as they can cause an increase in computations (and unnecessary Gas consumption) and decrease the code readability.

Lack of Account Registration Check for Coin

Severity: Low

Ecosystem: Aptos, Initia, and Movement

Protocol: Echelon Market

Auditor: Quantstamp

Report: https://certificate.quantstamp.com/full/echelon-market/9ee15c30-6a0f-4a70-b5ce-63b8a887bd4e/index.html

Report Date: Mar 2025

Description:

Different functions in the isolated_lending::isolated_lending module work with Move Coin. However, they miss proper registration for the coin before calling the coin::deposit function.

missing emiting EventOpenBinStepPreset when bin is removed via factory::remove_preset function

Severity: Low

Ecosystem: Aptos

Protocol: Magma DEX

Auditor: Three Sigma

Report: https://cdn.sanity.io/files/qoqld077/staging/9566473c444a6cfd99c7a6556fa4857950b41de3.pdf

Report Date: July 2025

Description:

When set bin status to either opened or closed we emit EventOpenBinStepPreset event for the bin information and its new status. The main function used to close bins is factory::close_bin_step_preset, which already emit this event when closing. There is another execution which will lead to closing of the bin where in case of removing the Present totally and the bin is opened we close it. but in that case we are not emiting EventOpenBinStepPreset event for that bined to be closed.

Collision - Overview

Collision vulnerabilities occur when different components accidentally share the same identifier or storage location (names, keys, types), causing unintended overwrites, state corruption, or unexpected behavior.

Collision	Findings
Medium	1
Low	4
Total	5

Medium Findings

Allocation ID Collision Enables Beneficiary Hijacking

Severity: Medium

Severity: Low

Ecosystem: Aptos, Initia, and Movement

Protocol: Echelon Market

Auditor: Quantstamp

Report: https://certificate.quantstamp.com/full/echelon-market/9ee15c30-6a0f-4a70-b5ce-63b8a887bd4e/index.html

Report Date: Mar 2025

Code: N/A

Description:

The two functions new_reward<RewardCoin> and new_reward_fa are used to register different tokens for reward payments. Under the hood, both of these functions call new_reward_for_farming_internal with the asset name. However, this can be problematic in the case of a name collision between an FA and a coin.

Possible Object Account Address Collision

Severity: Low

Ecosystem: Aptos, Initia, and Movement

Protocol: Echelon Market

Auditor: Quantstamp

Report: https://certificate.quantstamp.com/full/echelon-market/9ee15c30-6a0f-4a70-b5ce-63b8a887bd4e/index.html

Report Date: Mar 2025

Code: N/A

Description:

Different object accounts, such as JumpInterestRateModel, MarketLiquidationThreshold, MarketLiquidationIncentive, MarketLiquidationPauseFlag, CoinInfo, and FungibleAssetInfo, in various places are moved to global storage with the same market_signer object identifier. However, objects should be isolated to different accounts; otherwise, modifications to one object within an account can influence the entire collection.

Constant Definition - Overview

Hardcoded constants or misconfigured parameters leading to misbehavior or rigid protocol design.

Constant Definition	Findings
Critical	3
High	2
Medium	5
Low	11
Total	21

In is_whitelist_phase, the one_day constant is incorrectly set to 0 instead of 24*60*60*1000. This causes the calculation campaign.sale_start - one_day > clock::timestamp_ms(clock) to be incorrect, potentially allowing whitelist phase logic to fail.

Medium Findings

Fixed GUSD Pricing May Lead to Protocol Asset Loss

Severity: Medium

Ecosystem: Sui

Protocol: Creek Finance

Auditor: MoveBit

Report: https://movebit.xyz/reports/Creek-Audit-Report-2025-12-30.pdf

Report Date: Dec 2025

Description:

Pegging GUSD to a fixed price of $1 in the protocol could result in price misalignment.

Recommendation:

It is recommended to use the stablecoin’s actual market price for internal calculations to ensure that debt valuation aligns with real time market conditions.

nonce is Always 0

Severity: Medium

Ecosystem: Aptos

Protocol: MoveGPT

Auditor: MoveBit

Report: https://movebit.xyz/reports/MoveGPT-Final-Audit-Report.pdf

Report Date: Apr 2024

Description:

The nonce string value added to the signature in the buy function is always 0 and there is no place to change it. It is recommended not to use hard-coded.

Wrong value hardcoded in TOTAL_SUPPLY leads to too few minted tokens

Severity: Medium

Ecosystem: Sui

Protocol: Zesh AI

Auditor: Hacken

Report: https://hacken.io/audits/zesh-ai-layer/sca-zesh-ai-layer-zesh-coin-dec2024/

Report Date: Dec 2024

Description:

Harded coded token supply set to 1000 instead of 1 billion, as token uses 6 decimals. const TOTAL_SUPPLY: u64 = 1_000_000_000

Unused Constant

Severity: Medium

Ecosystem: Sui

Protocol: Scallop

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Scallop-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description:

Certain variables not referenced or used in any of the contract.

MIN_BASE_MAX_CLOSE_FACTOR_THRESHOLD has outdated value

Severity: Medium

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: June 2025

Description:

Incorrect constant.

Low Findings

Magic number in MAX_BOND_UNBOND_AT constant

Severity: Low

Ecosystem: Sui

Protocol: Momentum

Auditor: Sherlock

Report Date: Nov 2025

Description:

The MAX_BOND_UNBOND_AT is set to 0xffff_ffff_ffff_ffff (u64 max) but this magic number isn't documented. Future developers might not understand its significance.

Desynchronized or outdated state across contracts or storage variables breaking protocol invariants.

Data Inconsistency	Findings
Critical	2
High	10
Medium	10
Low	9
Total	31

Critical Findings

Token Identifier Collision

Severity: Critical

Ecosystem: OL Network

Protocol: StakeSphere

Auditor: MoveJay

Report: https://github.com/Jayfromthe13th/StakeSphere-stealth-/blob/Wallet/Audit.md

Report Date: Apr 2024

Description:

The get_pool_address function generates a unique address for a liquidity pool linked to trading pairs of fungible assets. This function creates and returns an address that uniquely identifies the liquidity pool for the specified pair of tokens. Users have the liberty to construct an Object using any symbol of their choice, which offers a great deal of flexibility. This flexibility, however, can lead to the creation of Object instances that closely resemble other existing instances. This situation might lead to a seed collision, which could subsequently cause a collision in the generation of the pool address.

Severity: High

Ecosystem: Sui

Protocol: Volo

Auditor: Hacken

Report: https://hacken.io/audits/volo/sca-volo-liquid-staking-aug2023/

Report Date: Sep 2023

Description:

The sort_validators function fails to consistently sort validators by priority. Extremely large priority values are placed at the beginning or middle of the array unpredictably, violating the intended descending order requirement.

Inconsistent Handling of reward_fee

Severity: High

Ecosystem: Sui

Protocol: Volo

Auditor: MoveBit

Report: https://movebit.xyz/reports/Volo-Smart-Contract-Audit-Report.pdf

Report Date: Oct 2023

Description:

In the update_rewards function, the total_rewards set by the set_rewards_unsafe function includes reward_fee, but in line 581 of the unstake_amount_from_validators function sub_rewards_unsafe(self, rewards - reward_fee) subtracts reward_fee.

Inconsistent Deduction Logic in remove_stakes Function

Severity: High

Ecosystem: Sui

Protocol: Volo

Auditor: MoveBit

Report: https://movebit.xyz/reports/Volo-Smart-Contract-Audit-Report.pdf

Report Date: Oct 2023

Description:

In the remove_stakes function, when the condition of L184 is not satisfied, the logic of L188-L191 will be executed. The value of requested_amount should be changed to requested_amount - principal_value. If the value of requested_amount is not updated, the actual amount withdrawn will be greater than requested_amount.

Severity: High

Ecosystem: Sui

Protocol: Random-Vault

Auditor: MoveBit

Report: https://movebit.xyz/reports/Random-Vault-Final-Audit-Report.pdf

Report Date: Feb 2024

Description:

When a user deposits multiple times, the contract updates round.total_share but fails to update the individual user’s share, leading to incorrect share accounting and potential loss of rewards.

token.start_p is not updated

Severity: High

Ecosystem: Sui

Protocol: Bucket

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Bucket-Protocol-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description: After invoking claim_collateral, the start_p value remains unchanged. This can cause subsequent logic errors and inconsistencies in state-dependent calculations.

ReserveData not Updated

Severity: High

Ecosystem: Sui

Protocol: Navi

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Navi-Smart-Contract-Audit-Report.pdf

Report Date: July 2023

Description: In the execute_withdraw function, small remaining amounts after withdrawal are sent to the treasury, but the user’s asset data and reserve balance in ReserveData are not updated. This leads to calculation errors and data desynchronization across the protocol.

Position Rewarder Checkpoint is not updated when changing liquidity

Severity: High

Ecosystem: Sui

Protocol: Magma DEX

Auditor: Three Sigma

Report: https://cdn.sanity.io/files/qoqld077/staging/9566473c444a6cfd99c7a6556fa4857950b41de3.pdf

Report Date: July 2025

Description:

When adjusting liquidity (inc/dec), only the global fee growth is checkpointed. However, reward growth from the reward manager is initialized only once at position creation via position_info_load_rewarder_growth_from_bin and never updated afterward, causing incomplete reward accounting.

LP unstaking only burns the shares but leaves the underlying tokens in the system, which distorts the shares-to-tokens ratio and leads to incorrect amounts being calculated during staking and unstaking

Severity: High

Ecosystem: Initia

Protocol: Cabal Liquid Staking

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-04-cabal-liquid-staking-token

Report Date: May 2025

Description:

When a user unstakes LP tokens, the corresponding shares (Cabal tokens) are burned. However, the actual undelegation from the validator will occur only after a delay of up to 3 days. During this period, the shares are already burned, but the underlying tokens are still included in shares-to-token conversions.

Medium Findings

Missing Reward Release Update When Breaking from Settlement Loop

Severity: Medium

Ecosystem: Sui

Protocol: Cetus DLMM

Auditor: MoveBit

Report: https://drive.google.com/drive/u/0/folders/1d9nv3nJidsbQ0vDT8D1kEuR3rJzK2ULg

Report Date: Sep 2025

Description:

In the settle_rewards function, when the condition if (current_time < next_settle_at) is met, the function breaks from the inner loop without updating reward.reward_released with the accumulated reward. This leads to potential reward loss and state inconsistency.

Incomplete Handling of Staked Liquidity in Fullsail Distribution

Severity: Medium

Ecosystem: Sui

Protocol: Full Sail CLMM

Auditor: Asymptotic

Report: https://info.asymptotic.tech/full-sail-clmm-audit

Report Date: May 2025

Description:

The pool maintains fullsail_distribution_staked_liquidity separately from total liquidity, creating a risk of desynchronization. Liquidity updates in the pool and staked liquidity changes are decoupled, allowing inconsistencies to arise between staking status and the underlying liquidity.

Inconsistent Balance Management in RewarderGlobalVault

Severity: Medium

Ecosystem: Sui

Protocol: Full Sail CLMM

Auditor: Asymptotic

Report: https://info.asymptotic.tech/full-sail-clmm-audit

Report Date: May 2025

Description:

The RewarderGlobalVault maintains two separate balance tracking mechanisms: coin balances in a bag and logical balances in an available_balance table. The function emergent_withdraw bypasses the available_balance accounting by directly withdrawing from the coin balance, which will lead to reward collection failures for users.

TakeRevenueEvent May Not Match The Actual Transferred Amount

Severity: Medium

Ecosystem: Sui

Protocol: Creek Finance

Auditor: MoveBit

Report: https://movebit.xyz/reports/Creek-Audit-Report-2025-12-30.pdf

Report Date: Dec 2025

Description:

In the take_revenue logic, there is an inconsistency between the emitted event amount and the actual amount of tokens transferred.

Attacker Can Desynchronize Supply Snapshot During Same-Block Unstake, Reducing Everyone’s Rewards

Severity: Medium

Ecosystem: Initia

Protocol: Cabal Liquid Staking

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-04-cabal-liquid-staking-token

Report Date: May 2025

Description:

An attacker holding Cabal LSTs (like sxINIT) can monitor the mempool for the manager’s voting_reward::snapshot() transaction. By submitting his own cabal::initiate_unstake transaction to execute in the same block (H) as the manager’s snapshot, the attacker can use two flaws: cabal_token::burn (called by their unstake) doesn’t update the supply snapshot for block H, leaving the recorded supply artificially high (pre-burn). cabal_token::check_snapshot skips recording the attacker’s own balance for block H. Later reward calculations use the stale high supply but retrieve the attacker’s now lower (post-burn) balance via fallback logic. This desynchronization causes the total calculated reward shares to be less than 100%, reducing the rewards paid out to all users for that cycle.

LP Redelegation Uses Inaccurate Internal Tracker Amount, Leading to Potential Failures or Orphaned Funds

Severity: Medium

Ecosystem: Initia

Protocol: Cabal Liquid Staking

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-04-cabal-liquid-staking-token

Report Date: May 2025

Description:

The redelegate_lp function, called during validator changes for LP pools, uses the internal pool.amount tracker to specify the amount for MsgBeginRedelegate. This tracker can diverge from the actual staked amount due to unreflected rewards or slashing, potentially causing redelegation failures or leaving funds staked with the old validator.

Desynchronization of Cabal’s internal accounting with actual staked INIT amounts leads to over-minting of sxINIT tokens

Severity: Medium

Ecosystem: Initia

Protocol: Cabal Liquid Staking

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-04-cabal-liquid-staking-token

Report Date: May 2025

Description:

The Cabal Protocol’s implementation of compound_xinit_pool_rewards fails to synchronize the protocol’s internal accounting (m_store.staked_amounts) with the actual amount of INIT tokens staked in the underlying Initia staking system. This creates a vulnerability where external events like slashing penalties or validator-initiated actions that reduce the staked amount are not reflected in Cabal’s internal state.

Loss of funds due to address mappings are not cleaned up after domain expiry

Severity: Medium

Ecosystem: Initia

Protocol: Initia Move

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-01-initia-move

Report Date: Apr 2025

Description:

The register_domain function doesn’t properly clean up old mappings (name_to_addr and addr_to_name) when a new user registers an expired domain. While it removes the old name_to_token mapping, it leaves the previous user’s address mappings.

Update magnified_dividends_per_share Values When staked_tokens Reaches Zero

Severity: Medium

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

When pool_info.staked_tokens reaches zero,the protocol fails to update pool_info.magnified_dividends_per_share_x and pool_info.magnified_dividends_per_share_y . This inconsistency results in a mismatch between the current state of pool_info and its initialized state.

Incorrect metadata used for deposit_stkapt function

Severity: Medium

Ecosystem: Aptos

Protocol: KoFi Finance

Auditor: MoveJay

Report: https://github.com/KofiFinance/audits/blob/main/Kofi%20Finance%20-%20Zenith%20Audit%20Report.pdf Report Date: Mar 2025

Description:

In the deposit_stkapt function, the code incorrectly uses kAPT_coin::metadata() instead of stkAPT_coin::metadata() when creating/accessing the fungible store for stkAPT tokens. This mismatch between token type and metadata will cause deposits to fail. The function is supposed to deposit stkAPT tokens but is using kAPT metadata to identify the store.

Low Findings

Position Display Object Inconsistencies

Severity: Low

Ecosystem: Sui

Protocol: Full Sail CLMM

Auditor: Asymptotic

Report: https://info.asymptotic.tech/full-sail-clmm-audit

Report Date: May 2025

Description:

The position module contains two separate functions (init and set_display) that independently create and transfer Display object without reusing shared logic. The inconsistent field naming ("website" vs "project_url") and hardcoded values between the two functions can lead to metadata inconsistencies and potential front-end display issues.

Stale Position Fee Rate Metadata

Severity: Low

Ecosystem: Sui

Protocol: Momentum CLMM

Auditor: Asymptotic

Report Date: Aug 2025

Description:

Position objects store a fee rate field capturing the pool’s fee rate at creation time. This field becomes stale and misleading when administrators update the pool’s swap fee rate, as position metadata is never updated.

Inconsistency In Fee Rate Enforcement

Severity: Low

Ecosystem: Sui

Protocol: Cetus DLMM

Auditor: CertiK

Report: https://drive.google.com/drive/u/0/folders/1d9nv3nJidsbQ0vDT8D1kEuR3rJzK2ULg

Report Date: Sep 2025

Description:

The function get_total_fee_rate enforces a cap only on the total_fee_rate , ensuring it does not exceed max_fee_rate , but returns the individual base_fee_rate and var_fee_rate values without applying any constraints. During swaps, fee calculations reference base_fee_rate() + step.bin_swap_var_fee_rate() as inputs for per-step fees, while actual bin swap operations are performed using the clamped total_fee_rate . This creates an inconsistency where displayed or derived component fee rates may differ from the effective, capped execution fee rate, especially if the sum of the base and variable rates exceeds the cap. This can result in confusion in fee reporting or analytics since the breakdown and the total fee applied may not align.

Event Log and State Inconsistency May Mislead Users

Severity: Low

Ecosystem: Sui

Protocol: Cetus DLMM

Auditor: MoveBit

Report: https://drive.google.com/drive/u/0/folders/1d9nv3nJidsbQ0vDT8D1kEuR3rJzK2ULg

Report Date: Sep 2025

Description:

In the add_reward function, two independent parameters are used to represent the reward amount: reward_coin: Coin amount: u64 However, the actual amount of tokens added to the pool’s reward manager comes from the reward_coin object, while the AddRewardEvent event records the reward amount based on the amount parameter. The code does not check whether these two values are equal. A malicious user could pass in a very small-value reward_coin while providing a very large amount parameter. This would cause the on-chain event to log a grossly inflated reward amount, while the pool itself only received a negligible reward.

Incorrect Data in Event

Severity: Low

Ecosystem: Sui

Protocol: Navi

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Navi-Smart-Contract-Audit-Report.pdf

Report Date: July 2023

Description:

In functions withdraw(), repay(), and liquidation_call(), the amount emitted in emit should represent the actual amount of funds withdrawn, repaid, or liquidated, rather than what the user inputs. Otherwise, it will send incorrect information to external event listeners.

Improper Implementation Of Mint Cap Check

Severity: Low

Ecosystem: Aptos

Protocol: Thala Labs

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Code Snippet: N/A

Description:

The number of MOD tokens to be minted in borrow is limited by the mint_cap parameter set by the protocol. This is enforced by checking if the newly minted amount along with the previous total debt exceeds the mint_cap. But in implementation, the amount considered in this check (amount) is different from the amount that is actually minted (total_amount = amount + fee_amount). This leads to the minting of MOD exceeding the amount set in the mint_cap parameter.

Inconsistent Results On Unmatched Decimals

Severity: Low

Ecosystem: Aptos

Protocol: Switchboard Aptos

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Nov 2022

Description:

SwitchboardDecimal can store a decimal value along with its decimals and sign. When a new decimal is initialized, it will be scaled to 9 decimals by default(MAX_DECIMALS), which is the maximum limit. All of the operations inside the math library assume that all the passed SwitchboardDecimal are scaled to MAX_DECIMALS. With the function, math::normalize scaling can be reversed; Thus, when an unscaled value is sent with a scaled value, the outcome is erroneous.

Users could lose not-yet accrued rewards when the distribution end is updated

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Periphery

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Periphery%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The current implementation of set_emission_per_second is not executing update_reward_data(...) to update the (asset, reward) distribution before updating the Global Storage value for reward_data.distribution_end. Assuming that the distribution has not ended yet, If the new new_distribution_end is <= reward_data.last_update_timestamp all the users will lose amount of rewards that could have accrued in the delta seconds timestamp::now_seconds() - reward_data.last_update_timestamp. This happens because calculate_asset_index_internal will early return the "old" distribution index when last_update_timestamp >= distribution_end.

Interest rates not updated before liquidation

Severity: Low

Ecosystem: Aptos

Protocol: Yeap Finance

Auditor: SlowMist

Report: https://github.com/slowmist/Knowledge-Base/blob/master/open-report-V2/smart-contract/aptos-smart-contract/yeap-finance%20-%20SlowMist%20Audit%20Report.pdf

Report Date: July 2025

Description:

In the liquidation module, users can liquidate insolvent users via the liquidate function. However, the protocol's global interest rate is not updated prior to liquidation. This could lead to interest not being accounted for when calculating user liabilities through preview_repay_shares , thereby impacting the accuracy of the liquidation operation.

Denial of Service (DoS) - Overview

Logic that can halt execution, lock funds, or make functions unusable.

DoS	Findings
Critical	1
High	4
Medium	27
Low	7
Total	39

Critical Findings

burn_from_bins_internal is subjected to DoS as we reset global liquidity when one bins liquidity goes to zero

Severity: Critical

Ecosystem: Sui

Protocol: Magma DEX

Auditor: Three Sigma

Report: https://cdn.sanity.io/files/qoqld077/staging/9566473c444a6cfd99c7a6556fa4857950b41de3.pdf

Report Date: July 2025

Description:

When burning liquidity we call burn_from_bins_internal. and we reset the global liquidity parameter to zero in case the reserve for the bins goes to zero or the supply of that bin goes to zero. Resetting liquidity at this case is not needed, it is actually incorrect, as this variable indicates the total liquidity in all bins. so falling one bin to zero does not mean the global liquidity goes to zero. And the problem is not just incorrect view function. In case this occur and another LP wanted to burn frmo his position from another bin, and the bin still has liquidity we will go to the else block which will do self.liquidity - liquidity_delta so it will endup in underflow error, reverting the tx and preventing the burning. Even the first check enforces the liquidity difference to be too small. so most of further burning process will end up at else block results in underflow and reverting the tx.

Unbounded Execution - DOS

Severity: Critical

Ecosystem: Binance Smart Chain

Protocol: AquaSwap

Auditor: MoveJay

Report: https://github.com/Jayfromthe13th/AuquaSwap-Audit-/blob/Wallet/Audit%20report.md

Report Date: July 2025

Description:

These functions can lead to unbounded execution because they iterate over potentially large lists. An attacker could exploit this by registering a large number of orders, causing the functions to block and leading to denial-of-service (DOS).

High Findings

DXLP Ratio Manipulation and Denial of Service

Severity: High

Ecosystem: Supra

Protocol: Dexlyn Perp DEX

Auditor: Hacken

Report: https://hacken.io/audits/dexlyn/sca-dexlyn-perp-dex-jul2025/

Report Date: Sep 2025

Description:

The Dexlyn perpetual trading protocol contains a significant vulnerability in its House LP (DXLP) token system that allows attackers to manipulate the token ratio and extract value from legitimate users' deposits. This vulnerability combines ratio manipulation with a denial of service attack.

The vulnerability stems from two interconnected design flaws:

No Minimum Deposit Protection: The house_lp::deposit function allows deposits as small as 1 wei, enabling attackers to become the first depositor with minimal investment.
Unprotected Vault Inflation: The pnl_deposit_to_lp function deposits trading losses into the HouseLPVault without minting corresponding DXLP tokens, allowing vault inflation without supply increase.

Potential DoS Due to Improper Balance Splitting in the Liquidation

Severity: High

Ecosystem: Sui

Protocol: Creek Finance

Auditor: MoveBit

Report: https://movebit.xyz/reports/Creek-Audit-Report-2025-12-30.pdf

Report Date: Dec 2025

Description:

If the debt_to_burn exceeds the value of repay_balance (for example, when revenue_balance has a non-zero value), the balance::split operation will fail and cause a transaction panic. This renders the liquidation mechanism unusable under many normal conditions and may freeze funds involved in the liquidation.

NFT Token ID contains forbidden character by design which prevents any domain from being issued at all

Severity: High

Ecosystem: Initia

Protocol: Initia Move

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-01-initia-move

Report Date: Apr 2025

Description:

The usernames module allows for registering a domain. This happens in function register_domain. On registration, a NFT is minted to the buyer, with field Token ID in format domain:timestamp. However the : character is forbidden by underlying nft.move module which is also the reason why original unit tests fail. Due to this, the protocol cannot be used in its current state, because no NFTs can be currently minted, thus, no domains can be claimed. Hence, this is equivalent to a permanent DoS.

Excessive rewards allocations leads to DoS

Severity: High

Severity: Medium

Ecosystem: Aptos

Protocol: Echelon

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2025

Description:

The vulnerability relates to the creation of a primary fungible asset store in new_reward_fa in the lending core (shown below) and isolated core farming modules. new_reward_fa tries to create a primary store for the asset at the package address utilizing create_primary_store , which does not check if a store already exists at the address before creating a new one.

Thus, primary_fungible_store::create_primary_store aborts if a primary store already exists at the address. As anyone may create a primary store at any address since it is permissionless, it enables an attacker to create a primary store for an asset at the package address. This action will block any subsequent attempts to add that address as a farming reward in both lending_core and isolated_lending farms.

Risk of Self-Dos

Severity: Medium

Ecosystem: Sui

Protocol: Volo

Auditor: MoveBit

Report: https://movebit.xyz/reports/Volo-Smart-Contract-Audit-Report.pdf

Report Date: Sep 2023

Description:

In line 199 of the remove_stakes function, it is necessary to deal with the situation that staked_sui_mut_ref - requested_amount is less than 1 Sui , otherwise it will cause self-dos.

Option params in CLI

Severity: Medium

Ecosystem: Sui

Protocol: Legend of Arcadia

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Legend-of-Arcadia-Smart-Contract-Audit-Report.pdf

Report Date: Jun 2023

Description:

burn_request and update_metadata_request have Option type parameters. If these parameters cannot be passed in CLI, users cannot call functions, causing DOS on these functions.

DoS on Failed Transfer Operations on the Same Object

Severity: Medium

Ecosystem: Sui

Protocol: MSafe Maven

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Maven-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

Multiple transfer requests cause DoS as first transfer succeeds, other requests fail when execute_object_operation is called.

DoS from Privileged User where Permission has Single Signer Settings

Severity: Medium

Ecosystem: Sui

Protocol: MSafe Maven

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Maven-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

If proposer and approver are in same roles, the role only has one signer with the authority to vote on the propsal. This will cause execution queue to be blocked resulting in a DoS.

claim Function May Cause DOS Problems

Severity: Medium

Ecosystem: Aptos

Protocol: MoveGPT

Auditor: MoveBit

Report: https://movebit.xyz/reports/MoveGPT-Final-Audit-Report.pdf

Report Date: Apr 2024

Description:

In the claim function, when lock_amount is equal to round_config.balances, it will extract all the coins in round_config.balances , but by calculating the lock_amount may be less than round_config.balances, then the function will always fail when reaching the else branch to extract the lock_amount from balances.

Reentrancy Check in lock_staking::reentry_check Causes Concurrent INIT Deposit Failures (DOS)

Severity: Medium

Ecosystem: Initia

Protocol: Cabal Liquid Staking

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-04-cabal-liquid-staking-token

Report Date: May 2025

Description:

The liquid staking protocol’s deposit_init_for_xinit function, which allows users to deposit INIT tokens to receive xINIT, is vulnerable to transaction failures when multiple users deposit concurrently in the same block. The function withdraws INIT tokens and delegates them to a validator via pool_router::add_stake, which triggers lock_staking::delegate. This, in turn, invokes reentry_check to prevent multiple delegations in the same block.

If a second user attempts to deposit in the same block as another, their transaction fails with error code 196618 (EREENTER), as reentry_check detects that the StakingAccount was already modified in the current block. This vulnerability disrupts users’ ability to participate in the protocol, particularly during periods of high transaction activity.

Severity: Medium

Ecosystem: Initia

Protocol: Cabal Liquid Staking

Auditor: Code4Arena Contest Security Researchers

Report: https://code4rena.com/reports/2025-04-cabal-liquid-staking-token

Report Date: May 2025

Description:

Users can stake both INIT and LP tokens into different validator pools by calling functions like deposit_init_for_xinit or stake_asset. To exit, users initiate an unstake via initiate_unstake, which starts an unbonding period. After this delay, they can claim their tokens through claim_unbonded_assets.

Behind the scenes, these staked assets are delegated to validators, and slashing may occur—meaning a portion of the delegated tokens could be penalized (burned). To stay accurate, the protocol uses pool_router::get_real_total_stakes to track the current delegated amount. However, the current unstaking flow doesn’t properly account for slashing events that may occur during the unbonding period.

DoS due Unbounded Rewards Map

Severity: Medium

Ecosystem: Aptos

Protocol: Econia

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Dec 2022

Description:

AVL queue evicts orders when the tree exceeds a CRITICAL_HEIGHT or, when the number of active nodes becomes equal to N_NODES_MAX, to prevent excessive gas costs for insertion and deletion. In theory, due to the limited orderbook capacity, an attacker can place enough orders to evict legitimate orders and then cancel these placed orders.

Pyth Deployment DOS

Severity: Low

Ecosystem: Aptos

Protocol: Pyth

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2022

Description:

Similar to the issue we found in Wormhole, during initialization of the pyth module, it attempts to register an AptosCoin account in order to be able to receive fees:

However, coin::register is a one-time operation. If coin::register has previously been called on this address, this initialization code will abort and the wormhole program will be unable to initialize. While it is usually not possible to register coins for users you can not sign for, the Aptos framework provides a special mechanism to register AptosCoin for any user via aptos_account::create_account:

Therefore, with this mechanism an attacker could register AptosCoin for the wormhole program before deployment in order to prevent it from properly initializing.

Wormhole Deployment DOS

Severity: Low

Ecosystem: Aptos

Protocol: Wormhole Aptos

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2022

Description:

During initialization of the wormhole module, it attempts to register an AptosCoin account in order to be able to receive fees:

Therefore, with this mechanism an attacker could register AptosCoin for the wormhole program before deployment in order to prevent it from properly initializing.

Potential Denial of Service Risk of DAP Module

Severity: Low

Ecosystem: Aptos

Protocol: Yeap Finance

Auditor: SlowMist

Report: https://github.com/slowmist/Knowledge-Base/blob/master/open-report-V2/smart-contract/aptos-smart-contract/yeap-finance%20-%20SlowMist%20Audit%20Report.pdf

Report Date: July 2025

Description:

In yeap_oracle, the DAP module is primarily responsible for asset price routing, constructing a directed acyclic graph (DAG) to manage price conversion paths between different assets. However, operations within functions such as add_edge, get_common_ancestor, and get_paths all require traversing the entire path to detect cycles. This traversal has a time complexity of O(n). If the created paths become excessively long, it could lead to a Denial-ofService (DoS) risk.

Documentation Mismatch - Overview

Code that does not follow comments or documentation.

Documentation Mismatch	Findings
Low	3
Total	3

During the security audit, a discrepancy was identified between the reward equation depicted in the staking diagram and the implementation in the apply_reward_formula function. To maintain a robust and consistent system, it is imperative that the specifications outlined in the whitepaper documentation precisely match the code. We recommend updating the staking diagram to accurately reflect the calculation performed by the code.

Front Running - Overview

Attackers exploit transaction ordering or mempool visibility to gain unfair advantage.

Front-running	Findings
High	3
Medium	2
Low	2
Total	7

address and seed are trivial. Attacker can front-run book::create_orderbook by creating account at right address, causing a revert.

Medium Findings

Duplicate-order DoS via front-running deterministic order_id

Severity: Medium

Ecosystem: Sui

Protocol: Garden Move

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Garden%20Move%20Deploy%20-%20Zellic%20Audit%20Report.pdf

Report Date: May 2025

Description:

order_id is publicly visible — initiate_on_behalf lets anyone set order_id without verifying initiator ownership, allowing attackers to replay the transaction (e.g., with amount = 1) to trigger a DuplicateOrder error for the legitimate request.

Front-Running Pair/Market Creation

Severity: Medium

Ecosystem: Aptos

Protocol: Echelon

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2025

Description:

create_pair_with_jump_model in isolated_lending is responsible for creating a new lending pair with a jump interest rate model. However, it is vulnerable to front-running. An attacker may observe a pending pair creation and preemptively register their Aptos account to the to-be-created pair’s address before the pair is fully initialized. Similarly, in lending_core , create_market_with_jump_model_v2 , the market creation may be front-run with a call to register the Aptos account at the address of the market that it is going to be created, resulting in a denial-of-service scenario.

Low Findings

Front-Running Vulnerability in Liquidity Management

Severity: Low

Ecosystem: Sui

Protocol: Full Sail CLMM

Auditor: Asymptotic

Report: https://info.asymptotic.tech/full-sail-clmm-audit

Report Date: May 2025

Description:

The remove_liquidity function in the pool module lacks slippage protection mechanisms, making users vulnerable to front-running attacks that can result in substantial financial losses. Unlike add_liquidity which provides a two-step process allowing users to review amounts before committing, remove_liquidity executes immediately without any user-controlled protection parameters.

Attack Strategy: • Find large positions (>5% of pool liquidity) • Manipulate price to push victim's position out of range • Victim removes large liquidity, reducing pool depth • Exploit reduced liquidity for cheaper price restoration • Profit from asymmetric price impact before/after liquidity removal

The seed for minting does not update

Severity: Low

Ecosystem: Sui

Protocol: MystenLabs Sui

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description: This field should update after every mint with a new value.

Inefficient or unbounded gas use that increases costs or causes function failure.

Gas-related Issues	Findings
Medium	11
Total	11

When confirming a Momentum Safe registration, the address is removed from the pending vector of the owner’s OwnerMomentumSafes using a linear search. As anyone can register Momentum Safes for the owner, this causes the pending vector to grow. Note that an attacker can register a Momentum Safe in O(1) time, but all future operations will cost O(n) for the victim. This asymptotic difference makes it a viable gas-griefing attack vector.

Low

Inflation Attacks - Overview

Manipulating token supply or pricing mechanisms to artificially inflate token value or circulation, leading to economic imbalance or devaluation.

Inflation Attacks	Findings
Medium	1
Low	4
Total	5

Inconsistency in Maintaining One-to-One Peg

Severity: Low

Ecosystem: Aptos

Protocol: Thala LSD

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2025

Description:

The 1:1 peg between thAPT and staked APT may break due to the unrestricted burning burn_from_thapt, and while reconcile may mint thAPT to restore the peg, it also enables arbitrary supply manipulation.

Payouts round down

Severity: Low

Ecosystem: Aptos

Protocol: Tortuga Liquid Staking

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Tortuga Liquid Staking - Zellic Audit Report.pdf

Report Date: Oct 2022

Description:

It is possible to perform an economically impractical, griefing-style attack that abuses the rounding down behavior of mul_div in disperse_all_payouts to ensure only those with a relatively high number of shares can receive a payout:

If the reserve_balance is low enough, delegators with few shares would receive zero payout while delegators with many shares would receive some. Dust is refunded to the reserve at the end of disperse_all_payouts, meaning repeated, quick calls to disperse_all_payouts would result in only high-value delegators getting payouts. Impact Malicious, high-value delegators (i.e., those with many shares) could cause lowervalue delegators to not receive any payouts.

Input Validation - Overview

Missing or weak checks on user input leading to invalid or malicious state changes.

Input Validation	Findings
Critical	16
High	29
Medium	34
Low	91
Total	170

Critical Findings

Fake Openings Lead to Malicious Withdrawal of Pool Fees and Funds

Severity: Critical

Ecosystem: Sui

Protocol: Cetus DLMM

Auditor: MoveBit

Report: https://drive.google.com/drive/u/0/folders/1d9nv3nJidsbQ0vDT8D1kEuR3rJzK2ULg

Report Date: Sep 2025

Description:

If the user opens a position with very large values (only by passing parameters, without actually adding liquidity), the bin’s fee growth global will be inflated. The first user can then exploit the difference between the position’s fee growth entry and the inflated global value to drain funds from the pool.

Incorrect message signature verification parameters

Severity: Critical

Ecosystem: Supra Chain

Protocol: Dexlyn Hyperlane

Auditor: Hacken

Report: https://hacken.io/audits/dexlyn/sca-dexlyn-hyperlane-monorepo-dec2024/

Report Date: Dec 2024

Description:

The code implementation uses an incorrect parameter combination in the signature verification process. The verify function in move/isms/sources/multisig_ism.move is using msg_utils::nonce(message) instead of the proper merkle_index when generating the signed digest bytes, which would cause signature validation to fail.

Additionally, the merkle_index was being extracted incorrectly as raw bytes rather than being properly converted to a u32 value.

Tolerance Check Bypass on Forced Withdrawal

Severity: Critical

Ecosystem: Sui

Protocol: Aftermath Market Making

Auditor: OtterSec

Report: https://www.notion.so/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Jan 2025

Description: A malicious user may intentionally set min_expected_balance_out to an unrealistically high value that the vault cannot satisfy, effectively locking the withdrawal session. The user can then trigger a forced withdrawal, bypassing default constraints on withdrawal processing and resulting in vault losses. This feature also triggers market orders on all positions.

Absence of Generics Checking

Severity: Critical

Ecosystem: Binance Smart Chain

Protocol: AquaSwap

Auditor: MoveJay

Report: https://github.com/Jayfromthe13th/AuquaSwap-Audit-/blob/Wallet/Audit%20report.md

Report Date: July 2024

Description: The revoke_trade<BaseTokenType> function does not assert that the inputted generic type matches the base_type TypeInfo stored on the Trade resource. An attacker could drain liquidity from the AMM by placing a limit trade order, canceling it, and passing an incorrect token type.

Signature Length Validation

Severity: Critical

Ecosystem: Sui

Protocol: Bluefin

Auditor: OtterSec

Report: https://www.notion.so/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2024

Description: Extra bytes in signature_bytes can alter the computed hash, leading to incorrect digest values and potentially causing incorrect validation if rewards have been previously claimed.

Missing UID Validation

Severity: Critical

Ecosystem: Sui

Protocol: Bluefin

Auditor: OtterSec

Report: https://www.notion.so/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2024

Description: Missing validation of UIDs allows attackers to use invalid or forged BankV2 objects, potentially minting shares at lower price, resulting in a loss of funds.

Loss of Coin

Severity: Critical

Ecosystem: Sui

Protocol: Cetus

Auditor: OtterSec

Report: https://www.notion.so/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2024

Description: The limit_order::repay_flash_loan function lacks a check to verify that the order_id in the receipt matches the ID of the limit order. An attacker can manipulate the order_id, resulting in loss of coins.

Loss Of Funds In Lending

Severity: Critical

Ecosystem: Sui

Protocol: Navi

Auditor: OtterSec

Report: https://www.notion.so/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: June 2023

Description: All functions in lending.move lack validation on the Coin Type, allowing attackers to use incorrect coin types and causing loss of funds through incorrect asset calculations.

Bid with Zero Input Causing DOS

Severity: Critical

Ecosystem: Sui

Protocol: MoviePass Exchange

Auditor: Cetora

Report: https://github.com/Certora/SecurityReports/blob/main/Reports/2025/03_02_2025_MoviePass_MSX-MR.pdf

Report Date: Feb 2025

Description: A bid with a 0-value input can cause the entire dispersal phase to fail if the split(0) operation reverts. A single 0-value bid entering the disperse function can cause a denial-of-service by failing all subsequent withdrawals.

Missing Asset-Type Validation in repay_add_liquidity Allows Wrong Token Repayment

Severity: Critical

Ecosystem: Sui

Protocol: Dexlyn

Auditor: HackenProof

Report: https://hackenproof.com/audit-programs/dexlyn-smart-contract-audit-contest?tab=reports

Report Date: Sep 2025

Description: The repay_add_liquidity function accepts repayment with arbitrary fungible assets without verifying they are the pool's configured tokens. This allows attackers to provide wrong tokens and still satisfy liquidity repayment, corrupting pool reserves.

repay_flash_swap accepts arbitrary token types, enabling theft of pool assets

Severity: Critical

Ecosystem: Sui

Protocol: Dexlyn

Auditor: HackenProof

Report: https://hackenproof.com/audit-programs/dexlyn-smart-contract-audit-contest?tab=reports

Report Date: Sep 2025

Description: The repay_flash_swap function lacks token type validation, allowing the pool to accept repayment with arbitrary token types and enabling theft of real assets from the pool.

Unchecked reward asset during reward claim allows withdrawing the wrong token from pool reserves

Severity: Critical

Ecosystem: Sui

Protocol: Dexlyn

Auditor: HackenProof

Report: https://hackenproof.com/audit-programs/dexlyn-smart-contract-audit-contest?tab=reports

Report Date: Sep 2025

Description: The reward-claim function trusts a user-supplied asset_addr when transferring owed rewards instead of enforcing the configured rewarder asset for the given rewarder_index. An LP with accrued rewards can claim in asset A or B (or any fungible asset the pool holds), draining pool reserves by up to the owed amount per claim.

Lack of Validation for target_amount and tokens_to_sell in create_campaign

Severity: Critical

Ecosystem: Sui

Protocol: SuiPad

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/SuiPad-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: Missing validation for target_amount and tokens_to_sell can lead to 0 values due to precision issues, causing failure to claim tokens or locking assets indefinitely.

Function can't be called

Severity: Critical

Ecosystem: Sui

Protocol: SuiPad

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/SuiPad-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description: The claim_refund function cannot be called because the parameter Vault<TI, TR> cannot be passed, preventing users from retrieving their tokens.

Severity: High

Ecosystem: Sui

Protocol: SatLayer Sui

Auditor: Asymptotic

Report: https://info.asymptotic.tech/satlayer-audit

Report Date: Mar 2025

Description: The initialize_vault function accepts a TreasuryCap<K> parameter for minting receipt tokens when users deposit tokens of type T into the vault. However, there is no validation to ensure that this treasury cap hasn't been previously used to mint tokens.

`DeleteAccount` does not but should check if `account_id` is used in some policy

Severity: High

Ecosystem: Sui

Protocol: Aeon

Auditor: Asymptotic

Report: https://info.asymptotic.tech/aeon-audit-report#262c1aef2c7042b7816a0015ed4a0051

Report Date: Feb 2025

Description: This may lead to policies which are more permissive than intended. For example, we could have a sequence of rules:

For all vaults in an account, check some condition
If the above fails, automatically approve

Now a deleted account could still have the above executed despite the account being deleted.

Duplicate Feed IDs in Data Packages Allow a Single Signer to Override Others

Severity: High

Ecosystem: Sui

Protocol: RedStone

Auditor: Hacken

Report: https://hacken.io/audits/redstone/sca-redstone-finance-sui-connector-feb2025/

Report Date: Feb 2025

Description:

The process_payload function does not enforce the uniqueness of feed_id values within a single data package. This allows a single signer to submit multiple values for the same feed ID, which can influence the oracle value. Since calculate_median aggregates values without verifying uniqueness per signer, an attacker who obtains valid signatures ahead of time can modify the oracle value.

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.

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: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Navi-Smart-Contract-Audit-Report.pdf

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: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/SuiPad-Smart-Contract-Audit-Report.pdf

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: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/SuiPad-Smart-Contract-Audit-Report.pdf

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: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/SuiPad-Smart-Contract-Audit-Report.pdf

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: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Smart-Contract-Audit-Report.pdf

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: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Smart-Contract-Audit-Report.pdf

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.

Severity: High

Ecosystem: Aptos

Protocol: Baptswap

Auditor: MoveBit

Report: https://movebit.xyz/reports/BAPTSWAP-Final-Audit-Report.pdf

Report Date: Dec 2023

Description:

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.

Severity: Medium

Ecosystem: Sui

Protocol: Full Sail CLMM

Auditor: Asymptotic

Report: https://info.asymptotic.tech/full-sail-clmm-audit

Report Date: May 2025

Description:

The add_fee_tier function in config module does not validate the tick_spacing parameter, allowing callers to set arbitrarily large values.

A very large tick_spacing significantly reduces tick density across the price range. In concentrated liquidity models like CLMM, this results in extremely coarse or even absent liquidity across wide price intervals, leading to inefficient pricing and degraded trading performance.

Missing Referral and Fee Rate Validation

Severity: Medium

Ecosystem: Sui

Protocol: ZO Perps(Sudo)

Auditor: Asymptotic

Report: https://info.asymptotic.tech/sudo-audit-report

Report Date: Mar 2025

Description:

The admin functions set_referral_rate and set_fee_config lack proper input validation for fee rates. While fee_rate has a 100% limit (which seems too high), referral rates are completely unlimited. This allows setting arbitrary referral rate percentages without bounds (e.g., above 100%), which may cause transactions to revert during position operations.

Additionally, setting referral rates higher than fee rates could negatively impact users who utilize the referral system.

Missing Input Validation for Position Orders

Severity: Medium

Ecosystem: Sui

Protocol: ZO Perps(Sudo)

Auditor: Asymptotic

Report: https://info.asymptotic.tech/sudo-audit-report

Report Date: Mar 2025

Description:

The open_position and decrease_position functions lack essential input validation when creating orders. For example, users can create open orders with zero collateral or zero open_amount, while position decrease orders have no validation for decrease amounts or leverage limits. These missing validations allow the creation of meaningless orders that waste system resources and may lead to unexpected behavior during execution.

Maximum Position Collateral Validation Inconsistency

Severity: Medium

Ecosystem: Supra

Protocol: Dexlyn Perp DEX

Auditor: Hacken

Report: https://hacken.io/audits/dexlyn/sca-dexlyn-perp-dex-jul2025/

Report Date: Sep 2025

Description:

A significant validation inconsistency exists between the order placement and execution phases regarding maximum_position_collateral enforcement. While validation correctly checks total projected collateral against the limit, execution only validates the post-fee collateral delta, allowing positions to exceed configured maximums when governance parameters change between order placement and execution.

Mismatched Array Lengths in Admin Messages Can Lead to State Corruption or Denial of Service

Severity: Medium

Ecosystem: IOTA Mainnet

Protocol: Echo Protocol Bridge

Auditor: Hacken

Report: https://hacken.io/audits/echo-protocol/sca-echo-protocol-bridge-iota-jul2025/

Report Date: Aug 2025

Description:

The system relies on privileged, off-chain administrators to configure its core parameters, such as which tokens are supported and what routes are active. This is accomplished via signed messages created by the create_add_tokens_on_iota_message and create_add_routes_on_iota_message functions in the bridge::message module. These functions accept several parallel vectors of data (e.g., token_ids, token_type_names, token_prices) which are then encoded into a message payload. This message is subsequently processed on-chain by the execute_add_tokens_on_iota and execute_add_routes_on_iota functions, which decode the payload and update the bridge's state.

The message creation functions (create_add...) fail to validate that the parallel vectors provided as input have identical lengths. A malicious or mistaken administrator can therefore craft a syntactically valid message with mismatched array lengths (e.g., providing 3 token IDs but only 2 prices). When the bridge attempts to process this malformed message, the transaction will abort due to an out-of-bounds error, leading to a Denial-of-Service (DoS) that prevents any administrative updates. This could trap the bridge in a misconfigured or paused state indefinitely.

Artificially Low Asset Price Leads to Rate-Limiter Bypass

Severity: Medium

Ecosystem: IOTA Mainnet

Protocol: Echo Protocol Bridge

Auditor: Hacken

Report: https://hacken.io/audits/echo-protocol/sca-echo-protocol-bridge-iota-jul2025/

Report Date: Aug 2025

Description:

The notional_value<T>() is fetched directly from the treasury module. The issue is that the function for setting this price, update_asset_notional_price, does not validate its input. It is called by execute_update_asset_price in bridge.move, which is in turn only callable via a committee-signed execute_system_message. If the committee sets an artificially low price for a high-value asset, the hourly transfer limits for that asset become ineffective.

Manipulated Initial Data Package Can Skew Timestamp Validation

Severity: Medium

Ecosystem: Sui

Protocol: RedStone

Auditor: Hacken

Report: https://hacken.io/audits/redstone/sca-redstone-finance-sui-connector-feb2025/

Report Date: Feb 2025

Description: The process_payload function extracts the timestamp from the first package in parsed_payload after filtering packages by their feed ID and extracts these packages. However, the package_timestamp function uses the first package's timestamp for other packages in the payload. This creates a risk because an attacker can insert a fake initial package with an incorrect timestamp, bypassing proper validation.

Insufficient Validation of Price Source Independence

Severity: Medium

Ecosystem: Sui

Protocol: Creek Finance

Auditor: MoveBit

Report: https://movebit.xyz/reports/Creek-Audit-Report-2025-12-30.pdf

Report Date: Dec 2025

Description:

In the determine_price function , the code calculates the required number of secondary matches using:

let required_secondary_match_num = (secondary_price_feed_num + 1) / 2;

However, there is no check to ensure that required_secondary_match_num > 0 . Additionally, in the upper-level function confirm_price_update_request , there is no validation to ensure that the primary_price_update_request and secondary_price_update_request originate from distinct sources.

Lack of Validation for Price Value in get_price function

Severity: Medium

Ecosystem: Sui

Protocol: Scallop

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Scallop-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description:

Missing 0 check can lead to incorrect calculations and impact other functions.

Parameter Check for Creating Dutch

Severity: Medium

Ecosystem: Sui

Protocol: Typus Finance

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Typus-Finance-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

Parameters like decay_speed should not be zero, and time-related values must be logically consistent (e.g., start_ms < end_time_ms and end_time_ms should be greater than the current time).

Can Create Pools With Same Type

Severity: Medium

Ecosystem: Sui

Protocol: MovEx

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/MovEx-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

create_pool function doesn't check if pool type was already created which will lead to duplicate pools. Depth of each pool is not large enough and will cause slippage.

Create Pools with same Coin Type

Severity: Medium

Ecosystem: Sui

Protocol: MovEx

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/MovEx-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

You can create a pool with two of the same token.

Severity: Medium

Ecosystem: Sui

Protocol: Sui AMM swap

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Sui-AMM-swap-Contracts-Audit-Report.pdf

Report Date: Nov 2022

Description:

The functions multi_add_liquidity, multi_remove_liquidity, and multi_swap first use the pop_back function for coins_in and lp_coin in the code to pop up the last element of the vector, but this does not judge that the length of the vector is 0.

Lack of Input Validation

Severity: Medium

Ecosystem: Sui

Protocol: Aries Market

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Smart-Contract-Audit-Report.pdf

Report Date: Jun 2023

Description:

reserve_ratio is not checked to ensure it is not greater than 100 when updating reserve_config.

The addition of reserve is missing validation

Severity: Medium

Ecosystem: Sui

Protocol: Aries Market

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Smart-Contract-Audit-Report.pdf

Report Date: Jun 2023

Description:

add_reserve lacks input validation — should include an assertion to prevent adding the same coin to the reserve. The client acknowledged this but deemed it a non-issue.

Validation is Required Before Deleting reserve_addr

Severity: Medium

Ecosystem: Sui

Protocol: Aries Market

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Smart-Contract-Audit-Report.pdf

Report Date: Jun 2023

Description:

Check if reserve_addr exists, then proceed with delete.

ID occupied causes program termination

Severity: Medium

Ecosystem: Sui

Protocol: Mango

Auditor: ExVul

Report: https://github.com/ExVul-Sec/AuditReport/blob/main/Smartcontract/Mango%20Smart%20Contract%20Audit%20Report-Exvul.pdf

Report Date: July 2025

Description:

The new_bridge_pair funciton in config.move does not strictly enforce the relationship between the provided id and the internal pair_id counter.

strategy_type missing check

Severity: Medium

Ecosystem: Aptos

Protocol: Mole

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mole-Aptos-Audit-Report.pdf

Report Date: Feb 2023

Description:

add_collateral and work functions both use strategy_type parameter to execute different logic. However, add_collateral lacks a check of strategy_type.

current_time not checked

Severity: Medium

Ecosystem: Aptos

Protocol: Cetus Concentrated Liquidity Protocol

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Aptos-Audit-Report.pdf

Report Date: Jan 2023

Description:

In get_ref_fee_rate, current_time does not check it is the current time.

Missing tick in range check

Severity: Medium

Ecosystem: Aptos

Protocol: Cetus Concentrated Liquidity Protocol

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Aptos-Audit-Report.pdf

Report Date: Jan 2023

Description:

get_sqrt_price_at_tick function does not check if tick is in range, some ticks out of range pass.

Create pool with two same CoinTypes

Severity: Medium

Ecosystem: Aptos

Protocol: Cetus Concentrated Liquidity Protocol

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Aptos-Audit-Report.pdf

Report Date: Jan 2023

Description:

A pool can be created between CoinA and CoinA, which is redundant.

Missing Check for Sequence Number

Severity: Medium

Ecosystem: Sui

Protocol: Walrus Contracts

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2025

Description:

While there is validation for the blob ID, there is no validation for the ending checkpoint sequence number. As a result, the value provided by a quorum-reaching node gets recorded in the state. If an incorrect number is entered, it causes a mismatch between the event blob being processed by the node and the on-chain tracking.

Exceeding Object Size Limit

Severity: Medium

Ecosystem: Sui

Protocol: Walrus Contracts

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2025

Description:

In staking_pool, if the StorageNodeInfo.{name,network_address} field is set to an excessively long value by the node owner, it may contribute significantly to the total size of the StakingPool object. This may restrict the addition of new values to pending_shares_withdraw, thereby blocking stakers from making withdrawals.

Missing Commission Rate Check

Severity: Medium

Ecosystem: Sui

Protocol: Walrus Contracts

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2025

Description:

There is no check to ensure that the commission rate is less than or equal to 10000, an ENotEnough error may occur in staking_pool::advance_epoch when the node becomes part of the committee.

Duplicate Entries

Severity: Medium

Ecosystem: Sui

Protocol: Drife Technologies

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Dec 2023

Description:

register_rider and register_driver allows the creation of multiple rider or driver objects with the same address, resulting in duplicate entries. Both register_rider and register_driver create a new rider or driver objects without checking whether an object with the same address already exists, resulting in multiple objects with the same address.

Signature Forgery

Severity: Medium

Ecosystem: Sui

Protocol: Drife Technologies

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Dec 2023

Description:

In the context of the drife_app::request_ride, the signature includes a parameter city: String after the address to allow the user to set the city name. However, this string may become any value, even to the operation name. Attacker can forge signature by manipulating this field.

Missing TransactionPayload Type Validation

Severity: Medium

Ecosystem: Aptos

Protocol: MSafe

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2022

Description:

The TransactionPayload struct contains the payload and its type. Aptos supports payloads of type: • WriteSet • Scripts • ModuleBundle • EntryFunction

The payload in theTransactionPayloadstruct can be any transaction type, not justEntryFunction. This assumption should be validated. For example, many internal functions such as register payload validation assume the layout of the TransactionPayload is a EntryFunction.

Missing Chain ID Validation

Severity: Medium

Ecosystem: Aptos

Protocol: MSafe

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2022

Description:

Transactions can be replayed from one chain to another if this field isn’t properly validated. In the context of a multisig, the transaction can be added but will fail at execution. Nonetheless, this represents a potential UX risk and is worth remediating. Validate chain_id in the validate_txn_payload function.

Lack Of Check For Forbidden IDs

Severity: Medium

Ecosystem: Sui

Protocol: Maven

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2023

Description:

Update admin policy could be set to forbidden ID, ensure check beforehand.

Users may set a TTL value that does not follow the maximum TTL limit

Severity: Medium

Severity: Low

Ecosystem: Sui

Protocol: Magna Airlock

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Magna Airlock - Zellic Audit Report.pdf

Report Date: Nov 2025

Description:

The deserialize_allocation() function performs BCS deserialization of allocation data without validating the integrity of the deserialized values. This creates multiple denial-of-service vectors that will manifest at withdrawal time rather than at merkle root creation time.

Missing validations:

Calendar schedule: No check that unlock_timestamps and unlock_amounts arrays have equal length
Interval schedule: No check that period_length > 0 or number_of_periods > 0
Amount consistency: No check that allocation.amount matches sum of unlock amounts or piece amounts
Array bounds: No maximum size limits on timestamps/amounts/pieces vectors

Missing Validation For Token Decimals

Severity: Low

Ecosystem: IOTA Mainnet

Protocol: Pools Finance

Auditor: Hacken

Report: https://hacken.io/audits/pools-finance/sca-pools-finance-pools-contracts-may2025/

Report Date: June 2025

Description:

The register_pool function in the stake.move module allows users to register a new staking pool by providing the stake and reward tokens along with their corresponding decimal values. These decimal values are used to compute a scale factor for accurately calculating accumulated rewards.

Lack of Zero-Value Validation in update_route_limit() Allows Setting Invalid Rate Limits

Severity: Low

Ecosystem: IOTA Mainnet

Protocol: Echo Protocol Bridge

Auditor: Hacken

Report: https://hacken.io/audits/echo-protocol/sca-echo-protocol-bridge-iota-jul2025/

Report Date: Aug 2025

Description:

The bridge module enables bridging assets from an EVM to IOTA. To prevent abuse, it enforces a per-route hourly transfer rate limit. If a transfer exceeds this limit, it is rejected, and a TokenTransferLimitExceed event is emitted.

Smokescreen/log flooding on `deposit`

Severity: Low

Ecosystem: Sui

Protocol: Bluefin RFQ

Auditor: Asymptotic

Report: https://bluefin.io/blog/doc/bluefin_rfq_audit.pdf

Report Date: Feb 2025

Description:

There is no privilege check and no minimum amount for depositing, so an attacker could induce a very large number of Deposit events cheaply.

`set_manager` should also have a zero-address check

Severity: Low

Ecosystem: Sui

Protocol: Bluefin RFQ

Auditor: Asymptotic

Report: https://bluefin.io/blog/doc/bluefin_rfq_audit.pdf

Report Date: Feb 2025

Description:

create_rfq_vault check that the manager is not set to the zero address: assert!(manager != @0, EZeroAddress);

set_manager should also have this check.

Missing Withdrawal Time Validation

Severity: Low

Ecosystem: Sui

Protocol: SatLayer Sui

Auditor: Asymptotic

Report: https://info.asymptotic.tech/satlayer-audit

Report Date: Mar 2025

Description:

The withdrawal_time parameter, which defines the cooldown period between a withdrawal request and the actual withdrawal execution, lacks proper validation in both initialize_vault and update_withdrawal_time functions. Without appropriate bounds checking, the cooldown period could potentially be set to an unreasonably high value, effectively preventing users from accessing their funds for extended periods. Additionally, setting a zero cooldown period would make the two withdrawal functions call redundant, so consider to forbid zero cooldown as well.

Insufficient Fee Validation in Position Orders

Severity: Low

Ecosystem: Sui

Protocol: ZO Perps(Sudo)

Auditor: Asymptotic

Report: https://info.asymptotic.tech/sudo-audit-report

Report Date: Mar 2025

Description:

The open_position and decrease_position functions accept fee coins as payment for order execution. While this fee is intended to incentivize executors to process orders, there are no validation checks to ensure the fee is sufficient or even non-zero. This creates a risk where orders with inadequate fees may remain permanently unexecuted in the orders list, as executors would have no economic incentive to process them if the fee is below their operational costs.

Missing Zero Value Check in decrease_reserved_from_position

Severity: Low

Ecosystem: Sui

Protocol: ZO Perps(Sudo)

Auditor: Asymptotic

Report: https://info.asymptotic.tech/sudo-audit-report

Report Date: Mar 2025

Description:

The decrease_reserved_from_position function does not validate that the decrease_amount parameter is non-zero.

Missing Position Validation in Pool Module Functions

Severity: Low

Ecosystem: Sui

Protocol: Full Sail CLMM

Auditor: Asymptotic

Report: https://info.asymptotic.tech/full-sail-clmm-audit

Report Date: May 2025

Description:

The protocol implements the validate_pool_position function specifically to ensure a position belongs to the pool it's interacting with, but this validation is applied for add_liquidity_* functions only.

Version Validation in update_package_version

Severity: Low

Ecosystem: Sui

Protocol: Full Sail CLMM

Auditor: Asymptotic

Report: https://info.asymptotic.tech/full-sail-clmm-audit

Report Date: May 2025

Description:

The update_package_version function in the config module allows setting any value, including older or identical versions. This can lead to unintended downgrades or redundant updates, potentially causing compatibility or versioning issues.

Additionally, the lack of a public getter for package_version makes it difficult to verify the current version for external callers or before performing updates.

Missing Parameter Checks

Severity: Low

Ecosystem: Sui

Protocol: Momentum

Auditor: MoveBit

Report Date: Nov 2025

Description:

During operations such as merge and extend in user_v1.move, it is advisable to add checks for the validity of user-input parameters. This prevents users from unnecessarily consuming gas due to incorrect parameters. extend() No validation that new_unbond_at is greater than old_unbond_at . merge() No validation that only one VeToken is staked between primary and merged.

Missing Input Validations in Swap Simulation Functions

Severity: Low

Ecosystem: Sui

Protocol: Momentum CLMM

Auditor: Asymptotic

Report Date: Aug 2025

Description:

The compute swap result and get optimal swap amount for single sided liquidity functions do not check that pool::sqrt price(pool) != 0 or that sqrt price limit is within valid min/max and current price bounds. As a result, these functions may abort unexpectedly or return incorrect results if called with invalid inputs. Additionally, get optimal swap amount for single sided liquidity does not verify that the provided position actually belongs to the specified pool.

Missing Input Validation and Code Duplication in Liquidity Math

Severity: Low

Ecosystem: Sui

Protocol: Momentum CLMM

Auditor: Asymptotic

Report Date: Aug 2025

Description:

The liquidity math module functions get liquidity for amounts and get amounts for liquidity do not validate that sqrt price lower ¡ sqrt price upper, which can result in incorrect calculations. Additionally, liquidity math::get amount x for liquidity and liquidity math::get amount y for liquidity contain identical logic to sqrt price math::get amount x delta and sqrt price math::get amount y delta respectively. The liquidity math versions are never called in the codebase.

Severity: Low

Ecosystem: Sui

Protocol: Maven

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2023

Description:

In utils.move, vector_slice should return the subslice of the vector, starting at the start index and ending at the end index. However, there is no check to ensure that end is higher than start; in this case, the function returns an empty vector.

Incorrect checks result in the absence of verification of the invariant

Severity: Low

Ecosystem: Sui

Protocol: MystenLabs Sui

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description: In voting_power.move, check_invariants checks the enforcement of invariants after setting the voting power. However, the first if statement compares stake_i with itself instead of stake_j, not checking the invariant.

Insufficient checks for the order of genes

Severity: Low

Ecosystem: Sui

Protocol: MystenLabs Sui

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description: definitions_from_bcs should ensure the correct order of genes. Otherwise, if definitions are set in an incorrect order, receiving parts of the value becomes impossible.

Erroneous checks allow the user to create an invalid discount code

Severity: Low

Ecosystem: Sui

Protocol: MystenLabs Sui

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description:

In remove_later::deserialize_discount_code, the current validation for the discount code rate during deserialization is incorrect, as it only checks if the rate is greater than zero or less than three characters. The intended validation should verify that the rate is greater than zero and less than three characters.

Lack of validation in setting and retrieving default domain names

Severity: Low

Ecosystem: Sui

Protocol: MystenLabs Sui

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description:

In registry.move, set_default_domain_name sets the value of the new default_domain_name, however, several checks are missing.

The function does not check if new_default_domain_name exists or if the sender is its owner.
The function only permits modifying the default domain name setting for subdomains of addr.reverse, leaving the field empty for all other domains.
The default domain name still points to the same domain if the owner changes.
The default domain name should not be accessible through any other public functions. However, registry::get_name_record_all_fields returns the default domain name without validation.

Prevent Zero Unstaking

Severity: Low

Ecosystem: Sui

Protocol: Aftermath LSD

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2023

Description:

When a user requests to unstake in order to exchange AFSUI for SUI, a PendingUnstakeRecord is stored in StakedSuiVaultStateV1::pending_unstake_records. During epoch_was_changed, process_pending_unstake_requests calculates the SUI amount from the AFSUI amount in the record based on the exchange rate. Due to the access to the dynamic field, field_request_counter increases, which raises the reward to be sent to the caller from the crank incentive pool. Therefore, allowing unstake for a zero amount causes the protocol to consume the crank incentive reward pool without generating any fees. This enables a malicious user to extend the crank process and exhaust the crank incentive pool.

Rebalance Security Checks

Severity: Low

Ecosystem: Sui

Protocol: Volo

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2023

Description:

native_pool::rebalance does not include calls to the assert_version and when_not_paused functions.

Inconsistencies In Object Creation

Severity: Low

Ecosystem: Sui

Protocol: Drife Technologies

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Dec 2023

Description:

add_stop creates a Stop object with the duration parameter and appends it to the ride.stops vector. However, it lacks cross-checking against existing stops, specifically concerning values like stop_started or stop_ended. Without proper validation, there is a risk that these values might conflict with other stops, resulting in unintended consequences during fare calculation or ride management.

Inadvertent Locking Of Tokens In Incorrect Chain

Severity: Low

Ecosystem: Sui

Protocol: Sui Bridge

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2024

Description: target_chain could be one that doesn’t accept tokens, which can then be locked.

Payload Size Limitation

Severity: Low

Ecosystem: Sui

Protocol: Sui Bridge

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2024

Description: Payloads under 64 bytes cause an invalid target address msg, causing unclaimable tokens on Ethereum chain.

Severity: Low

Ecosystem: Aptos

Protocol: Supra

Auditor: MoveBit

Report: https://movebit.xyz/reports/Supra-Smart-Contract-Audit-Report.pdf

Report Date: Sep 2023

Code Snippet: N/A

Description:

It is essential to ensure that the lengths of all Vector-type parameters are consistent within the process_cluster function; otherwise, it may result in an abort. However, there is a lack of assertions for validating the lengths of Vector-type parameters.

Unexpected Pool Status (Property 6 Not Hold)

Severity: Low

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 6 requires: Each step in the update_bin should correctly update the value of the bin and return the correct coin value/type. After minting, the pool.coin_x or pool.coin_y should rise. During the specification, we found the state of the pool.coin_x and pool.coin_y had been reassigned after the loop in the mint_bin function, and this reassign of the pool led to the violation of this property. These functions include: mint_bin, update_bin The reassigned pool shows the situation that, none of the coin_x and coin_y are increase after the mint.

Zero Fee Deposit for Small Amounts

Severity: Low

Ecosystem: Aptos

Protocol: Merkle Trade Smart Contract

Auditor: MoveBit

Report: https://movebit.xyz/reports/Merkle-Trade-Smart-Contract-Audit-Report.pdf

Report Date: July 2023

Description:

In the deposit() function, there is a possibility for users to deposit a very small amount that results in a fee of zero. This allows users to bypass paying any deposit fees. The function calculates the deposit fee based on the house_lp.deposit_fee percentage and the original amount deposited. If the amount is extremely small, the calculated fee may round down to zero. Consequently, the _amount variable will remain unchanged, and the user can deposit the entire amount without incurring any fee. This issue allows users to make deposits without paying the intended deposit fee, potentially leading to a loss of revenue for the system. The same issue for withdraw() function.

Check Sufficient lp Collectral

Severity: Low

Ecosystem: Aptos

Protocol: Merkle Trade Smart Contract

Auditor: MoveBit

Report: https://movebit.xyz/reports/Merkle-Trade-Smart-Contract-Audit-Report.pdf

Report Date: July 2023

Description:

It's a good practice to check that HouseLPVault has enough collateral to withdraw, otherwise, it will go deep down to the aptos_std::coin::extract to check the balance.

Deserialization Should Explicitly Check Data Length

Severity: Low

Ecosystem: Aptos

Protocol: Superposition

Auditor: MoveBit

Report: https://movebit.xyz/reports/Superposition-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

In the deserialization methods: read_u8, read_u16, read_u32, read_u64, read_u128, and read_u256... , they do not check the length of bytes before consuming the data. If the input's length is not enough, it will cause the function to panic.

Fee Rates Should Be Hard Capped Under 100%

Severity: Low

Ecosystem: Aptos

Protocol: Superposition

Auditor: MoveBit

Report: https://movebit.xyz/reports/Superposition-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

In tenant.move , set_liquidation_fee_rate , set_interest_rate_fee_rate , set_stability_fee_rate can set arbitrary fee rates without limitation. If any of the fee rate is over 100%, then it'd become the total loss of the funds.

Lack check of parameter

Severity: Low

Ecosystem: Aptos

Protocol: PatronusFi

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/PatronusFi-Contract-Audit-Report.pdf

Report Date: Mar 2023

Description:

There is no limit to the amount greater than 0, and there is no judgment that the balance of wcoin is greater than the parameter amount passed in.

Vault may already exist

Severity: Low

Ecosystem: Aptos

Protocol: PatronusFi

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/PatronusFi-Contract-Audit-Report.pdf

Report Date: Mar 2023

Description:

When creating a vault, create_vault does not judge whether the vault under the bank address exists, or judges whether the token has been registered in wcoin::create.

There is no assert in the function to verify whether the amount is greater than 0

Severity: Low

Ecosystem: Aptos

Protocol: Aries Market(Aptos)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Market-Contracts-Audit-Report.pdf

Report Date: Feb 2023

Description:

It is not verified whether the amount is 0 before recharging. According to the code logic, it will be verified when the function profile::repay_profile is executed, which undoubtedly consumes excess Gas.

Lack of the check for coin amount

Severity: Low

Ecosystem: Aptos

Protocol: Mole

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mole-Aptos-Audit-Report.pdf

Report Date: Feb 2023

Description:

According to the parameters of the deposit function, the result of the share mint to the user in the calculation may be 0. When minting tokens, tokens with a value of 0 should not be minted.

TinyCoin has no check value upper limit

Severity: Low

Ecosystem: Aptos

Protocol: Mole

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mole-Aptos-Audit-Report.pdf

Report Date: Feb 2023

Description:

After the swap, there may be a situation where the value of TinyCoin is relatively large, which is not tiny enough, so causing some losses to users.

Tokens might not be registered

Severity: Low

Ecosystem: Aptos

Protocol: Mole

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mole-Aptos-Audit-Report.pdf

Report Date: Feb 2023

Description:

In the kill function of the liquidswap_worker module, there is no check in advance on whether to register the BaseCoin token.

Invalid end_time argument of partner::create_partner may cause partner::get_ref_fee_rate to return incorrect fee rate

Severity: Low

Ecosystem: Aptos

Protocol: Cetus Concentrated Liquidity Protocol(Aptos)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Aptos-Audit-Report.pdf

Report Date: Jan 2023

Description:

partner::create_partner doesn't check whether the argument end_time is greater than now. It is used to initialize the PartnerMetadata.end_time .If the PartnerMetadata.end_time is less than now, and not updated by partner::update_time later, the partner would always get a zero fee rate returned by partner::get_ref_fee_rate , and thus the partner would never receive any partner fee.

Unchecked deposit amount

Severity: Low

Ecosystem: Aptos

Protocol: Echelon

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Echelon - Zellic Audit Report (January).pdf

Report Date: Jan 2025

Description:

The receive_deposit_batch function calls parse_deposit_payload to parse deposit payloads. While received_asset_amount represents the total sum of all depositor amounts, the parse_deposit_payload function lacks validation to ensure this sum matches the actual total deposit amount received.

Missing validation checks in set_params

Severity: Low

Ecosystem: Aptos

Protocol: Aptos Dollar

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Thala Labs Move Dollar - Zellic Audit Report.pdf

Report Date: Oct 2022

Description:

Currently there are no validation checks in params::set_params to ensure that the following critical protocol parameters are not set to values that break the protocol.

Missing assertion checks for oracle initialization

Severity: Low

Ecosystem: Aptos

Protocol: Aptos Dollar

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Thala Labs Move Dollar - Zellic Audit Report.pdf

Report Date: Oct 2022

Description:

There are no checks in place to enforce that oracle::set_price has been called for a given CoinType prior to calling vault::initialize.

batch_set_asset_feed_ids should revert when assets and feed_ids lengths are not the same

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The batch_set_asset_feed_ids is not checking if the length of the two input vectors assets and feed_ids matches. If feed_ids is bigger compared to assets, the function will not revert but will not configure all the feed_ids to an asset.

AToken/vToken factories functions work with tokens of the opposite type

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The token_base function is used as the shared module between aTokens and vTokens. To get a token's balance one can call the public functions on either the a_token_factory or variable_debt_token_factory modules. However, not all functions check if the token address parameter is indeed a token of the factory's type, for example: • A user can call variable_debt_token_factory::scaled_balance_of(owner, metadata_address=a_token) with an a_token address and receive the aToken balance, and vice versa for aToken factory and vToken parameters. This should not be valid and in the worst case, this can lead to exploits in integrators that don't perform further checks on the metadata_address (like interpreting a vToken address as an aToken collateral balance in a a_token_factory::scaled_balance(owner, metadata_address=vToken)).

coin_to_fa should revert if the user has not enough CoinType balance to perform the conversion

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Periphery

Auditor: Spearbit

Report:

https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit Aave Aptos Periphery V3.0.2 Report.pdf

Report Date: Jun 2025

Description:

The current sanity check performed by aave_pool::coin_migrator::coin_to_fa on the user balance is not correctly implementing the requirement to revert when the caller has not enough CoinType balance to perform the conversion of amount coins. The function fetches the user's balance by calling coin::balance(signer::address_of(account)) which does not strictly return the amount of CoinType owned by the user that could be converted to the FungibleAsset version, but it rather returns the total amount of both CoinType + FungibleAsset (of the CoinType) amount.

Lack of lower and Upper bound in set_emission_per_second

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Periphery

Auditor: Spearbit

Report:

https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit Aave Aptos Periphery V3.0.2 Report.pdf

Report Date: Jun 2025

Description:

The set_emission_per_second function in the RewardsController module allows setting new emission rates for rewards without validating upper or lower bounds. This could lead to two potential issues:

Setting extremely high emission rates could cause excessive rewards distribution and potential numerical overflow when calculating rewards.
Setting extremely low (but non-zero) emission rates could lead to rewards that effectively round to zero, wasting gas on calculations that produce no meaningful rewards.

Missing Zero Amount Checks

Severity: Low

Ecosystem: Aptos

Protocol: Hyperionxyz Vaults

Auditor: ExVul

Report: https://github.com/ExVul-Sec/AuditReport/blob/main/Smartcontract/Hyperion Smart Contrat Audit Report-Exvul.pdf

Report Date: Apr 2025

Description:

Functions like remove_as_pair and remove_as_single assert token_amount != 0, but deposits (deposit_with_pair, deposit_with_single) don't explicitly check for zero amount_a_desired/amount_b_desired or amount_in. While downstream calls might handle this, explicit checks can prevent wasted gas or unexpected behavior.

Missing Zero Liquidity Check

Severity: Low

Ecosystem: Aptos

Protocol: Hyperionxyz Vaults

Auditor: ExVul

Report: https://github.com/ExVul-Sec/AuditReport/blob/main/Smartcontract/Hyperion Smart Contrat Audit Report-Exvul.pdf

Report Date: Apr 2025

Description:

In the close_position function, the logic directly calls pool_v3::remove_liquidity using the liquidity_amount retrieved from position_v3::get_liquidity. However, there is no check to ensure that liquidity_amount is non-zero. If the value is 0, calling remove_liquidity with zero liquidity may lead to unexpected behavior, wasted gas, or even reverts inside the remove_liquidity logic, depending on the pool implementation.

Should check if the amount_in is bigger than 0

Severity: Low

Ecosystem: Aptos

Protocol: Hyperionxyz Vaults

Auditor: ExVul

Report: https://github.com/ExVul-Sec/AuditReport/blob/main/Smartcontract/Hyperion Smart Contrat Audit Report-Exvul.pdf

Report Date: Apr 2025

Description:

In the swap_liquidity_token_to_another function, there is no explicit check to ensure that amount_in is greater than zero before performing a withdrawal and initiating a swap.

Nonce expiration isn’t verified before removal

Severity: Low

Ecosystem: Sui

Protocol: Claynosaurz

Auditor: Certora

Report: https://github.com/Certora/SecurityReports/blob/main/Reports/2025/04_18_2025_Claynosaurz_NFT.pdf

Report Date: Apr 2025

Code Snippet: N/A

Description:

registry::update_nonce_expiration_window() allows the admin to remove old nonces from the registry. However, the function doesn’t verify that the nonces have expired already and relies on the admin to check that. It might be best to double-check that programmatically and not only rely on the admin.

Bytes isn’t verified to be fully consumed by claim_boosterpack()

Severity: Low

Ecosystem: Sui

Protocol: Claynosaurz

Auditor: Certora

Report: https://github.com/Certora/SecurityReports/blob/main/Reports/2025/04_18_2025_Claynosaurz_NFT.pdf

Report Date: Apr 2025

Description:

claim_boosterpack() decodes a bytes parameter which contains encoded data about the booster pack. However, it doesn’t verify the bytes were fully consumed by decoding (i.e. the bytes vec is empty after ‘peeling’ all the data). Meaning, the function might accept data that’s longer than expected and contains excess bytes at its end. This kind of data wasn’t signed to be used for claiming boosterpack and should be rejected by the function.

Missing role bounds check in has_role

Severity: Low

Ecosystem: Sui

Protocol: Elixir

Auditor: Pashov Audit Group

Report: https://github.com/pashov/audits/blob/master/team/pdf/Elixir-security-review_2025-08-17.pdf

Report Date: Aug 2025

Code: N/A

Description:

The has_role function in sources/acl.move lacks role bounds validation, unlike other role functions. This inconsistency could cause runtime aborts if invalid role values (≥128) are passed. The issue may arise in future integrations where external contracts pass usercontrolled role parameters or during cross-contract calls with unvalidated inputs. Impact -> Runtime trxs abort instead of graceful error handling, leading to inconsistent API behavior.

The deposit function lacks asset support check

Severity: Low

Ecosystem: Sui

Protocol: Elixir

Auditor: Pashov Audit Group

Report: https://github.com/pashov/audits/blob/master/team/pdf/Elixir-security-review_2025-08-17.pdf

Report Date: Aug 2025

Description:

The deposit function allows anyone to send coins to management, mainly intended for the router to inject the tokens required for withdrawals after rebalancing.

Missing Input Validation

Severity: Low

Ecosystem: Aptos, Initia, and Movement

Protocol: Echelon Market

Auditor: Quantstamp

Report: https://certificate.quantstamp.com/full/echelon-market/9ee15c30-6a0f-4a70-b5ce-63b8a887bd4e/index.html

Report Date: Mar 2025

Description:

The following functions lack proper input validation:

isolated_lending::isolated_lending:
1. set_pair_collateral_dust_amount(): collateral_dust_amount is unbound and may have any value between zero and MAX_U64.
2. set_pair_supply_cap(): supply_cap neither has a lower nor an upper bound, allowing arbitrary caps, which may leave the pair temporarily in an inoperable state.
3. set_pair_borrow_cap(): borrow_cap neither has a lower nor an upper bound, allowing arbitrary caps, which may leave the pair temporarily in an inoperable state.
4. set_pair_jump_interest_rate_model(): All parameters are unbound and unchecked, with the exception of utilization_kink_bps, which however may assume any values between zero and BPS_BASE.
5. create_pair_internal():
  1. liquidation_incentive_bps not checked to be greater than or equal to BASE_BPS and smaller or equal to MAX_LIQUIDATION_INCENTIVE_BPS.
  2. collateral_dust_amount not checked to be within a reasonable bound.
  3. base_rate_bps not checked to be within BASE_BPS.
  4. multiplier_bps not checked to be within BASE_BPS.
  5. jump_multiplier_bps not checked to be within BASE_BPS.
lending::lending:
1. set_market_jump_interest_rate_model():
  1. base_rate_bps, multiplier_bps and jump_multiplier_bps are not checked to be smaller than BPS_BASE or otherwise reasonably bound.
  2. It is not checked that jump_multiplier_bps < multiplier_bps, leading to no jump in rates after the kink point.
  3. It is not checked that utilization_kink_bps is a reasonable value. Especially, it is not checked that utilization_kink_bps !== 0. If utilization_kink_bps === 0, it would cause borrow_interest_rate to divide by zero. This division by zero risk is particularly concerning as it would cause transaction failures for all operations that depend on interest rate calculations, including borrowing, supplying, and liquidations, potentially rendering markets unusable.
2. set_market_rate_limit_internal(): window_max_qty not checked to be non-zero or otherwise reasonably bound.
3. deposit_reserve_fa(): Missing call to validate_fa_info().

`MAX_LIQUIDATION_INCENTIVE_BPS` Can Be Bypassed when Creating New Pairs

Severity: Low

Ecosystem: Aptos, Initia, and Movement

Protocol: Echelon Market

Auditor: Quantstamp

Report: https://certificate.quantstamp.com/full/echelon-market/9ee15c30-6a0f-4a70-b5ce-63b8a887bd4e/index.html

Report Date: Mar 2025

Description:

When changing the liquidity incentive via set_pair_liquidation_incentive_bps(), it is constrained to be within 100% and MAX_LIQUIDATION_INCENTIVE_BPS (150%). However, when creating new pairs via create_pair_internal() no such checks exist, allowing potentially higher or lower values, given sufficiently low collateral factor values to pass the coverage checks.

Missing Input Validation

Severity: Low

Ecosystem: Sui

Protocol: BalancerV2

Auditor: Quantstamp

Report: https://certificate.quantstamp.com/full/bucket-protocol-v-2/abd312d6-1a5e-45c5-963b-a6856daf6621/index.html

Report Date: Aug 2025

Description:

human error may lead to erroneous inputs that drive unexpected protocol behavior. As such, input validation is important to include in the code to prevent incorrect inputs from influencing the protocol.

Many of the inputs are integers, some of which are formatted as basis points (bps). In most cases, basis points should not exceed 10000 (i.e. 100%). However, inputs above this number are possible.

Unbounded values can be set in config

Severity: Low

Ecosystem: Aptos

Protocol: KoFi Finance

Auditor: Zenith

Report: https://github.com/KofiFinance/audits/blob/main/Kofi Finance - Zenith Audit Report.pdf

Report Date: Mar 2025

Description:

The set_min_withdrawal_amount_admin function allows setting the minimum withdrawal amount without any upper bound validation. This could lead to a denial of service if the admin accidentally sets an extremely high minimum withdrawal amount, effectively preventing users from making withdrawals.

Looping Issues - Overview

Unbounded loops or iteration over dynamic arrays leading to high gas costs or DoS.

Looping Issues	Findings
Critical	1
High	3
Medium	3
Low	4
Total	11

High Findings

Early Return in Signer Threshold Verification May Confirm Malicious Payloads

Severity: High

Ecosystem: Sui

Protocol: RedStone

Auditor: Hacken

Report: https://hacken.io/audits/redstone/sca-redstone-finance-sui-connector-feb2025/

Report Date: Feb 2025

Description: The verify_signer_count function is responsible for ensuring that the number of valid signers meets a predefined threshold before confirming a price update or other critical operation. However, the function contains an early return (return) within the loop, which terminates the verification process as soon as the threshold is met. This can introduce significant security risks, particularly in malicious payload injection scenarios.

Infinite Loop in handle_redeem

Severity: High

Ecosystem: Sui

Protocol: Bucket Protocol

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Bucket-Protocol-Smart-Contract-Audit-Report.pdf

Report Date: July 2023

Description:

In the handle_redeem function, if the debt value is 0, the loop controlling the redemption process may not terminate as expected, leading to a potential infinite loop. This can cause transaction failures or denial-of-service conditions within the protocol.

Infinite Recursion in distribute_dex_fees() Leading to Transaction Failure

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() aims to calculate and distribute DEX fees based on the type of input X. In this function, the protocol calls swap_exact_x_to_y_direct() to exchange X for APT and then transfers the obtained APT to the treasury. However, within the swap_exact_x_to_y_direct() function, the protocol again invokes distribute_dex_fees(). This recursive calling pattern leads to an infinite loop, resulting in an out-of-gas situation and a failed transaction.

Medium Findings

Presence Of Infinite Loop

Severity: Medium

Ecosystem: Sui

Protocol: Drife Technologies

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Dec 2023

Description:

If ride is less than three stops, continues to next iteration, but it does not increase causing infinite loop.

Multiple indexes can map to the same reserve

Severity: Medium

Ecosystem: Aptos

Protocol: AAVE

Auditor: Certora

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Certora%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Apr 2025

Description:

The function init_reserve() does not break when finding a valid index to use.

When adding a new reserve, the function first looks for an unused index in the current range (and increases the range of indexes if none were found). If an unused index was found, we map this index to the new reserve. However, we do not break from the loop, but continue looking for more unused indexes. If we find multiple such indexes, we will have multiple indexes mapping to the same reserve. (For multiple indices to be unused within the current range, drop_reserve() will have to be called twice between uses of init_reserve().)

This will then lead to counting the reserve multiple times when calling calculate_user_account_data(), which can lead to counting the same coin as collateral twice and taking debt against it, resulting in a loan worth more than its collateral.

For this to work, drop_reserve() will have to be called twice between uses of init_reserve().

Inefficient Assignment Within Loop in the process_cluster Function

Severity: Medium

Missing Functions	Findings
Critical	1
High	3
Medium	15
Low	18
Total	37

Critical Findings

Locked Fees in Vault Due to Lack of Withdraw Function

Severity: Critical

Severity: Medium

Ecosystem: Initia

Protocol: Echelon Market

Auditor: Quantstamp

Report: https://certificate.quantstamp.com/full/echelon-market/9ee15c30-6a0f-4a70-b5ce-63b8a887bd4e/index.html

Report Date: Mar 2025

Description:

The following functions used to accrue interest before changing protocol parameters. This ensure that up to the point of the changes all interest would be accumulated as per the previous configuration.

set_interest_fee_bps().
set_pair_jump_interest_rate_model().

Removing the accrual functions would lead to distorted interests as pending interest accrual would assume the new values, which could lead to sudden unexpectedly high or low interest changes.

Missing Pause Control Functions in ALMM Pair Module Leads to Non-Functional Emergency Controls

Severity: Medium

Ecosystem: Sui

Protocol: MagmaDEX

Auditor: Three Sigma

Report: https://cdn.sanity.io/files/qoqld077/staging/9566473c444a6cfd99c7a6556fa4857950b41de3.pdf

Report Date: July 2025

Description:

The magma_almm::almm_pair module has a broken pause mechanism. The AlmmPair struct includes a pause field that's initialized to false during pair creation, and critical functions like collect_fees, stake_in_magma_distribution, and collect_reward, etc. check this state with assert!(!self.pause, ErrPaused). However, there are no functions to actually pause or unpause the pair.

Missing update_position_fees in burn function

Severity: Medium

Ecosystem: Sui

Protocol: MagmaDEX

Auditor: Three Sigma

Report: https://cdn.sanity.io/files/qoqld077/staging/9566473c444a6cfd99c7a6556fa4857950b41de3.pdf

Report Date: July 2025

Description:

When changing the position liquidity either by adding/removing tokens, we always call update_position_fees. this is to make sure the . Position took the fees it deserves for that period. before changing his tokens. The function update_position_fees is called for all functions that changes the liquidity of position, this includes burn_position, raise_position_by_amounts_internal, shrink_position. But for burn, which is used to make a partial burning of the position, this function is missing.

Tokens cannot be withdrawn from admin_controlled_ecosystem_reserve.move

Severity: Medium

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Periphery

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Periphery%20V3.0.2%20Report.pdf

Report Date: June 2025

Description:

Fungible_assets is never written, so the function transfer_out() does nothing.

Incentives cannot be configured

Severity: Medium

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Periphery

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Periphery%20V3.0.2%20Report.pdf

Report Date: June 2025

Description:

rewards_controller.move does not contain functions to create RewardsConfigInput, therefore emissions_manager::configure_assets() can’t be executed.

pausable and current_pause_start Parameters cannot be Modified

Severity: Medium

Ecosystem: Aptos

Protocol: StreamFlow

Auditor: MoveBit

Report: https://movebit.xyz/reports/StreamFlow2-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

In the create function we can initialize the pausable and current_pause_start parameters, but there is no specific implementation of the pause method in the contract.

Low Findings

Unimplemented Auto Pause Feature

Severity: Low

Ecosystem: Sui

Protocol: Creek Finance

Auditor: MoveBit

Report: https://movebit.xyz/reports/Creek-Audit-Report-2025-12-30.pdf

Report Date: Dec 2025

Description:

The Market struct defines the fields auto_pause_enabled and auto_pause_threshold, indicating that the protocol was designed with an automatic pause mechanism to handle extreme market conditions. However, no logic exists anywhere in the module's code to check whether the conditions defined by auto_pause_threshold have been triggered, nor is set_paused(self, true) automatically called when those conditions are met. This results in the complete absence of this functionality, giving users a false sense of security that the protocol has automatic risk controls in place, when in reality, this mechanism is not operational.

Severity: Low

Ecosystem: Sui

Protocol: Scallop

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Scallop-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description:

The contract currently supports the functionality of registering coins and collateral assets for the protocol. However, it lacks the ability to remove or unregister coins and collateral assets.

Missing Adapter Implementation in Supra Contract

Severity: Low

Ecosystem: Sui

Protocol: Scallop

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Scallop-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description:

The Supra contract lacks implementation for the adapter. Without the adapter, the contract cannot effectively communicate or interact with the external environment, limiting its functionality and interoperability.

Description Cannot Be Modified

Severity: Low

Ecosystem: Sui

Protocol: Cetus Concentrated Liquidity Protocol (Sui)

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Sui-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

The description of open_position is specified as an empty string when the position is created, it is not passed through function parameters, and there is no function that can modify the description in other functions of the position.

Lack of Unfreeze Functionality

Severity: Low

Ecosystem: Aptos

Protocol: Echleon

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2025

Description:

There is a lack of functionality to unfreeze coin stores after a freeze operation in echelon_coin.

Lack of Token Unfreeze Functionality

Severity: Low

Ecosystem: Aptos

Protocol: Thala LSD

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2025

Description:

freeze_thapt_coin_stores permanently freezes token stores without any method to unfreeze them.

Contract Configuration and Loan Validation Improvements

Severity: Low

Ecosystem: Aptos

Protocol: Amnis

Auditor: MoveBit

Report: https://movebit.xyz/reports/Amnis-Final-Audit-Report.pdf

Report Date: Mar 2024

Description:

Currently, there is no place in the contract to modify loan_fee. Should the ability to update loan_fee be allowed in the config_pegging() function? Additionally, the loan_apt() function checks that the treasury balance must be greater than the loan amount. Should it also allow equality, as a borrower might acquire the entire balance before invoking this function? The current validation may lead to confusion for borrowers attempting to loan their entire balance.

Severity: Low

Ecosystem: Aptos

Protocol: Hyperionxyz Vaults

Auditor: ExVul

Report: https://github.com/ExVul-Sec/AuditReport/blob/main/Smartcontract/Hyperion Smart Contrat Audit Report-Exvul.pdf

Report Date: Apr 2025

Description:

The Vault contract previously lacked a pause mechanism, which is a fundamental operational control in DeFi contracts. Without a paused flag and corresponding validation logic, administrators are unable to temporarily disable critical functions (e.g., deposit, withdraw) during emergencies, upgrades, or abnormal conditions.

Missing Functionality: Partial Withdrawals

Severity: Low

Ecosystem: Sui

Protocol: MoviePass Exchange - MSX Smart Contract

Auditor: Certora

Report: https://github.com/Certora/SecurityReports/blob/main/Reports/2025/03_02_2025_MoviePass_MSX-MR.pdf

Report Date: Feb 2025

Description:

Both user and admin withdrawal functions (e.g., withdraw_custodial_pool and admin_withdraw_custodial_pool) currently withdraw the entire balance. Users who wish to withdraw only a portion of their funds must withdraw everything, then redeposit any funds they wish to keep. This may lead to increased transaction fees and reduced flexibility.

Missing the function to transfer the AdminCap object

Severity: Low

Ecosystem: Sui

Protocol: Elixir

Auditor: Pashov Audit Group

Report: https://github.com/pashov/audits/blob/master/team/pdf/Elixir-security-review_2025-08-17.pdf

Report Date: Aug 2025

Description:

The AdminCap is the protocol’s privilege credential. It is created in the init function and transferred to the sender.

However, the AdminCap object only has the key ability, which means it cannot be freely transferred via public_transfer outside the module. Moreover, there is no function within the module that allows the AdminCap holder to transfer ownership. This indicates that the functionality for owner transfer is missing.

Missing Global Pausability (All Pairs) Function for Quicker Reaction in Emergency

Severity: Low

Ecosystem: Aptos, Initia, and Movement

Protocol: Echelon Market

Auditor: Quantstamp

Report: https://certificate.quantstamp.com/full/echelon-market/9ee15c30-6a0f-4a70-b5ce-63b8a887bd4e/index.html

Report Date: Mar 2025

Description:

The isolated lending pools, while can be individually paused, lack a global pausability function. Unlike the lending core module which supports global pause flag as well as individualized market paused flag. This may result in losing valuable time in case of a hack, since all pools would have to be iterated and paused individually.

Protocol only Supports Hard Liquidations

Severity: Low

Ecosystem: Sui

Protocol: BalancerV2

Auditor: Quantstamp

Report: https://certificate.quantstamp.com/full/bucket-protocol-v-2/abd312d6-1a5e-45c5-963b-a6856daf6621/index.html

Report Date: Aug 2025

Code: N/A

Description:

The liquidation mechanism forces complete position closure regardless of how slightly a position breaches the minimum collateralization ratio. For example, a position at 149% collateralization faces total liquidation despite needing only minimal deleveraging to restore a 150% threshold. This all-or-nothing approach causes unnecessarily severe user losses and discourages efficient capital utilization near the collateralization boundaries.

The implementation allows liquidators to specify repayment amounts but always liquidates proportionally across the entire position rather than targeting a healthy collateralization ratio. This design may hold back users who are looking for optimized capital efficiency, since their position would be extremely risky.

Missing Version Check - Overview

Lack of validation for contract or dependency versions causing incompatibility or security regressions.

Missing Version Check	Findings
High	2
Medium	1
Low	9
Total	12

High Findings

Initialize Missing Version Checks

Severity: High

Ecosystem: Sui

Protocol: FlowX Finance

Auditor: MoveBit

Report: https://movebit.xyz/reports/FlowX-Final-Audit-Report.pdf

Report Date: May 2024

Description:

The old initialize function remains callable, allowing users to reinitialize the pool and potentially cause inconsistent or unintended system states.

Security Vulnerability in add_operator Function of config.move due to Missing Contract Version Check

Severity: High

Ecosystem: Sui

Protocol: Cetus Farming Smart Contracts

Auditor: MoveBit

Report: https://movebit.xyz/reports/Cetus-Farming-Smart-Contract-Final-Audit-Report.pdf

Report Date: Jan 2024

Description:

The add_operator function lacks a version check, allowing older contract versions to be called. This can reintroduce vulnerabilities or inconsistent logic from outdated deployments.

Low Findings

Missing checked_package_version Enforcement in Multiple Functions

Severity: Low

Ecosystem: Sui

Protocol: Full Sail CLMM

Auditor: Asymptotic

Report: https://info.asymptotic.tech/full-sail-clmm-audit

Report Date: May 2025

Description:

Several functions across the factory and pool modules are missing calls to checked_package_version, which is used to ensure compatibility and enforce upgrade safety in systems with upgradeable packages.

Omitting this check allows these functions to be called even when the package version is outdated or mismatched, potentially leading to unintended behavior, security vulnerabilities, or inconsistent state if the logic is changed in newer versions.

Insufficient Version Validation in Version Management

Severity: Low

Ecosystem: Sui

Protocol: Momentum CLMM

Auditor: Asymptotic

Report Date: Aug 2025

Description:

The upgrade minor and set version functions lack proper validation to ensure version updates follow a proper upgrade path. Both functions allow setting versions to any value, including the current version or even downgrading to older versions.

Severity: Low

Ecosystem: Sui

Protocol: Volo

Auditor: MoveBit

Report: https://movebit.xyz/reports/Volo-Smart-Contract-Audit-Report.pdf

Report Date: Sep 2023

Description: The function update_validators does not check the version.

update_nonce_expiration_window() lacks version validation

Severity: Low

Ecosystem: Sui

Protocol: Claynosaurz

Auditor: Certora

Report: https://github.com/Certora/SecurityReports/blob/main/Reports/2025/04_18_2025_Claynosaurz_NFT.pdf

Report Date: Apr 2025

Description:

The function update_nonce_expiration_window() doesn’t verify that the registry’s version matches the version of the module. This would allow calling the function also when a newer version is released.

Missing Package Version Validation in ALMM Pair Module

Severity: Low

Ecosystem: Aptos

Protocol: Magma DEX

Auditor: Three Sigma

Report: https://cdn.sanity.io/files/qoqld077/staging/9566473c444a6cfd99c7a6556fa4857950b41de3.pdf

Report Date: July 2025

Code: N/A

Description:

The almm_pair module lacks package version validation in its public functions. While ALMM rewarder module use cfg.checked_package_version(), the ALMM pair module omits this validation entirely. Functions execute critical operations without verifying package version, allowing incompatible logic to run after upgrades.

Oracle Issues - Overview

Manipulation or inaccuracy of external data sources impacting on-chain decisions.

Oracle Issues	Findings
Critical	3
High	5
Medium	11
Low	8
Total	27

Potential risk of manipulation of hyperion llp positions

Severity: High

Ecosystem: Aptos

Protocol: Yeap Finance

Auditor: SlowMist

Report: https://github.com/slowmist/Knowledge-Base/blob/master/open-report-V2/smart-contract/aptos-smart-contract/yeap-finance%20-%20SlowMist%20Audit%20Report.pdf

Report Date: July 2025

Description:

In the health_check module, get_amount_by_liquidity must use the pool’s real-time price; otherwise, attackers can manipulate token amounts by performing large swaps within the same transaction.

Domain pricing relies on pool price, which can be manipulated

Severity: High

Severity: Medium

Ecosystem: Aptos

Protocol: AAVE V3

Auditor: Cantina Contest SRs

Report: https://cantina.xyz/code/ad445d42-9d39-4bcf-becb-0c6c8689b767/findings/237

Report Date: June 2025

Description:

In AAVE's oracle module, we will try to fetch underlying asset's price from Oracle feed if there is not one custom price.

We will fetch the price via the interface chainlink::get_benchmark_value(benchmark) from the benchmark. According to Chainlink Aptos Doc, when we fetch the price from benchmark, we can fetch the price and the related timestamp from the benchmark.

The problem here is that we miss fetching the timestamp from the benchmark, and we don't check whether the price from Chainlink is staleness or not. If there is something wrong in Chainlink, the price don't update for a while, we may fetch stale price, this will cause we borrow/liquidate with one incorrect underlying price.

Missing oracle stale price check

Severity: Medium

Ecosystem: Aptos

Protocol: Thala Labs Aptos Dollar

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Thala%20Labs%20Move%20Dollar%20-%20Zellic%20Audit%20Report.pdf

Report Date: Feb 2023

Description:

The oracle lacks timestamps and stale-price checks. The project has switched to a tiered oracle framework, which requires a separate review.

Missing Check for Negative in get_switchboard_price() Function

Severity: Medium

Ecosystem: Aptos

Protocol: Merkle Trade Smart Contract

Auditor: MoveBit

Report: https://movebit.xyz/reports/Merkle-Trade-Smart-Contract-Audit-Report.pdf

Report Date: July 2023

Description:

The function get_switchboard_price() is used to retrieve the price and round confirmed timestamp from Switchboard. it is advised to include a check to ensure the negative is not true. If the negative value is true, it implies that there might be some problem with the price received from Oracle, potentially because the price is expired or has some error leading to potential issues.

Oracle max_deviation cannot be updated

Severity: Medium

Ecosystem: Aptos

Protocol: Aries Market

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Market-Contracts-Audit-Report.pdf

Report Date: Feb 2023

Description:

Oracle max_deviation cannot be updated in set_pyth_oracle and set_switchboard_oracle, the only way to change it is to unset the oracle and set it again.

Oracle Confidence Checks

Severity: Medium

Ecosystem: Aptos

Protocol: Argo

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2022

Description:

High oracle confidence values indicate that providers disagree on the actual price. Pyth, for example, represents confidence as the difference between the 25/75th quartile and the median price. In this case, it’s safer to ignore the value than to use a potentially inaccurate value.

Severity: Low

Ecosystem: Sui

Protocol: BalancerV2

Auditor: Quantstamp

Report: https://certificate.quantstamp.com/full/bucket-protocol-v-2/abd312d6-1a5e-45c5-963b-a6856daf6621/index.html

Report Date: Aug 2025

Description:

The protocol delegates price freshness validation entirely to external price providers rather than enforcing its own staleness requirements. Currently, only Pyth is implemented as a price source, and the protocol relies on Pyth's internal staleness checks without the ability to configure acceptable price age limits. This dependency prevents the protocol from adjusting freshness requirements based on market conditions or risk parameters. Furthermore, price feed providers, such as Pyth, will panic if the price is outdated, leaving the protocol unable to revert to other oracle providers. The lack of protocol-level control also complicates adding new price sources with different staleness guarantees.

Signature Replay - Overview

Signature replay vulnerabilities occur when attackers reuse valid cryptographic signatures or messages to repeat or spoof authorized actions due to missing or flawed replay protections.

Signature Replay	Findings
Low	3
Total	3

Low Findings

Signature Replay

Severity: Low

Ecosystem: Sui

Protocol: Drife Technologies

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Dec 2023

Code Snippet: N/A

Description:

In several functions, a signature is used to authorize and validate an action that permits users to execute specific operations only if authorized by the off-chain authority. However, in the current implementation of the signature mechanism, the same signed operation may be submitted and processed multiple times. Thus, if a malicious actor captures a valid signed transaction, they may utilize that to successfully execute that particular action repeatedly. This executes the same operation multiple times without any further demand for authentication.

Possibility of Signature Reuse

Severity: Low

Ecosystem: Sui

Protocol: Aftermath Orderbook

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2024

Code: N/A

Description: There is a risk of cryptographic signature reuse in placing stop orders within clearing_house. Cryptographic signatures rely on a blend of order-specific details and a distinct random value termed salt, introducing unpredictability. Nonetheless, if the same salt is unintentionally or intentionally used again for generating signatures for diverse stop orders, it allows an observer to detect patterns and extract information about a user’s specific stop orders, potentially compromising their privacy.

claim_boosterpack() data signature isn’t typed

Severity: Low

Ecosystem: Sui

Protocol: Claynosaurz

Auditor: Certora

Report: https://github.com/Certora/SecurityReports/blob/main/Reports/2025/04_18_2025_Claynosaurz_NFT.pdf

Report Date: Apr 2025

Description:

The claim_boosterpack() function receives signed data (bytes and signature) that contains information about the boosterpack to be claimed. The signature isn’t ‘typed’ (like in EIP-712), this might allow an attacker to re-use data that was signed from the same address for other purposes (e.g. signing a Sui tx).

Third-Party Risk - Overview

Third-party risk vulnerabilities arise from reliance on external libraries, services, or integrations that may be compromised, misconfigured, or behave unexpectedly, introducing security or availability issues.

Third-Party Risk	Findings
Low	2
Total	2

Low Findings

Reliance on Thirdparty Library Files

Severity: Low

Ecosystem: Sui

Protocol: Talofa

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Talofa-Corporation-Smart-Contract-Audit-Report.pdf

Report Date: May 2023

Description:

During the audit, it was observed that the contract incorporates a substantial number of external libraries in https://github.com/Origin-Byte/nft-protocol. These libraries, although not included in the scope of this audit, are essential for the proper functioning of the contract. It is assumed that you have already assessed and verified the security and reliability of these dependencies

Third-Party Dependency

Severity: Low

Ecosystem: Sui

Protocol: Scallop

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Scallop-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description:

During the audit process, we discovered that the system relies on third-party services for certain functionalities, such as an oracle. However, please note that this audit does not cover the third-party dependencies, including the oracle. We assume that the data provided by the oracle is accurate and properly handled by the system.

Race Condition - Overview

Race conditions occur when concurrent or out-of-order operations allow conflicting updates that produce inconsistent state and enable exploits.

Race Condition	Findings
Low	1
Total	1

Low Findings

Possible Race Condition

Severity: Low

Ecosystem: Sui

Protocol: Haedel LSD

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Nov 2023

Description: The vulnerability originates from a potential race condition during the transition between epochs, which arises when a user executes claim_coinbefore the program approves the corresponding EpochClaim object for the current epoch. Thus, if the claiming occurs before the approval, claim_epoch_record may not decrease the value of ue.amount as expected because ue.approved will be set to false.

Runtime/Development Issues - Overview

Debug-only, test, or misconfigured deployment code reaching production.

Runtime/Development Issues	Findings
Medium	10
Low	5
Total	15

While running the test cases, some failed in the pool module. For example, the test_swap case failed. In module clmm_math , the test_get_next_price_a_down should be renamed to test_get_next_price_b_down as it tests get_next_sqrt_price_b_down .

State Management - Overview

Improper updates, resets, or dependency on stale state causing protocol corruption or loss of sync.

State Management	Findings
Critical	7
High	14
Medium	19
Low	24
Total	64

A proposal cannot be canceled until it reaches an approval or rejection threshold. Proposals can get stuck if MultiSignature participants are inactive and not voting, causing data or assets in the proposal to be locked.

Lack of Validation for Campaign Status in invest

Severity: Medium

Ecosystem: Sui

Protocol: SuiPad

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/SuiPad-Smart-Contract-Audit-Report.pdf

Report Date: Apr 2023

Description:

No validation for closed campaigns — users can invest in campaigns that are already closed, leading to confusion or incorrect token distribution.

No Pool Status Check

Severity: Medium

Ecosystem: Sui

Protocol: Cetus Concentrated Liquidity Protocol

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Cetus-Concentrated-Liquidity-Protocol-Sui-Contract-Audit-Report.pdf

Report Date: Mar 2023

Description:

No suspension checks — functions like repay_flash_swap, repay_flash_swap_with_partner, update_pool_url, and update_fee_rate can still modify pool data even when the pool is suspended.

Owner’s address is not updated

Severity: Medium

Ecosystem: Sui

Protocol: Mini Miners

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Mini-Miners-Contract-Audit.pdf

Report Date: Apr 2023

Description:

info is a shared object, so ownership cannot be transferred through transfer, and after the change the ownership, the owner address in info is not updated, and the next assert will panic.

Reserve Interest Not Updated in Timely Manner

Severity: Medium

Ecosystem: Sui

Protocol: Aries Market

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Aries-Smart-Contract-Audit-Report.pdf

Report Date: June 2023

Description:

Interest may become outdated for long-standing loans; recommend periodic updates to keep interest calculations synchronized.

Shared Global Vault Without Pool-Specific Balance Tracking Enables Cross-Pool Reward Drainage

Severity: Medium

Ecosystem: Sui

Protocol: Magma DEX

Auditor: Three Sigma

Report: https://cdn.sanity.io/files/qoqld077/staging/9566473c444a6cfd99c7a6556fa4857950b41de3.pdf

Report Date: July 2025

Description:

The ALMM protocol implements a reward system where all pools share a single RewarderGlobalVault instance, while each pool maintains its own RewarderManager for tracking reward emissions and growth. The critical flaw lies in the absence of pool-specific reward balance tracking within the global vault, allowing pools to withdraw rewards that were intended for other pools.

Epoch Mismatch in Storage Reclamation

Severity: Medium

Ecosystem: Sui

Protocol: Walrus

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2025

Description:

Epoch mismatch causes extend_blob to fail: decrease_storage_to_reclaim in storage_accounting attempts to reduce storage in the wrong epoch.

Risk of Compromising Snapshot Integrity

Severity: Medium

Ecosystem: Sui

Protocol: Mysten Republic Security Token

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2025

Description:

total_supply compromised during join. join allows two different tokens to be merged into one, potentially altering the balances and total supply of tokens mid-snapshot. If tokens that are part of the snapshot join with those that are, total_supply will no longer be equal to unlocked_sum + locked_sum.

Health Check Performed On Outdated State

Severity: Medium

Ecosystem: Sui

Protocol: Navi

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: June 2023

Description:

The is_health assert in execute_withdraw and execute_borrow in logic.move depends on the user’s collateral and loan balances. However, these balances are not updated with update_state during health validation, potentially causing inaccuracies. This issue is particularly impactful during the liquidation process, as outdated collateral asset states may lead to exclusion from liquidation.

Improper Stake Update

Severity: Medium

Ecosystem: Sui

Protocol: Bucket

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: June 2023

Description:

In the handle_redeem function in bucket.move, when redeeming Bottles, the else case inside the while loop handles the last Bottle’s redemption. When the remaining redemption amount is less than the Bottle’s buck amount, the loop ends in the else case with a break and skips the call to bottle::update_stake_and_total_stake_by_debtor on the last Bottle. Needs bottle::update_stake_and_total_stake_by_debtor on break.

Restake Sui

Severity: Medium

Ecosystem: Sui

Protocol: Volo

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2023

Description:

A vulnerability arises when a user creates an UnstakeTicket for a large stake. This may prevent the user from burning the ticket and reclaiming the staked SUI during the current epoch.

Include Pending In Unstake

Severity: Medium

Ecosystem: Sui

Protocol: Volo

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2023

Description:

native_pool::burn_ticket_non_entry employs native_pool::unstake_amount_from_validators to collect SUI for returns to the user. However, it does not consider the coins held in NativePool::pending.

Missing Timestamp Update

Severity: Medium

Ecosystem: Aptos

Protocol: Aries Markets

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: May 2024

Description:

When adding or removing rewards in the liquidity farming contract, the update_reward function is called to adjust the reward per share based on the elapsed time (time_diff). However, these functions currently do not update the farm.timestamp after invoking update_reward. Consequently, if subsequent reward distribution actions occur without updating the timestamp, the rewards for the same time period will be double-claimed.

Wallet Balance Misverification

Severity: Medium

Ecosystem: Aptos

Protocol: Aptos Securitize

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

ds_token::check_wallets_for_list checks the total token balance for an investor instead of the balance in each individual wallet. This implies that even if a wallet holds zero tokens, it will still be added tothe active wallet list if the investor’s total balance is non-zero. This discrepancy may allow an investor to create a large number of empty wallets that are added to the wallet tracking structures ( wallet_indexes and wallet_list ). Thus, an investor may create numerous dead wallets (wallets with a zero token balance), initiating a token transfer to each of these wallets with a value of zero.

Missing Bound Check on Lock Removal

Severity: Medium

Ecosystem: Aptos

Protocol: Aptos Securitize

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

When a lock is removed, it is not actually deleted from the SmartTable storing lock records. This renders the data accessible in the system even after it is supposedly removed. Since locks are not fully removed from the SmartTable , view functions may show locks that should have been deleted. Also, the lock_index is not validated to ensure it is within the bounds of the investor’s lock count. Thus, the lock_index values may be out of bounds, potentially attempting to delete nonexistent records. As a result, the same lock may be removed multiple times repeatedly, each time decreasing the lock count.

Failure to Clear Investor Attributes After Removal

Severity: Medium

Ecosystem: Aptos

Protocol: Aptos Securitize

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

In registry_service::remove_investor , when an investor is removed, only their main record in the investors table is deleted. Any associated data, such as compliance attributes, remains in the attributes table. If a new investor is later registered with the same ID as the removed investor, the system will inadvertently link the new investor to the old attributes, potentially allowing unintended access to privileges based on deleted investor’s attributes.

Severity: Low

Ecosystem: Sui

Protocol: Solend Liquid Staking

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

In the current implementation of the protocol, there is no logic to remove validators from the list of validator_infos . It is possible to remove an existing validator, which will only mark it as inactive.

Failure to Update Last Used Timestamp of Vault Cap

Severity: Low

Ecosystem: Sui

Protocol: Aftermath Market Making

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Jan 2025

Description:

Due to the failure to update last_used_timestamp_ms after successfully modifying the vault parameters, the recorded last-used timestamp in the VaultOwnerCap remains unchanged, allowing additional updates to bypass the cool-down check. As a result, it will be possible to continuously update these parameters to extremely low or high values, destabilizing the system.

Lack of Synchronization Between Bank and LendingMarket

Severity: Low

Ecosystem: Sui

Protocol: Solend Steamm

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2025

Description:

The vulnerability arises from the lack of full integration between bank and LendingMarket features. It is possible for the LendingMarketOwnerCap to create additional ObligationOwnerCap instances. This implies that a new obligation may be created without requiring interaction with the Bank module, which should ideally have control over such state changes. Furthermore, claim_rewards_and_deposit allows for the claim of rewards and automatic deposit of CTokens , which increases the obligation’s CTokens balance. As this feature operates outside the control of bank, it will not account for these changes in its tracking system.

Failure to Update Default Group

Severity: Low

Ecosystem: Sui

Protocol: Mysten Republic Security Token

Auditor: OtterSec

Report:

https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Apr 2025

Description:

Within remove_address_from_group in group_holder_config , the specified address is removed from its current group (old group), and the address_info for the address is updated, setting its group_id to DEFAULT_GROUP. However, it does not add the address to the holders list of the default group in config.groups. By setting address_info.group_id to DEFAULT_GROUP, the function intends to reassign the address to the default group.

However, without updating the DEFAULT_GROUP in Group.holders, the reassignment will be incomplete. This will result in an inconsistency, as the address will appear to belong to the default group based on address_info, but it will not be listed as a holder within the actual DEFAULT_GROUP in config.groups.

Don't Transfer Zero Coin

Severity: Low

Ecosystem: Sui

Protocol: Fluidity

Auditor: MoveBit

Report: https://movebit.xyz/reports/Fluidity-Final-Audit-Report.pdf

Report Date: Feb 2024

Description:

After calling redeem , if redeemed_coin_amount is 0, the protocol will transfer zero coin to the user, which will lead to more useless objects under the address, it is recommended to call destroy_zero in the contract to destroy coin with a zero value.

pause and resume Functions Should Check States First

Severity: Low

Ecosystem: Sui

Protocol: Random-Vault

Auditor: MoveBit

Report: https://movebit.xyz/reports/Random-Vault-Final-Audit-Report.pdf

Report Date: Feb 2024

Description:

The lottery.move, pause, and resume functions are used in emergencies to pause the protocol and resume it. However, typically it should be checked if it's already paused or unpaused first. And the related event would be emitted as well.

The Value Of able_to_remove_bid May Be The Same

Severity: Low

Ecosystem: Sui

Protocol: Typus Finance

Auditor: MoveBit

Report: https://github.com/movebit/Sampled-Audit-Reports/blob/main/reports/Typus-Finance-Smart-Contract-Audit-Report.pdf

Report Date: May 2023

Description:

When updating the value of able_to_remove_bid, it is not judged whether it is the same as the original value, resulting in the value of able_to_remove_bid not being updated. In this case, no event should be emitted.

Missing Last Modifier Update

Severity: Low

Ecosystem: Aptos

Protocol: Aptos Labs Securitize

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Oct 2024

Description:

set_attribute currently does not update the last_updated_by field in the investor’s record, which may result in outdated tracking of who last modified the investor’s attributes.

Collateral flag for liquidator can be overridden by cached user config when self liquidating

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The liquidation_logic::liquidation_call keeps a cached user_config_map for the violator throughout the function.
In the middle of the function, the liquidate_a_token call can set the collateral flag to true of the liquidator (which is also the user when self-liquidating).
Afterwards, burn_bad_debt ! burn_debt_token is called which users the cached user config user_config_map that does not have the collateral flag set. If outstanding_debt == 0, it turns off the borrowing for the reserve and sets the entire user config again - overwriting the collateral flag from liquidate_a_tokens.

update_state is not updating the cache

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The pool_logic::update_state function, which computes the new indexes, takes a &mut ReserveCache but does not update its timestamp. Functions that take a &mut ReserveCache should perform the code based on the values in the reserve cache and return an updated reserve cache.

Repaying with the AToken does not turn off the use-as-collateral flag when the user use the whole AToken balance

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

Users can repay their debt by using the corresponding AToken instead of the debt's underlying. If the user consumes the whole AToken balance and the AToken was used as collateral, the system should update the user's using_as_collateral flag to false for such asset. By not turning it to false, the system creates an inconsistency between the user's balance state and the config's state which could lead to unexpected behaviors given that such a flag is widely used both directly and indirectly across the protocol's logic.

Liquidation does not turn off the use-as-collateral flag when the liquidator seize the whole borrower's collateral

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

During the liquidation process, the liquidator could have seized the whole borrower's collateral. In such case, the protocol must update the borrower's user config and turn off the use-as-collateral flag for the collateral token. The Aptos codebase is not performing such operation that could lead to unexpected behavior for the borrower.

validate_set_use_reserve_as_collateral edge case handling

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Spearbit

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit%20Aave%20Aptos%20Core%20V3.0.2%20Report.pdf

Report Date: Jun 2025

Description:

The current implementation of the validate_set_use_reserve_as_collateral will always revert if the user_balance is equal to zero. There could be edge case scenarios where the protocol has failed to turn-off automatically (rounding down errors, logic errors and so on) the use-as-collateral flag for the asset in the user's config and the user would like to manually turn that flag to false.

LTV could be mistakenly reset due to missing set_reserve_freeze() check

Severity: Low

Ecosystem: Aptos

Protocol: AAVE v3.0.2 Core

Auditor: Certora

Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Certora Aave Aptos Core V3.0.2 Report.pdf

Report Date: Apr 2025

Description:

The function set_reserve_freeze() is not checking if freeze is different from the current frozen state, which could lead to resetting the current or pending ltv accidentally. set_reserve_freeze() is supposed to work as a toggle for freezing/unfreezing reserves. However, if we perform the same action twice, for example, unfreezing and then unfreezing again, the set_reserve_freeze() functionality goes beyond toggling and undermines the configuration set by the configure_reserve_as_collateral() function.

Underconfigured state is possible

Severity: Low

Ecosystem: Aptos

Protocol: Propbase

Auditor: Hacken

Report: https://hacken.io/audits/propbase/sca-propbase-staking-feb2024/

Report Date: Feb 2024

Description:

State resources such as StakePool, StakeApp, RewardPool are not initialized atomically. This means there is a possibility for the state to be underconfigured when it is being used. Setting/updating some of the fundamental fields is optional but the validity of the state is mandatory.

Incomplete storage cleanup on full withdrawal

Severity: Low

Ecosystem: Sui

Protocol: Elixir

Auditor: Pashov Audit Group

Report: https://github.com/pashov/audits/blob/master/team/pdf/Elixir-security-review_2025-08-17.pdf

Report Date: Aug 2025

Description:

In the locked_funds.move function update_user_collateral_coin_types() when users withdraw all tokens of a specific type, the tracking list is updated, but the underlying BalanceStore dynamic field entry is not removed from storage. This is how it occurs: 1. User deposits ETH → creates BalanceStore dynamic field in deposit calling get_or_create_balance_store_mut . 2. When the user withdraws all ETH → balance becomes 0. 3. update_user_collateral_coin_types() removes ETH from the tracking list. 4. BalanceStore with zero balance remains in storage permanently. The root cause is missing cleanup logic, only tracking is updated, and actual storage persists. One concrete impact of this is gradual storage bloat, as empty balance entries accumulate over time without cleanup.

Ghost members in ACL causing potential storage bloat

Severity: Low

Ecosystem: Sui

Protocol: Elixir

Auditor: Pashov Audit Group

Report: https://github.com/pashov/audits/blob/master/team/pdf/Elixir-security-review_2025-08-17.pdf

Report Date: Aug 2025

Code: N/A

Description:

The bug occurs in remove_role and set_roles functions in acl.move, where members with all roles revoked (roles=0) remain in the roles_by_member LinkedTable without automatic removal, leading to accumulation of useless entries via repeated add/clear operations; this bloats storage and increases gas costs/iteration time in get_members , degrading performance over time.

Appendix: Move Protocols & Audit Reports

OtterSec Reports

Cetus DLMM - Nov 2025
Kuna Labs – Jun 2025
Aptos ULN 301 – May 2025
Kofi Finance Contacts – May 2025
Thala Chainlink Oracle – May 2025
Mysten Republic Security Token – Apr 2025
Mysten Deepbook V3 – Apr 2025
Echleon – Apr 2025
Echleon Staked LPT – Apr 2025
Mayan Sui – Feb 2025
Solend Steam – Feb 2025
Lombard Sui – Feb 2025
Walrus Contracts – Feb 2025
Thala LSD – Feb 2025
Thala Deps – Feb 2025
Emojicoin – Feb 2025
Thala Swap + Math V2 – Jan 2025
Aftermath Market Making – Jan 2025
TruFin – May 2024
Amnis Finance – May 2024
Aries Markets – May 2024
Sui Axelar Gateway V2 – May 2024
Cetus – May 2024
Turbos – May 2024
First Digital – Jun 2024
Mysten Deepbook – Aug 2024
Fungible StakedSui – Aug 2024
ThalaSwapV2 – Aug 2024
Merkle Token – Jul 2024
Merso Lending – Jul 2024
Hop Aggregator – Oct 2024
Solend Liquid Staking – Oct 2024
Aptos Securitize – Oct 2024
BlueFin Spot – Nov 2024
Lombard Finance – Dec 2024
Wormhole Sui Integration – Dec 2024
Drife Technologies – Dec 2023
Haedel LSD – Nov 2023
Volo – Oct 2023
Aftermath LSD – Oct 2023
Tsunami GMX – Sep 2023
Pontem clmm – Aug 2023
Scallop – Jul 2023
Navi – Jun 2023
Bucket – Jun 2023
Tortugal – Jun 2023
Aries Market (Sui) – Jun 2023
Thala – May 2023
Aftermath – May 2023
Wormhole Sui – May 2023
Mysten Labs Sui (Rust and Move) – May 2023
BlueJay – May 2023
Ghost Ivy – May 2023
Lucky Kat – May 2023
Suia – May 2023
Steamflow – Mar 2023
Typus Finance – Apr 2023
MovEX – Apr 2023
KriyaDEX – Apr 2023
MSafe Maven – Apr 2023
SuiPad – Apr 2023
Mini Miners – Apr 2023
Mokshya/Wapal Aptos NFT Mint Smart – Mar 2023
PatronusFi – Mar 2023
Aries Market (Aptos) – Feb 2023
Mole – Feb 2023
AptoPad – Feb 2023
Thala Labs – Feb 2023
Wormhole NFT Aptos – Feb 2023
Eternal Finance – Jan 2023
Cetus – Jan 2023
Pontem Harvest – Jan 2023
PancakeSwap OFT – Dec 2022
PancakeSwap IFO – Dec 2022
Econia – Dec 2022
Meeiro – Dec 2022
Aries Markets – Nov 2022
Swithboard Aptos – Nov 2022
Pancake Swap – Nov 2022
Laminar Markets – Oct 2022
Argo – Oct 2022
Tortuga – Oct 2022
Ditto – Oct 2022
Pyth – Oct 2022
Wormhole Aptos – Oct 2022
MSafe – Oct 2022
LayerZero Aptos – Sep 2022
Pontem (Liquidswap) – Sep 2022

MoveBit Reports

Creek Finance – Dec 2025
Momentum – Nov 2025
Momentum CLMM – Nov 2025
Cetus DLMM – Sep 2025
FlowX Finance – May 08, 2024
Liquidswap – Apr 20, 2024
Pontem – Apr 20, 2024
MoveGPT – Apr 11, 2024
StreamFlow – Mar 26, 2024
Superposition – Mar 26, 2024
Amnis – Mar 14, 2024
Cellana Smart Contract – Feb 20, 2024
Dola Protocol – Feb 07, 2024
Random-Vault – Feb 02, 2024
Cetus Farming Smart Contracts – Jan 19, 2024
vibrantX – Jan 08, 2024
Baptswap – Dec 18, 2023
Haedel – Dec 04, 2023
Kuna Labs Yield Optimizer Smart Contract – Nov 15, 2023
Aftermath Finance Liquid Staking Derivative – Nov 21, 2023
Supra – Sep 10, 2023
Volo – Sep 07, 2023
Kanalabs aggregator Smart Contract – Sep 07, 2023
Scallop – Jun 2023
Bucket Protocol – Jun 2023
Legend of Arcadia – Jun 2023
Aries Market (Sui) – Jun 2023
Navi – Jul 2023
Talofa Corporation – May 2023
Turbos Finance-TurboStar – May 2023
Lucky Kat – May 2023
Suia – May 2023
Typus Finance – Apr 2023
MovEX – Apr 2023
KriyaDEX – Apr 2023
MSafe Maven – Apr 2023
SuiPad – Apr 2023
Mini Miners – Apr 2023
Merkle Trade Smart Contract – Jul 21, 2023
Mokshya/Wapal Aptos NFT Mint Smart – Mar 2023
PatronusFi – Mar 2023
Cetus Concentrated Liquidity Protocol (Sui) – Mar 2023
Aries Market (Aptos) – Feb 2023
Mole – Feb 2023
AptoPad – Feb 2023
Cetus Concentrated Liquidity Protocol (Aptos) – Jan 2023
Transit Finance – Nov 2022
Sui AMM swap – Nov 2022
MoveDID – Nov 2022

Zellic Reports

Magna Finance – Nov, 2025
Matrixdock – Jul 28, 2025
Garden Move Deploy – Jun 4, 2025
Cetus – Apr 11, 2025
Magma Finance – Jan 31, 2025
Echelon – Jan 16, 2025
Econia – Jan 5, 2023
Wormhole Aptos – Nov 29, 2022
PancakeSwap Aptos – Nov 17, 2022
LiquidSwap – Nov 3, 2022
OFT – Nov 1, 2022
Laminar Markets – Oct 26, 2022
Tortuga Liquid Staking – Oct 21, 2022
Aptos Dollar – Oct 7, 2022
Momentum Safe – Sep 23, 2022

MoveJay Audit Reports

Aave Core
Aave Core v2
Aave Periphery
Navi
Kofi Finance
Poel
Studio Mirai
OL Network
Dexlyn Bridge
Project Z
StakeSphere
AquaSwap
Thala

Hacken / HackenProof

Dexlyn Perp DEX – Sep 2025
Echo Protocol Bridge – Aug 2025
Pools Finance – Jun 2025
Hacken RedStone – Feb 2025
Hacken S3Money – Jan 2025
Hacken Dexlyn Hyperlane - Dec 2024
Hacken Volo – Sep 2023
Hacken Zesh AI – Dec 2024
HackenProof DexLyn Smart Contract Audit Contest – Sep 2025

Asymptotic

Cetus CLMM – Nov 2025
Momentum CLMM – Aug 2025
Full Sail CLMM – May 2025
ZO Perps(Sudo) – Mar 2025
SatLayer Sui – Mar 2025
Aeon – Feb 2025
Bluefin RFQ – Feb 2025
Kai Finance – Aug 2024

ExVul

Hyperion – Apr 2025
TokinmonsterAI – May 2025
Mango – Jul 2025

Protocol-specific Reports

AAVE v3.0.2 Core Certora – Apr 2025
AAVE v3.1-3.3 Core Certora – Apr 2025
AAVE v3.1-3.3 Core OtterSec – Aug 2025
AAVE v3.0.2 Core Spearbit – Jun 2025
AAVE v3.1-3.3 Core Spearbit – Jun 2025
AAVE v3.0.2 Periphery Spearbit – Jun 2025

Contests

AAVE v3 Cantina Contest – May–Jun 2025
Initia Cabal Liquid Staking Code4Arena Contest – May 2025
Initia Move Code4Arena Contest – Apr 2025

Quantstamp

Echelon Market – Mar 2025
BucketV2 – Aug 2025

Sherlock

Momentum VeMMT - Nov 2025

Pashov

Elixir – Aug 2025

CertiK

Cetus DLMM - Sep 2025

Zenith

KoFi Finance - Mar 2025

SlowMist

Yeap Finance – Jul 2025

Three Sigma

Magma DEX – Jul 2025

Access the reports using the links below:

Audit Firm/Auditor	Report Links
OtterSec	Sampled Public Audit Reports (OtterSec Notion)
MoveBit	MoveBit — Sampled Audit Reports
MoveJay	MoveJay (Jayfromthe13th)
Zellic	Zellic Reports
Spearbit	Spearbit Reports
Cantina	Cantina Reports
Code4Arena	Code4Arena Reports
Certora	Certora Security Reports
Hacken	Hacken Audits
Pashov Audit Group	Pashov Audit Group — Audits
ExVul Security	ExVul Audits
Quantstamp	Quantstamp Reports
SlowMist	SlowMist Reports
Three Sigma	Three Sigma Reports
Asymptotic	Asymptotic Reports
Sherlock	Sherlock Reports