In ThunderLoanUpgraded.sol:98
, the audit uncovered that the contract's fee precision is set as a constant (FEE_PRECISION = 1e18
). This implementation assumes all ERC20 tokens will operate with 18 decimal places, which is not always the case. Tokens can have various decimal definitions, and this constant setting fails to account for such variations.
Vulnerable code:
The impact of this vulnerability is significant for any ERC20 token that does not use 18 decimal places. If such a token were to be used with this contract, fee calculations would be incorrect, resulting in either overcharging or undercharging for flash loan services. This can lead to financial loss for either the contract or the users, depending on the scenario.
Manual Review
Vs Code
The contract should be updated to dynamically handle ERC20 token decimals for fee calculations. The following changes are recommended:
Remove the FEE_PRECISION
constant and replace it with a variable that can be set either:
Globally, by fetching the decimal value from each ERC20 token upon interaction, or
Individually for each ERC20 token pair within the s_tokenToAssetToken
mapping.
Ensure that wherever FEE_PRECISION
is currently used, the contract performs a check to retrieve the correct decimal count from the token in question.
Consider implementing a function to update the fee precision for existing asset tokens, should the need arise to accommodate new tokens with unique decimal values.
Conduct thorough testing with multiple ERC20 tokens having various decimal places to ensure the new implementation works as expected without any precision loss.
Regular audits and monitoring should be conducted post-implementation to prevent any future issues related to token decimal precision.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.