Open code423n4 opened 1 year ago
0xScotch marked the issue as sponsor disputed
I don't agree 0 is the natural thing to return in this case. You are requesting the average APR for a period of time. When startEpoch == endEpoch
returning the APR for that epoch feels natural to me.
Regardless then seems like a stylistic choice more than a vulnerability. So unless there is a specific security concern for this behaviour I would say this isn't a valid finding.
Downgrading to low in the absence of impact description.
Picodes changed the severity to QA (Quality Assurance)
Picodes marked the issue as grade-a
Lines of code
https://github.com/code-423n4/2023-02-malt/blob/main/contracts/RewardSystem/RewardThrottle.sol#L225-L227 https://github.com/code-423n4/2023-02-malt/blob/main/contracts/RewardSystem/RewardThrottle.sol#L252-L254
Vulnerability details
Impact
averageCashflowAPR
returns meaningless value whenstartEpoch
=endEpoch
.Proof of Concept
There are two
averageCashflowAPR
functions inRewardThrottle.sol
and they returnsepochCashflowAPR(endEpoch)
whenstartEpoch
==endEpoch
.In the both of implementations,
apr = (endEpochState.cumulativeCashflowApr - startEpochState.cumulativeCashflowApr) / averagePeriod
.And
state[i + 1].cumulativeCashflowApr = state[i].cumulativeCashflowApr + epochCashflowAPR(i)
for any epoch i.apr
is the average ofepochCashflowAPR
s for (startEpoch
,startEpoch + 1
, ... ,endEpoch - 1
). WhenendEpoch
>startEpoch
, all things are good, but whenendEpoch
==startEpoch
, there's nothing to average, so it's natural to return 0 instead ofepochCashflowAPR(endEpoch)
.Inside of
RewardThrottle.sol
,endEpoch
will always be greater thanstartEpoch
becausesmoothingPeriod
> 0. L139L40
L698-L704
So this only affects when it is called from outside. So the impact reduced, but it's still a problem.
Tools Used
Manual Review
Recommended Mitigation Steps
Return
0
instead ofepochCashflowAPR(endEpoch)
whenstartEpoch
=endEpoch
.