THE FIRST AMM STAKER MAY NOT RECEIVE ACCORDING REWARDS BECAUSE OF POOR CHECKPOINTS #111
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
disagree with severity
Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments)
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Lines of code
https://github.com/code-423n4/2022-05-backd/blob/2a5664d35cde5b036074edef3c1369b984d10010/protocol/contracts/tokenomics/AmmGauge.sol#L56
https://github.com/code-423n4/2022-05-backd/blob/2a5664d35cde5b036074edef3c1369b984d10010/protocol/contracts/tokenomics/AmmGauge.sol#L140
Vulnerability details
Impact
The first staker within the
AmmGauge
may not get the rewards if the pool is not checkpointed right after he stakes and before he wants to claim the rewards.Proof of Concept
A testing environment that reproduces how the protocol is going to be deployed and managed is used to evaluate this case under the following assumptions and simplifications.
0.001
)._executeInflationRateUpdate
call. Not while staking.In order to illustrate this scenario we will show both the vulnerable and non vulnerable situations.
Vulnerable Situation:
Non Vulnerable Situation:
_poolCheckpoint()
between Alice stake call and Bobs' and before checking the accumulated rewards.The code to show this has a
secureCheckpoints
toggle that can be set as true or false to trigger (or not) the intermediate poolCheckpoints.The outputs for both cases are shown on the following chart. The initial staking amount is 10eth amount of the DummyERC20 token.
Recommended Mitigation Steps
The text was updated successfully, but these errors were encountered: