The setRewardThreshold function in the LSTRewardsSplitterController contract is designed to update the minimum amount of rewards required before a split operation is performed. This threshold is meant to be used by individual LSTRewardsSplitter contracts.
The issue is that changing the rewardThreshold in the controller does not directly affect the behavior of existing LSTRewardsSplitter contracts. The splitters query the controller's threshold in their checkUpkeep function, but there's no mechanism to notify splitters of threshold changes or to trigger immediate checks.
In LSTRewardsSplitterController:
In LSTRewardsSplitter:
Delayed Effect: Changes to the reward threshold may not immediately affect the system's behavior.
Inconsistent State: There could be a period where the controller's threshold and the actual splitting behavior are out of sync.
Potential for Missed Splits: If the threshold is lowered, splitters won't immediately check if they now qualify for a split.
The system is running with a reward threshold of 1000 tokens.
Several splitters have accumulated 800 tokens each.
The owner decides to lower the threshold to 500 tokens and calls setRewardThreshold.
Despite now being eligible for a split, the splitters won't perform one until their next checkUpkeep call.
This delay could lead to larger-than-intended accumulations of rewards before splitting.
To address this issue, we need to implement a mechanism to trigger immediate checks on all splitters when the threshold changes.
In LSTRewardsSplitterController:
This fix ensures that when the reward threshold is changed, all splitters immediately check if they need to perform a split, maintaining system consistency and responsiveness to threshold changes.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.