Security

The core of the issue lies in the timing between two critical function calls: notifyRewardAmount(): This function is called to start a new reward period and to set the amount of rewards that will be distributed during this period. stake(): This function is used by stakers to stake their tokens and begin earning rewards. The problem arises when there is a delay (Y) between the execution of notifyRewardAmount() and the first call to stake() in a new reward period. Here’s a step-by-step explanation: Step 1: At block timestamp X, notifyRewardAmount() is called, initiating a new reward period intended to last for 2,592,000 seconds (one month). Step 2: There is a delay of Y seconds before the first stake() call is made. For example, if Y is 1,800 seconds (30 minutes), then no tokens are staked to earn rewards during these 1,800 seconds. Step 3: Because the reward distribution is set to end at X + 2,592,000 seconds (the end of the month from the start time), the rewards that would have been distributed during the initial 1,800 seconds (when no tokens were staked) remain undistributed and are essentially locked in the contract until the next reward period begins. Consequences This delay results in: Underutilization of Rewards: The 1,800 tokens that could have been distributed during the initial delay remain unused. This means less overall distribution of rewards during the period, which is inefficient. Locked Rewards: These undistributed rewards are locked in the contract and do not benefit any stakers. They only become relevant or usable in the next reward cycle, which could potentially lead to discrepancies in reward expectations and planning for stakers.