The getPeriodReward is inefficient when computing the reward when the decrease amount is 0.
getPeriodReward computes the reward as the sum of three integers, which represent the separate reward computation for the start interval, mid (full) intervals and end interval.
There is a lot of computation that is not needed for the constant reward amount, where the reward can simply be computed as (endTime - startTime) * initialAmount / interval
Moreover, this implementation also fixes the defect where function provides wrong rewards for edge cases (submitted as separate finding)
A quick test on remix shows an execution cost of ~33600 gas (original version) vs ~7800 gas (simplified version, provided below)
Remix
For the constant reward amount, use the following implementation:
Note: Sanity checks were kept (and simplified). New code is only the return line:
function getPeriodRewardConstantAmount(
uint256 initialAmount_,
uint128 payoutStart_,
uint128 interval_,
uint128 startTime_,
uint128 endTime_
) public returns (uint256) {
if (interval_ == 0) {
return 0;
}
// 'startTime_' can't be less than 'payoutStart_'
if (startTime_ < payoutStart_) {
startTime_ = payoutStart_;
}
uint128 maxEndTime_ = type(uint128).max;
if (endTime_ > maxEndTime_) {
endTime_ = maxEndTime_;
}
// Return 0 when calculation 'startTime_' is bigger then 'endTime_'...
if (startTime_ >= endTime_) {
return 0;
}
return ((endTime_ - startTime_) * initialAmount_) / interval_;
}
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.