Liquid Staking

Summary

In OperatorVCS::updateDeposits, reward tokens are incorrectly counted twice during deposit accounting, leading to an inflated calculation of fees and rewards. This error causes the protocol to mint and distribute excess Liquid Staking Tokens (LST) to fee receivers, distorting the token supply and unfairly distributing rewards.

Vulnerability Details

When OperatorVCS::updateDeposits is called by the StakingPool to update deposit accounting and calculate fees on newly earned rewards, it calls each vault to retrieve the (uint256 deposits, uint256 principal, uint256 rewards) values.

According to OperatorVault::updateDeposits, if the accrued rewards exceed _minRewards, they are sent to the OperatorVCS contract:

The problem arises in OperatorVCS::updateDeposits, where the operatorRewards are incorrectly treated as though they are separate from depositChange. However, operatorRewards are already included in depositChange when the tokens are sent from OperatorVault to OperatorVCS once rewards exceed _minRewards. This results in operatorRewards being double-counted when calculating the total rewards.

In StakingPool::_updateStrategyRewards, the amounts returned by OperatorVCS::updateDeposits are added to the strategyFeeAmounts array, and these values are summed to derive totalFeeAmounts. This value is then used to calculate sharesToMint, which determines the number of shares minted and distributed to fee receivers. Since operatorRewards are counted twice, the protocol mints excess shares, inflating the total rewards distributed.

Impact

This double counting leads to an overestimation of rewards and the minting of excess LST shares to fee receivers. The inflation of the token supply distorts the protocol's tokenomics, resulting in an unfair distribution of rewards and a dilution of value for other stakers.

Tools Used

Manual

Recommendations

Refactor OperatorVCS::updateDeposits to ensure that operatorRewards are not double-counted.