Liquid Staking

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

Direct stakers in `PriorityPool` miss out on staking rewards due to flawed reward distribution logic

Summary

Users who directly deposit their tokens into the PriorityPool receive Liquid Staking Tokens (LST) at a 1:1 conversion rate with their deposited LINK. However, the contract lacks proper accounting mechanisms to track depositor balances or reward accrual over time. As a result, these users are unable to earn staking rewards, and when they exit the protocol, they receive the exact amount of LINK they initially deposited, without any yield. This system is flawed, as it doesn’t factor in any changes in users' balances or the duration they have staked, leading to a loss of potential rewards.

Vulnerability Details

When users directly deposit their LINK without queuing, they receive LST tokens at a 1:1 ratio with their deposit amount:

uint256 toDeposit = _amount;
uint256 queuedWithdrawals = withdrawalPool.getTotalQueuedWithdrawals();
if (queuedWithdrawals != 0) {
uint256 toDepositIntoQueue = toDeposit <= queuedWithdrawals
? toDeposit
: queuedWithdrawals;
withdrawalPool.deposit(toDepositIntoQueue);
toDeposit -= toDepositIntoQueue;
IERC20Upgradeable(address(stakingPool)).safeTransfer(_account, toDepositIntoQueue);
}

However, the PriorityPool contract does not track users' balances or how long they have held their LST tokens. No matter how long users hold their LST, when they choose to withdraw, they receive the same amount of LINK they originally deposited:

IERC20Upgradeable(address(stakingPool)).safeTransferFrom(
account,
address(this),
toWithdraw
);
toWithdraw = _withdraw(account, toWithdraw, _shouldQueueWithdrawal);
token.safeTransfer(account, _amountToWithdraw - toWithdraw);

This logic does not account for any accrued staking rewards, effectively denying users any yield. Although the protocol may claim that rewards can be collected via PriorityPool::claimLSDTokens, this method is flawed. The contract has no mechanism to track how long each user has staked, making it infeasible to calculate rewards fairly.

The only option the protocol has is tracking the change in account balance for every LST holder, which is infeasible. To accurately distribute rewards based on LST holdings over time, the contract would need to track every balance change for every user, which is impractical and resource-intensive. The lack of a variable exchange rate at deposit and withdrawal also prevents the fair distribution of staking rewards. Ideally, users should receive shares of a staking pool, which grows over time with accrued rewards, and the exchange rate should reflect the pool's value when users withdraw their LINK.

Impact

Direct stakers miss out on staking rewards because the protocol does not account for the duration of their staking period or the change in value of their LST holdings. The flawed system denies users their fair share of accrued rewards, leaving them with only their initial deposit when they exit. This results in a significant loss of potential yield for users, making the staking mechanism ineffective.

Tools Used

Manual

Recommendations

Updates

Lead Judging Commences

inallhonesty Lead Judge
11 months ago
inallhonesty Lead Judge 10 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

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