Root + Impact

H-1 Improper handling of fee units during initialization cause overcharging users or making the fee logic ineffective

Description

In the constructor of the contract:

The variable _buyFee is expected to be passed in its base form (e.g., 3 for 3%) by the deployer. However, multiplying this directly with PRECISION Without clearly documenting or validating the expected format, results in ambiguity and potential miscalculation.

Assumptions:

• If PRECISION = 1e18, then 3 * 1e18 = 3e18, which implies a 300% fee, not 3%.

• If s_buyFee is used later in calculations like:

Then it's expected that _buyFee should be something like 0.03e18 for 3%, not 3.

Due to this inconsistency, fees may:

• Be applied at 100x the intended value, draining users.

• Be too low or zero if someone assumes they must input a value like 300 to represent 3%.

Risk

Likelihood:

• Misunderstanding precision or units is a common developer error.

Impact:

• Can severely overcharge users, leading to loss of funds.

  
  

Proof of Concept

Thus, users would pay more in fees than the actual transaction amount, which is clearly unintended.

Recommended Mitigation

Clarify and enforce the expected fee format:

• If s_buyFee uses 18-decimal precision (e.g., 0.03e18 for 3%), then require deployers to input that exact format.