The performUpkeep
function within the RewardsInitiator contract exhibits a critical flaw. This function, intended to update strategy rewards in the event of a negative rebase, is hindered by its stringent validation mechanism. Specifically, if any one of the strategies undergoing an update possesses a positive deposit change, the entire transaction is aborted. This mechanism not only fails to address the rewards update for other strategies with negative deposit changes but also halts the distribution of rewards to cross-chain SDL pools.
The vulnerability arises in the loop within the performUpkeep function, where each strategy's deposit change is evaluated. The existing condition checks if IStrategy(strategies[strategiesToUpdate[i]]).getDepositChange()
is greater than or equal to zero. If this condition is met, the function reverts with a PositiveDepositChange
error. This approach does not account for the scenario where multiple strategies are involved, and at least one has a positive deposit change. In such a case, even if other strategies require an update due to a negative deposit change, the function will prematurely terminate, leaving these strategies unattended.
The primary impact of this issue is the potential blockade of the reward distribution process. In a scenario where multiple strategies are involved in the performUpkeep
call, a single strategy with a positive deposit change can prevent the update of rewards for all other strategies, irrespective of their need for an update. This not only disrupts the intended functionality of the performUpkeep
function but also negatively impacts the distribution of rewards to cross-chain SDL pools, effectively halting a critical component of the contract's operations.
Also a second case that can lead to this scenario: malicious users can cause a DDoS by ensuring that at least one the strategies remain with the positive balance as this result depends of the balanceOf function that is used to calculate the deposit change.
Manual Review
Modify the loop to ignore strategies with a positive deposit change, allowing the update process to continue for those with negative changes. This ensures that the presence of a positively performing strategy does not impede the update process for others.
For a more efficient solution, adopt a strategy similar to the one used in the Beefy contracts, specifically the VaultGasOverheadAnalyzer.sol(https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/keepers/contracts/VaultGasOverheadAnalyzer.sol).
This mechanism keep checking and updating only the strategies that are "pending" without compromising the rewards distribution.
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.