Lines of code
<https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L265&gt;
<https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L327&gt;

Vulnerability details

Impact

When a user creates a pledge, (s)he can specify the maximum amount of the Total Rewards and the maximum amount of fee amount (s)he is willing to spend.
By using the rewardPerVote, the vars.votesDifference and the vars.duration the smart contract calculates both the totalRewardAmount and the feeAmount. However, due to the fact that the denominator is 1e18, which in the calculation represents the decimals of the rewards tokens, the result will be wrong when the reward tokens decimals’ are not 18.
So, by using a reward token that doesn’t has 18 decimals the internal accounting of the smart contract will be wrong in multiple places, including in the _pledge, the createPledge, the extendPledge and the increasePledgeRewardPerVote functions.

Proof of Concept

• A user creates a pledge by calling the createPledge function with a reward token that doesn’t have 18 decimals
• The internal accounting of the totalRewardAmount and the feeAmount will be wrong
• Because the above calculation is wrong, the reward calculation will be higher than maxTotalRewardAmount and so he spends more tokens than he wanted

Tools Used

Manual Code Review

Recommended Mitigation Steps

It is recommended to replace all the UNIT occurrences with the IERC(rewardToken).decimals().

The text was updated successfully, but these errors were encountered:

All reactions