Open code423n4 opened 1 year ago
dmvt marked the issue as primary issue
vince0656 marked the issue as sponsor disputed
This doesn't factor in that when ETH is supplied to a liquid staking network, it has 30 minutes to be utilized for staking with the BLS public key - giant pool users can manage this inventory and move the liquidity between BLS keys but that's by design and as mentioned above cannot move for 30 minutes at a time. If it never gets used, it can always go back to the giant pool
dmvt marked the issue as nullified
dmvt marked the issue as satisfactory
dmvt marked the issue as selected for report
Lines of code
https://github.com/code-423n4/2022-11-stakehouse/blob/4b6828e9c807f2f7c569e6d721ca1289f7cf7112/contracts/liquid-staking/GiantMevAndFeesPool.sol#L105
Vulnerability details
Description
batchRotateLPTokens in GiantMevAndFeesPool allows any user to rotate LP tokens of stakingFundsVaults around.
There is a check that sender has over 0.5 ether of lpTokenETH, to prevent griefing. However, this check is unsatisfactory as user can at any stage deposit ETH to receive lpTokenETH and burn it to receive back ETH. Their lpTokenETH holdings do not correlate with their interest in the vault funds.
Therefore, malicious users can keep bouncing LP tokens around and prevent them from being available for actual staking by liquid staking manager.
Impact
Giant pools are prone to user griefing, preventing their holdings from being staked.
Tools Used
Manual audit
Recommended Mitigation Steps
Three options: