The updateDeposits function in the OperatorVault contract has a potential logic flaw that can lead to incorrect reward calculations and unintended behaviors.
The updateDeposits function is responsible for updating the deposit and reward accounting for the vault. The logic used to calculate the newly earned rewards and adjust tracked total deposits may be flawed, especially if the contract does not account for changes in deposits accurately. This can lead to scenarios where rewards are either over-claimed or under-claimed, potentially affecting the financial integrity of the contract.
The updateDeposits function recalculates deposits and rewards based on the difference between total deposits and trackedTotalDeposits. However, the condition if (depositChange > 0) only allows positive changes to affect rewards. If there are negative changes, they might not be accounted for properly.
Issue here is that:
The way the depositChange is calculated does not effectively handle edge cases where deposits might decrease, leading to incorrect calculations for opRewards.
If rewards are not accurately accounted for when deposits decrease, the operator may miss out on rewards that they are entitled to.
The management of trackedTotalDeposits does not effectively account for changes in rewards, leading to potential discrepancies in the rewards distribution logic.
PoC:
Scenario: An operator deposits a certain amount, and the rewards are updated. If the deposits later decrease (for example, due to an improper withdrawal or mistake), the logic may not adjust correctly, causing rewards to be miscalculated.
Realistic PoC:
Deploy the OperatorVault contract.
Deposit a certain amount and accumulate rewards.
Simulate a decrease in deposits and observe how the reward calculation fails.
Expected output:
The rewards calculation after the withdrawal should accurately reflect the change in deposits. If the logic flaw is present, it may result in an incorrect rewards amount.
Here’s a sample test script using Hardhat to demonstrate the potential logic flaw in the updateDeposits function:
If the logic flaw persists, operators may miss out on rewards, leading to financial losses.
Users may lose trust in the system if they perceive that rewards are not managed correctly.
Inefficient reward calculations may lead to increased gas costs and resource usage.
Manual review.
Ensure that the logic accurately accounts for all changes in deposits, including reductions due to withdrawals.
Introduce conditions that validate the integrity of deposits and rewards before proceeding with updates.
Implement comprehensive unit tests to catch potential edge cases in reward calculations, and conduct regular code reviews to identify logical flaws.
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.