-
Notifications
You must be signed in to change notification settings - Fork 157
fix: ensure getRewards and takeRewards return 0 for closed allos (L-11) #1149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: horizon-oz2/l10-unsafe-encoding
Are you sure you want to change the base?
fix: ensure getRewards and takeRewards return 0 for closed allos (L-11) #1149
Conversation
fix: ensure getRewards and takeRewards return 0 for closed allos (L-11)
🚨 Report Summary
For more details view the full report in OpenZeppelin Code Inspector |
0d9825c
to
d6783a9
Compare
caa7fa9
to
93a3838
Compare
d6783a9
to
34a771c
Compare
93a3838
to
9fdcf37
Compare
@@ -836,6 +843,9 @@ abstract contract Staking is StakingV4Storage, GraphUpgradeable, IStakingBase, M | |||
); | |||
} | |||
|
|||
// Close the allocation | |||
__allocations[_allocationID].closedAtEpoch = alloc.closedAtEpoch; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The scary thing here is it breaks the checks-effects-interactions pattern... I don't see any reentrancy vectors, as I don't think we do any calls to untrusted addresses in this flow, but it's worth double checking, or reconsidering if it might not be better to make getRewards return 0 but takeRewards work as before
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, I noted this in the PR comment but perhaps worth doing the same in the code. I don't think there is reentrancy risk, but we can have OZ comment on which alternative they prefer, wdyt?
34a771c
to
8808257
Compare
9fdcf37
to
a76885d
Compare
6811eb0
to
dbc4f37
Compare
568a714
to
7db0ae7
Compare
dbc4f37
to
c2a753d
Compare
…L-11) Signed-off-by: Tomás Migone <tomas@edgeandnode.com>
Signed-off-by: Tomás Migone <tomas@edgeandnode.com>
7db0ae7
to
e053527
Compare
Tricky bit in
HorizonStakingExtension.sol
is moving theclosedAtEpoch
storage update after theRewardsManager
internal calls, here: https://github.com/graphprotocol/contracts/pull/1149/files#diff-f0ca33d417ab44fd34813873b594fcfb2dcb852a3bf77c8c3b8ccb88130d9797R378-R380