The issue highlighted how reward logic can get broken because virtual rewards were recorded as uint128 breaking the invariant
"The ratio of virtualRewards/increaseShareAmount is the same as totalRewards/totalShares for the pool."
their actual value could be much higher than could be stored as a uint128.
Hence users can claim more rewards than they should because on claiming the deducted virtual rewards will be smaller than it would have been had it not been stored as uin256.
Lines of code
Vulnerability details
Lines of code
Vulnerability details
C4 Issue
https://github.com/code-423n4/2024-01-salty-findings/issues/341
Comments
The issue highlighted how reward logic can get broken because virtual rewards were recorded as uint128 breaking the invariant
"The ratio of virtualRewards/increaseShareAmount is the same as totalRewards/totalShares for the pool."
their actual value could be much higher than could be stored as a uint128.
Hence users can claim more rewards than they should because on claiming the deducted virtual rewards will be smaller than it would have been had it not been stored as uin256.
Mitigation
https://github.com/othernet-global/salty-io/commit/5f79dc4f0db978202ab7da464b09bf08374ec618
The final mitigation for this was to store virtual rewards as uin256 to avoid breaking the invariant.
Tests
Tests were added and they pass
Conclusion
LGTM