search

code-423n4 / 2024-05-predy-validation

0 stars 0 forks source link

Hardcoded `1e18` Amount Causes Issues with Non-Standard Decimal Tokens #303

Open c4-bot-3 opened 3 months ago

c4-bot-3 commented 3 months ago

Lines of code

https://github.com/code-423n4/2024-05-predy/blob/a9246db5f874a91fb71c296aac6a66902289306a/src/libraries/Trade.sol#L87

Vulnerability details

Proof of Concept

In the Trade library, there is a hardcoded value of 1e18 used in the calculation of stable amounts. This value represents 1 unit in a token with 18 decimals, which is common for many ERC20 tokens. However, not all tokens adhere to this standard, and using a fixed decimal value can lead to incorrect calculations and potential security issues.

The issue is present in the following line within the swap function:

int256 amountQuote = calculateStableAmount(sqrtPrice, 1e18).toInt256();

This hardcoded 1e18 does not account for tokens that may have different decimal places(WBTC, WETH...etc), which can lead to miscalculations in the amount of tokens required or returned in a swap operation. This can affect the precision and correctness of trading operations, ultimately impacting the functionality and security of the platform.

Impact

If a token with non-standard decimal places is used, the trade calculations will be incorrect, potentially leading to significant financial discrepancies. Users could end up with less or more tokens than expected, causing losses or unintentional arbitrage opportunities.

Tools Used

Manual

Recommended Mitigation Steps

Add a function to fetch the token decimals. Use this function to dynamically calculate amounts based on the token decimals. Update the hardcoded 1e18 value to use the dynamically fetched decimal value.

Assessed type

Decimal

Yasashari commented 2 months ago

Hello @alex-ppg . Here It is hardcorded token amount to 1e18. But this protocol is going to use WETH, USDC (non standard erc20 tokens) ...etc. Could you please check this and let me know feedback here ? Thank You