Liquid Staking

Summary

The PriorityPool contract fails to update the sharesSinceLastUpdate variable when withdrawals are fulfilled with the user's own queued tokens. This omission leads to inaccuracies in reward calculations, as the variable plays a critical role in tracking the total shares received since the last distribution. The protocol properly updates this variable in most cases, but overlooks this specific withdrawal scenario.

Vulnerability Details

The sharesSinceLastUpdate variable tracks the total number of shares received for tokens deposited into the staking pool since the last distribution. This is essential for accurate reward calculation and managing queued tokens.
In most cases, such as in PriorityPool::_withdraw and PriorityPool::_depositQueuedTokens, this variable is correctly updated when queued tokens are processed, either to fulfill withdrawals or deposit tokens into the staking pool.
However, the protocol fails to update sharesSinceLastUpdate when a user’s withdrawal request is fulfilled using their own queued deposit tokens. The omission occurs before PriorityPool::_withdraw is called in PriorityPool::withdraw, as shown below:

While other relevant variables are updated, sharesSinceLastUpdate is not, causing discrepancies in the protocol's accounting and reward distribution.

Impact

Failing to update sharesSinceLastUpdate results in incorrect reward calculations, as the protocol does not accurately account for the shares distributed when withdrawals are fulfilled with queued tokens.

Tools Used

Manual

Recommendations

Ensure that sharesSinceLastUpdate is updated in all cases where queued tokens are used to fulfill withdrawals, including when users' own queued deposit tokens are processed. This will prevent accounting errors and ensure accurate reward distribution.