Thunder Loan

Summary

getCalculatedFee divides the borrowed value by the precision before multiplying by the fee rate. Integer truncation in the intermediate result discards value that could contribute to the final fee, so loans are systematically undercharged even when token and oracle decimals are otherwise correctly aligned.

Root cause and evidence

At ThunderLoan.sol:248-250:

valueOfBorrowedToken = (amount * price) / precision;

fee = (valueOfBorrowedToken * flashLoanFee) / precision;

The first division rounds down. Multiplying after that division cannot recover the discarded remainder. This is distinct from the token-decimal mismatch: it occurs within a valid common scale due solely to operation ordering.

Impact

LPs lose a small portion of fees on many loans, and boundary amounts can be charged less than the configured percentage.

Minimal patch

Use full-precision multiplication/division (for example OpenZeppelin Math.mulDiv) and defer division until the final step, with explicit rounding policy. Ensure intermediate multiplication cannot overflow.

Regression test

Fuzz amounts and prices around precision boundaries and compare the implementation with a high-precision reference formula. Assert the result does not lose an avoidable intermediate remainder.