Closed c4-submissions closed 11 months ago
raymondfam marked the issue as sufficient quality report
raymondfam marked the issue as duplicate of #62
fatherGoose1 marked the issue as satisfactory
fatherGoose1 changed the severity to 2 (Med Risk)
fatherGoose1 changed the severity to 3 (High Risk)
Lines of code
https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/LRTDepositPool.sol#L136-L141 https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/LRTDepositPool.sol#L79
Vulnerability details
Impact
In LRTDepositPool::depositAsset(), it calculates the rsETH amount to be minted to the depositor per the input asset amount (a), the asset:ETH price (pa) and rsETH:ETH price (pb): (a*pa)/pb.
Per design, the rsETH:ETH price shall be calculated per the current assets balances and the current rsETH supply in the protocol. However, current implementation takes the new deposit amount also into the calculation of the rsETH:ETH price, because the new deposit is transferred into the contract before the calculation of the rsETH:ETH price. As a result, the rsETH:ETH price is a somehow higher than expected and the depositor will get less rsETH minted.
Proof of Concept
Tools Used
Recommended Mitigation Steps
In LRTDepositPool::depositAsset(), _mintRsETH() first and pull user deposit at last (i.e., IERC20(asset).transferFrom()).
Assessed type
Timing