Precision Error when calculating the penalty for not locking the reward

[code423n4]

Lines of code

https://github.com/code-423n4/2022-05-aura/blob/4989a2077546a5394e3650bf3c224669a0f7e690/contracts/AuraBalRewardPool.sol#L176-L190

Vulnerability details

The penalty calculation, when a user does not lock his reward, encounters precision loss when reward cannot be completely divisible. This could lower the amount of penalty that the protocal expects to receive. The severity of the issue increases when a user getReward when his reward is small. And if a bulf of users decide to do the same thing, the protocal could potentially miss a huge penalty.

proof of concept

-A user getReward when his reward is at around 99
-The penalty will be 198/10 or 19.8 but, since there is no float point in solidity, the penalty will be rounded down to 19
-The penalty's percentage will be at around 19.1% instead of 20% as stated

mitigation

Since the severity will decline as accumulated reward goes up, it would be best to set the minimum reward that a user must first accumulates before getReward

[0xMaharishi]

1 base unit (i.e. 0.00000000000000001 of a token) is an acceptable rounding error

[dmvt]

I'm lowering this to QA. It is technically true, but the loss is insignificant.