The StakingPool#deposit() function is designed to ensure that the number of tokens sitting in the pool outside of a strategy does not exceed the unusedDepositLimit. However, the current implementation only checks if both endingBalance > startingBalance and endingBalance > unusedDepositLimit. This logic can cause a situation where the first condition is false but the second condition is true, allowing more tokens than permitted to remain in the pool, violating the protocol’s invariant.
The inline documentation clearly states that unusedDepositLimit is the "max number of tokens that can sit in the pool outside of a strategy." However, the condition used in the deposit function is the following:
This condition requires both endingBalance > startingBalance and endingBalance > unusedDepositLimit to trigger the revert. This could lead to a scenario where endingBalance does exceed unusedDepositLimit, but because endingBalance > startingBalance is false, the function does not revert, allowing more tokens to sit idle in the pool than allowed by the unusedDepositLimit. This breaks one of the protocol invariants regarding liquidity management.
This issue can lead to the violation of the protocol's invariant, allowing more tokens than intended to sit in the pool, which could affect liquidity distribution and create unexpected behavior in the staking mechanism.
Manual audit
Change the condition to use || instead of && to ensure that the function reverts if either endingBalance > unusedDepositLimit or endingBalance > startingBalance.
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.