The notifyRewardAmount function calculates rewardRate as amount / periodDuration without a strict upper bound beyond a balance check against MAX_REWARD_RATE = 1000000e18. A misconfigured or malicious controller could set an excessively high amount, potentially exceeding practical limits and skewing rewards or causing reverts. This medium-impact, low-likelihood issue risks reward distribution integrity.
The function lacks an explicit cap on rewardRate beyond a balance check. Assumptions:
periodDuration is 7 days (604,800 seconds, common in gauges).
MAX_REWARD_RATE = 1000000e18 (1M crvUSD/sec in wei).
Scenario:
Controller calls notifyRewardAmount with amount = 1e30 (1 trillion crvUSD).
rewardRate = 1e30 / 604800 ≈ 1.98e23 wei/sec.
If pool balance is 1e24 wei ($1M), rewardRate * periodDuration = 1.2e29 < 1e30, passing balance check but exceeding MAX_REWARD_RATE.
Over-distributes $1M rewards early, leaving $500K intended share skewed.
Without a direct rewardRate cap, large amount values disrupt fairness or revert downstream.
Reward misallocation (e.g., $500K lost to early claimers) is a medium-impact issue, disrupting fairness in a $1M pool. The low likelihood requires a misconfigured controller or extreme amount, mitigated by balance checks but not fully prevented without a cap.
Manual Code Review: To verify missing explicit cap beyond balance check in notifyRewardAmount.
Cap rewardRate explicitly:
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.