TempleGold

TempleDAO
Foundry
25,000 USDC
View results
Submission Details
Severity: low
Invalid

Possible extended reward distribution delay

Summary

The rewardDuration parameter in the TempleGoldStaking contract currently has no upper limit, which could lead to excessively long periods between reward distributions. This would even make the rewardData.periodFinish too high if a distribution is successfully executed.

Vulnerability Details

The rewardDuration parameter, which defines the duration for distributing staking rewards, acts as a minimum rewardAmount, which rewardAmount depends on the percentage of TempleGold received and on the (numerator/denomerator) which three can be changed in the TempleGold contract anytime, so if the rewardDuration is not updated accordingly the issue can appear, also if arbitrary reward distribution delay is needed the storage variable rewardDistributionCoolDown is more than sufficient.

https://github.com/Cyfrin/2024-07-templegold/blob/57a3e597e9199f9e9e0c26aab2123332eb19cc28/protocol/contracts/templegold/TempleGoldStaking.sol#L190

function distributeRewards() updateReward(address(0), 0) external
...
_distributeGold();
uint256 rewardAmount = nextRewardAmount;
// revert if next reward is 0 or less than reward duration (final dust amounts)
> if (rewardAmount < rewardDuration ) { revert CommonEventsAndErrors.ExpectedNonZero(); }
nextRewardAmount = 0;
_notifyReward(rewardAmount);
lastRewardNotificationTimestamp = uint32(block.timestamp);
}

If set to a very high value, it could result in prolonged intervals between reward rate updates and Temple Gold distribution, potentially causing stakers to wait an excessively long time to receive their rewards. This means that stakers might have to wait an enormous amount of time to see their rewards, which is not ideal.

Impact

An excessively high rewardDuration can delay the reward distribution process, forcing users to wait for an extended period to see their reward rates updated and receive their Temple Gold. This delay can diminish user satisfaction and confidence in the staking process. The rewardDurationcan be easily updated if this issue occurs, but have to wait a lot if distributeRewards (which calls_notifyRewards) was successfully executed:

https://github.com/Cyfrin/2024-07-templegold/blob/57a3e597e9199f9e9e0c26aab2123332eb19cc28/protocol/contracts/templegold/TempleGoldStaking.sol#L515C1-L529C6

function _notifyReward(uint256 amount) private {
...
rewardData.periodFinish = uint40(block.timestamp + rewardDuration);
}

https://github.com/Cyfrin/2024-07-templegold/blob/57a3e597e9199f9e9e0c26aab2123332eb19cc28/protocol/contracts/templegold/TempleGoldStaking.sol#L107

function setRewardDuration(uint256 _duration) external override onlyElevatedAccess {
// minimum reward duration
if (_duration < WEEK_LENGTH) { revert CommonEventsAndErrors.InvalidParam(); }
// only change after reward epoch ends
> if (rewardData.periodFinish >= block.timestamp) { revert InvalidOperation(); }
rewardDuration = _duration;
emit RewardDurationSet(_duration);
}

This can also affect:

https://github.com/Cyfrin/2024-07-templegold/blob/57a3e597e9199f9e9e0c26aab2123332eb19cc28/protocol/contracts/templegold/TempleGoldStaking.sol#L95

function setVestingPeriod(uint32 _period) external override onlyElevatedAccess {
if (_period < WEEK_LENGTH) { revert CommonEventsAndErrors.InvalidParam(); }
// only change after reward epoch ends
> if (rewardData.periodFinish >= block.timestamp) { revert InvalidOperation(); }
vestingPeriod = _period;
emit VestingPeriodSet(_period);
}

because of the check rewardData.periodFinish >= block.timestamp

The likelyhood is LOW & Severity is MEDIUM because there's some level of disruption to the protocol's availability

hence the severity is Low

Tools Used

Manual Review

Recommendations

Implement an upper limit for the rewardDuration . This limit should take into account the typical amount of TempleGold minted daily, ensuring that reward intervals remain practical. Given that the expected reward amount is typically 20% of the Temple Gold minted from _distributeGold, thus the maximum possible minting could be up to 200 million tokens (though this is unlikely), the reward duration upper bound should reasonably depend on the tokens minted daily to ensure timely distributions.

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.