Slashed staking positions can still claim rewards #117
Labels
bug
Something isn't working
downgraded by judge
Judge downgraded the risk level of this issue
duplicate-262
edited-by-warden
grade-c
QA (Quality Assurance)
Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax
sufficient quality report
This report is of sufficient quality
unsatisfactory
does not satisfy C4 submission criteria; not eligible for awards
Lines of code
https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/main/src/loan/SurplusGuildMinter.sol#L216-L290
Vulnerability details
Impact
A user can stake his Credit tokens in SGM, and SGM goes ahead and mints Guild tokens and adds weight to a Gauge that the user chooses. If that Gauge gains profit the user who staked his tokens can claim rewards in the Credit token, in case of loss, the staking position is slashed, i.e. deleted, and the user loses all his stakings. Both the slashing and rewards claiming happen in the same function,
getRewards
. So in theory if a Guage that a user weighted in lost a certain amount then profited some amount, the user should be slashed and he shouldn't get any rewards from that position.However, if that happens and
getRewards
isn't called between the loss and the profit, that user can claim undeserved rewards, where he should've lost everything in that staking position.Even though
getRewards
can be called permissionless, i.e. anyone or a bot can call it, however, the protocol shouldn't depend on something like "if the function was anonymously called on time", this case should be handled explicitly.Proof of Concept
The following test shows the current behavior, where a user claims rewards after being supposedly slashed.
The following test shows the normal scenario where
getRewards
is called between loss and profit, the user lost everything and didn't get any rewards.Tools Used
Manual review + vscode
Recommended Mitigation Steps
The protocol should check if a user is slashed before transferring the rewards. However, this introduces another issue, that is the reverse, if a Gauge profited then lost, the user should still be able to claim the promised rewards, ...
Assessed type
Invalid Validation
The text was updated successfully, but these errors were encountered: