Low Findings
Missing divisibility check for gr_amount in unstake
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:
In the unstake function, if gr_amount % EXCHANGE_RATE != 0 , this division will truncate the remainder, causing slight mismatch between the actual burned GR/GY and redeemed XAUM. Potential rounding inconsistencies in accounting or event reporting.
Median Calculation Does Not Take Zero Amounts Into Account, Leading to Lower Prices
Severity: Low
Ecosystem: Sui
Protocol: RedStone
Auditor: Hacken
Report: https://hacken.io/audits/redstone/sca-redstone-finance-sui-connector-feb2025/
Report Date: Feb 2025
Description:
The calculate_median function does not properly handle zero values, which can skew the median calculation downward, leading to inaccurate price reporting.
Silent Truncation in safe_mul_div Functions Leads to Incorrect Calculations
Severity: Low
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 safe_math module provides a set of utility functions for common mathematical operations intended to be used throughout the protocol. The functions safe_mul_div and safe_mul_div_u128 are designed to perform multiplication and division ((x * y) / z) while avoiding intermediate overflows by casting the operands to the larger u256 type during the calculation. These functions are likely used in critical financial logic where precision and safety are paramount. The final as u64 cast is the source of the issue. The Move language specification dictates that this type of cast truncates the higher-order bits if the source value is larger than the destination type's maximum value. This leads to a slient failure which can cause inconsistent behaviour in the system.
Total Volume Overflow Risk in Volume Tracking
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 stats module uses u64 type for total_volume tracking, which presents a potential overflow risk for active pools. While the add_total_volume_internal function is not currently used during swaps, its future implementation could lead to transaction reverts due to overflow, effectively blocking swap operations in high-volume pools.
Inconsistent Fee Calculations in calculate_fees
Severity: Low
Ecosystem: Sui
Protocol: Full Sail CLMM
Auditor: Asymptotic
Report: https://info.asymptotic.tech/full-sail-clmm-audit
Report Date: May 2025
Description:
split_fee function expects total_growth and growth_inside as call parameters for calculating, but total_liquidity and staked_liquidity are provided instead.
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.
Potential Underflow in Observation Index Check
Severity: Low
Ecosystem: Sui
Protocol: Momentum CLMM
Auditor: Asymptotic
Report Date: Aug 2025
Description:
The function oracle::try get observation checks if an index is out of bounds using if (index ¿ vector::length¡Observation¿(observations) - 1) If the observations vector is empty, this can cause an underflow, as subtracting 1 from zero. While the first observation is created during initialization (making this safe in practice), the check is non-idiomatic and could lead to issues if the initialization logic changes.
Incorrect Fee Calculation Due To Stale active_id In Swaps
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 swap_in_pool function calculates the variable fee for a swap based on the price volatility, which is measured by the distance between the current active_id and a stable index_reference . A logical flaw exists in how active_id is used within the swap loop, leading to an incorrect fee calculation for the first bin processed in a swap. The function uses pool.active_id at the beginning of each loop iteration to calculate the volatility and the corresponding fee. However, if there is a gap in liquidity (i.e., the bin at pool.active_id is empty), the swap will start at the next available liquidity bin. The function correctly identifies this starting bin, but it fails to update pool.active_id to this actual starting bin's ID before the first fee calculation. Instead, it uses the stale pool.active_id from before the swap began. Consequently, the fee for the first chunk of the swap is calculated using an incorrect price delta, often resulting in a lower fee than intended.
price_math::pow Does Not Handle Base = 1 as a Special Case
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 current implementation of price_math::pow , when the base is exactly 1.0 (represented as 1 << 64 in Q64.64 fixed-point format), the result is not guaranteed to be exactly 1.0 due to precision loss in the computation.
Underflow due to Uncapped Flow Limit
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: The set_flow_limit function allows setting the flow limit to any value, including the maximum value that can be stored in a u64. This is problematic because, with such a high limit, an overflow may occur in the assertion condition inside add_flow_out, which will cause the assertion check to fail and prevent transfers entirely. While the current system does not actively support setting arbitrary flow limits, a cap should be imposed nonetheless.
Possible Abort due to Underflow
Severity: Low
Ecosystem: Sui
Protocol: Fungible StakedSui
Auditor: OtterSec
Report:
https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Aug 2024
Description: If total_sui_amount is less than fungible_staked_sui_data_principal_amount , this subtraction will result in a negative value, causing an underflow error and, consequently, an abortion.
Overestimation of Tokens Resulting in Oversupply
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 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.
Precision Loss
Severity: Low
Ecosystem: Sui
Protocol: SuiPad
Auditor: MoveBit
Report Date: May 2023
Description: Divide first and then multiply will lose precision in the operation.
Accuracy Loss
Severity: Low
Ecosystem: Sui
Protocol: SuiPad
Auditor: MoveBit
Report Date: May 2023
Description:
In the withdraw function, there is an accuracy loss in the calculation of lock.amount / 100 * pool.investment_lock_penalty, this calculation should be multiplied first and then divided.
Overflow Risk in Utility Functions
Severity: Low
Ecosystem: Sui
Protocol: Aries Market (Sui)
Auditor: MoveBit
Report Date: June 2023
Description:
In the decimal.move the file, it was found that some multiplication and addition/subtraction operations were not being checked for overflow risk in some functions.
Inconsistent Scaling in Conversion Rate Calculation
Severity: Low
Ecosystem: Aptos
Protocol: Kofi Finance Contacts
Auditor: OtterSec
Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: May 2025
Description:
The math::ratio function applies inconsistent scaling in its conversion logic, leading to potential imbalances between kAPT and stkAPT.
Risk of Overpayment
Severity: Low
Ecosystem: Aptos
Protocol: Kofi Finance Contacts
Auditor: OtterSec
Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: May 2025
Description:
math::from_shares assigns a minimum of 1 share, even if the calculated amount is 0, leading to protocol overpayment during unstaking.
Incorrect Pool Balance Calculation
Severity: Low
Ecosystem: Aptos
Protocol: ThalaSwapV2
Auditor: OtterSec
Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Aug 2024
Description:
swap_exact_out_stable utilizes normalized balances ( pool_balances_normalized ) instead of actual balances ( pool_balances ) when checking available liquidity, resulting in incorrect calculations.
Incorrect Rounding Directions
Severity: Low
Ecosystem: Aptos
Protocol: TruFin
Auditor: OtterSec
Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: May 2024
Description:
internal_unlock unlocks the amount from the delegation pool and burns the equivalent TruAPT tokens. It creates an UnlockRequest for the user with the unstaked amount, which later facilitates the withdrawal of APT from the protocol. amount represents the staker requested for unstaking from the delegation pool and allocated to the user, and truAPT_amount denotes the tokens taken from the user and burned. The protocol benefits from rounding down when calculating amount and rounding up when calculating truAPT_amount.
Unaccounted Rounding Errors in Restake Functionality
Severity: Low
Ecosystem: Aptos
Protocol: Amnis Finance
Auditor: OtterSec
Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: May 2024
Description:
delegation_manager::restake calculates the amount of pending inactive stake to restake (restake_amount) based on the minimum between the remaining amount to restake (remain_amount) and the available pending inactive stake. However, it does not account for rounding errors originating from delegation_pool::reactivate_stake, leading to cases where the pool covers these losses.
Exemption of Users From Covering Rounding Errors
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 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 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 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 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 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 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 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.