Liquid Staking

Summary

The protocol's documentation mentions that if the StakingPool lacks deposit room and later gets space, users with more reSDL tokens should be prioritized for deposits in PriorityPool. However, this prioritization mechanism is not implemented in the actual PriorityPool::_depositQueuedTokens function, which can lead to fairness and order issues for users with larger reSDL balances who expect priority.

Vulnerability Detail

The vulnerability arises from the discrepancy between the protocol documentation and the actual implementation of the deposit process. According to the documentation, users with higher reSDL token balances should be prioritized for deposits when the StakingPoolhas limited room and later gains availability. However, in the PriorityPool::_depositQueuedTokens function, there is no logic that prioritizes deposits based on reSDL token holdings.

Instead, the function calculates the available deposit room and attempts to fill it with a mix of unused deposits and queued tokens, but without giving preference to users with higher reSDL balances. This inconsistency may lead to situations where users with fewer reSDL tokens are allowed to deposit before users with more reSDL tokens, which contradicts the intended functionality as described in the documentation.

Impact

This issue affects the fairness of the deposit process for users. Users holding more reSDL tokens might expect priority when the staking pool has limited room, but since the prioritization logic is absent, they may not receive the anticipated benefits. This can cause user dissatisfaction and could be considered a violation of the protocol's intended behavior.

Code Snippet

https://github.com/Cyfrin/2024-09-stakelink/blob/f5824f9ad67058b24a2c08494e51ddd7efdbb90b/contracts/core/priorityPool/PriorityPool.sol#L693

Tool Used

Manual code review and documentation comparison.

Recommendation

To resolve this issue, implement logic in the PriorityPool::_depositQueuedTokens function that prioritizes users with more reSDL tokens when there is limited deposit room in the StakingPool. This could involve sorting queued deposits by reSDL token balances and ensuring those with higher balances are processed first, as per the protocol's intended design.