The function calls an internal helper (_swapTokenToLP) that, in turn, makes several external calls (for example, calling functions on the router such as addLiquidity and swap functions). None of these functions are protected by a reentrancy guard. The code does not include a nonReentrant modifier or any similar reentrancy protection. External calls occur after transferring tokens and before the final state check (require(amountOfLp >= minAmountOfLp, "lp amount too small")). If one of these external calls were to call back into the contract (via a malicious token or a compromised router), the attacker might be able to manipulate intermediate state before the function completes its execution.

Fee-on-transfer or deflationary tokens deduct a fee during every transfer. In the context of the zapInToken function, the contract expects to receive the exact amount specified by the user. However, with such tokens, the actual amount received can be less than expected due to the fee deduction. This discrepancy can lead to incorrect swap calculations and liquidity provision, potentially causing the transaction to revert or resulting in fewer LP tokens than anticipated. Check the contract’s token balance before and after the transfer to confirm the actual amount received. Modify the swap and liquidity logic to account for the net amount received post-fee. Moreover, Prefer using tokens without fee-on-transfer behavior or implement specialized handling for tokens that do deduct fees.

The estimation assumes that the full amount is available for swapping. However, if _in is a fee-on-transfer token, the actual amount received may be less than amount, resulting in an inaccurate estimation. The function uses sellAmount directly for estimation. Fee deductions on transfer mean the effective amount swapped could be lower, which isn’t accounted for. To mitigate this, The estimation logic should verify the actual balance change after transfers or adjust for fee deductions to provide a more accurate estimate.