Liquid Staking

Summary

The LSTRewardsSplitterController contract contains an unbounded loop in its checkUpkeep and performUpkeep functions. As the number of reward splitters increases, these functions may exceed the block gas limit or become too expensive to call. It is generally not a good practice to loop through an unbounded loop.

Vulnerability Details

The checkUpKeep function retuns a bytes variable representing an array of booleans, whether to call performUpKeep on the given splitter or not. However the checkUpKeep function iterates through all of the splitters that are in the storage array accounts and mapping splitters. This number could grow to a number that is too big either hiting the block gas limit or causing the function performUpKeep to be too expensive to be called. On the other hand if any of the splitters's performUpKeep function reverts this will cause the whole function to revert, causing a DoS once again. For example if this condition is met - (uint256(newRewards) < controller.rewardThreshold()) the function will revert with InsufficientRewards().

https://github.com/Cyfrin/2024-09-stakelink/blob/f5824f9ad67058b24a2c08494e51ddd7efdbb90b/contracts/core/lstRewardsSplitter/LSTRewardsSplitterController.sol#L76

https://github.com/Cyfrin/2024-09-stakelink/blob/main/contracts/core/lstRewardsSplitter/LSTRewardsSplitterController.sol#L93

Impact

1. Reward distributions could be delayed or fail entirely, affecting user returns and trust in the protocol.

2. The performUpKeep function can either hit the block gas limit or become too expensive to be called. This will make the function unusable.

Tools Used

Manual Review

Recommendations

1. Modify the checkUpkeep and performUpkeep functions to process a limited number of splitters per transaction. Implement a mechanism to track which splitters have been processed and continue from that point in subsequent calls.

2. Batch Processing: Implement a maximum batch size for processing splitters in a single transaction.

3. Tracking: Implement a more gas-efficient way to track which splitters need upkeep, such as using a bitmap or a separate queue for splitters needing processing.