Open code423n4 opened 2 years ago
This is true. Will fix. There are other implications of this elsewhere, but it's valid nonetheless.
Given the amount of refactoring due to various suggestions (unchecked math, gas savings, duplicate code isolation, distribution math edge cases, etc) it is difficult to isolate the changes made to satisfy this issue.
Nevertheless, it can be seen that the release candidate contract uses only unsigned math using uint256
types.
Namely, pointsCorrection
is now a uint256
, and the _withdrawableGiven
math is all unsigned.
Handle
TomFrenchBlockchain
Vulnerability details
Impact
Extra gas costs from unnecessary casting.
Proof of Concept
pointsCorrection
is stored as a int256 variable.https://github.com/XDeFi-tech/xdefi-distribution/blob/3856a42df295183b40c6eee89307308f196612fe/contracts/interfaces/IXDEFIDistribution.sol#L15
However we can see that this variable is always negative (
_pointsPerUnit
andunits
are both positive)https://github.com/XDeFi-tech/xdefi-distribution/blob/3856a42df295183b40c6eee89307308f196612fe/contracts/XDEFIDistribution.sol#L277
The only usage of
pointsCorrection
is in the_withdrawableGiven
function as shown below.https://github.com/XDeFi-tech/xdefi-distribution/blob/3856a42df295183b40c6eee89307308f196612fe/contracts/XDEFIDistribution.sol#L341-L342
pointsCorrection
is set to_pointsPerUnit * uint256(units_)
when locking and_pointsPerUnit
only increases so we can safely store `pointsCorrection as a positive uint256 (note this is an assumption of the original code as well) and simplify the above expression.We can then remove a significant amount of casting along with the associated costs.
Recommended Mitigation Steps
store
pointsCorrection
in a uint256 and subtract rather than add.