Open hats-bug-reporter[bot] opened 1 week ago
It's true that a single, precise calculation might be more accurate, but our current implementation is more readable and has practical accuracy. We defined a uint256 internal constant MIN_MINT_FEE = 1_000_000
, considering anything below this as dust. The difference between a more precise solution and our current readable code is negligible, only affecting the dust value. Therefore, we believe no changes are required.
Github username: -- Twitter username: rnemes4 Submission hash (on-chain): 0xcae1fd8054e74e1235a2a97fca61254f2c15306448f84b46c0593e0136ff6a79 Severity: medium
Description: Description\
_calculateMintAmountForStreamingFees
is susceptable to precision loss errors when calculatingtokensToMint
due to instances of dividing before m,ultiplication over multiple functions. The first precision loss comes from the_calculateStreamingFee
where the following calculation is made:the loss is then compounded by multiplying the result
streamingFees
byONE_ETH_IN_WEI
on the following line:finaly the
feeReceiverShare
is multipliplied again_userShare
in:All three functions are listed below for clarity of the call sequence.
File: contracts/fee/FeeCalculations.sol
File: contracts/fee/FeeCalculations.sol
File: contracts/core/calculations/TokenCalculations.sol
Attack Scenario\ The following foundry Fuzzing test was used to highlight this precision loss wherby the
tokensToMint
was calulated using the current functions and then compared to a more precise method wherby the as many divisions before multiplications were removed by rearranging the equations into the following form:Attachments
Output
It is recommended to reduce the precision loss by using the following function to calculate
tokensToMint