Liquid Staking

Stakelink
DeFiHardhatOracle
50,000 USDC
View results
Submission Details
Severity: high
Invalid

PriorityPool::withdraw() is implemented incorrectly

Summary

Alice has 100 LST which she wants to convert back to LINK tokens. She calls PriorityPool::withdraw() with _shouldUnqueue set to false and there are 80 LINK tokens judging from the value of totalQueued, this means that 20 will be queued for withdrawal such as here -> https://github.com/Cyfrin/2024-09-stakelink/blob/main/contracts/core/priorityPool/PriorityPool.sol#L679

This presents the following problem: how will those 80 tokens, that were used for exchange to LST, be claimed from the people that had their LINK queued in totalQueued. I do not see any function that actually makes that possible.

Vulnerability Details

Alice has 100 LST and she wants to exchange them back to the LINK token due to personal reasons. If the contract of PriorityPool.sol has actually 100 tokens (totalQueued is used for tracking LINK tokens in this contract), then she can instantly withdraw them, otherwise whatever tokens are in the totalQueued are to be given momentarily, the rest going to be queued for a withdrawal when possible.

The issue in all of this stems from the following: if Alice calls PriorityPool::withdraw() willing to exchange all of her 100 LST tokens and totalQueued is let's say... 100 tokens for simplicity, she will actually be able to exchange LST -> LINK, but the users which had queued the 100 LINK tokens won't be able to claim the tokens that she had sent to the PriorityPool.sol. This is where the LST is send from Alice to PriorityPool.sol -> https://github.com/Cyfrin/2024-09-stakelink/blob/main/contracts/core/priorityPool/PriorityPool.sol#L312-L316.

Vulnerability in steps:

  1. Alice has 100 LST and decides to call PriorityPool::withdraw() with _shouldUnqueue set to false

  2. The 100 LST are transferred from her wallet to the PriorityPool.sol in https://github.com/Cyfrin/2024-09-stakelink/blob/main/contracts/core/priorityPool/PriorityPool.sol#L312-L316.

  3. She claims her 100 LINK token successfully, but the users which had queued their token do not have any mechanism to claim the 100 LST that were deposited by Alice

Impact

Overtime, more and more LST is destined to be stuck in PriorityPool.sol with its current implementation causing loss of funds that were deposited by the users interacting with the protocol.

Tools Used

Manual review

Recommendations

Make a function that can claim LST.

Updates

Lead Judging Commences

inallhonesty Lead Judge
about 1 year ago
inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.