Rounding error when depositing will cause loss of funds for caller #357
Labels
bug
Something isn't working
downgraded by judge
Judge downgraded the risk level of this issue
duplicate-479
grade-b
Q-79
QA (Quality Assurance)
Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax
satisfactory
satisfies C4 submission criteria; eligible for awards
sufficient quality report
This report is of sufficient quality
Lines of code
https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/LRTDepositPool.sol#L109
https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/LRTDepositPool.sol#L151-L156
Vulnerability details
Impact
Significant loss of user funds, when calling
depositAsset
the user will lose theirdepositAmount
and receive 0RsETH
in return due to a rounding area, for specificassets
.Proof of Concept
The protocol intends to use Chainlink Price Feeds as the price oracle however they haven't considered the fact that most price feeds denominated in USD return prices to 8 decimals.
This is problematic as
RsETH
is 18 decimals, therefore ingetRsETHAmountToMint
the returned amount to mint will likely round to 0 for these assets as you can see here.The value from
getAssetPrice
is computed as so:As you can see the value is used directly, without any consideration of the decimals.
Also, the depositAsset function doesn't allow the user to specify a minimum amount of
RsETH
to receive and there is no validation of the minted amount, meaning should this rounding error occur it will not be caught.Tools Used
manual
Recommended Mitigation Steps
Account for the decimals from the returned value of the price feed, and allow users to specify a minimum amount of RsETH to receive.
Assessed type
Invalid Validation
The text was updated successfully, but these errors were encountered: