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
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
Incorrect Data in Event
Severity: Low
Ecosystem: Sui
Protocol: Navi
Auditor: MoveBit
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 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 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.