Core Contracts

Summary

Low precision used for fee/burn fee may prevent the admin from setting the fee values to the desired level.
As a result, users may have to pay a fee even when the protocol doesn't intend to tax its users.
Additionally, the protocol may lose revenue due to the inability to raise the fee.

Vulnerability Details

RaacTokne implements 2 types of fees swap/tranfer fee and burn fee.
These fees are updated using _setTaxRate function.
The fees are expressed in BPS: uint256 public constant MAX_TAX_RATE = 1000; // 10%

The percentMul rounds UP if a value is >=0.5, otherwise will round down.

It is equivalent to
(value * percent + 5000) / 10_000.

The fee can be increased / decreased by 10% of its previous fee value. (taxRateIncrementLimit can't be set higher than 1000bps).
This means that, if the current fee is 500pbs it can be decreased to 450BPS then 405, etc.

When the fee reached 4bps it can't be decreased further because percentMul(4, 1000) returns 0, disallowing the fee rate to be set to 0.
This is problematic when the admin wants to remove one fee but keep the other.
Moreover, once the fee is 4bps, it can't be increased either for the same reason: the maximum allowed change is 0.

Impact

If the protocol want to disable one of the fee and keep the other, it can't. The minimum fee is 4bps.

If one of the fees is 4bps, it can be increased at a later date.

Tools Used

Recommendations

Consider using a higher precision for tax rates. eg. 1e18 for 100%.

Once the fee is lower than a predefined value (eg. 0.1%), allow setting the fee to 0. This is required to avoid calling _setTaxRate many times in order to set the fee to 0.