Inaccurate Handling of Fee-on-Transfer Token Swaps Due to Slippage Tolerance Mismatch

Summary

The swapExactETHForTokensSupportingFeeOnTransferTokens function in the JalaRouter02 contract is designed to swap ETH for ERC20 tokens implementing a fee-on-transfer mechanism. The handling of such tokens poses unique challenges due to the fees deducted during the transfer process. These challenges can lead to discrepancies between the expected and actual outcomes of swaps, particularly in how the function manages the impact of transfer fees on the final amount received by the user.

Vulnerability Detail

When executing swaps with fee-on-transfer tokens, the transaction involves the deduction of a certain percentage of the tokens as a fee during each transfer. This deduction occurs automatically and is a characteristic feature of fee-on-transfer tokens, intended to support various mechanisms like redistribution to existing holders, liquidity pool contributions, or burning to reduce total supply.

Impact

The function calculates the expected output without accounting for the loss incurred due to transfer fees. It essentially assumes a direct conversion based on the input amount and the prevailing exchange rate within the liquidity pool.

Since a portion of the tokens is deducted as a fee during the swap, the actual amount of tokens received by the user amountOut can be significantly lower than both the amountOutMin specified by the user and the initially calculated output based on liquidity pool ratios. This discrepancy arises because the fee deduction effectively reduces the amount of tokens that are actually swapped within the liquidity pool, leading to a lower final output.
Users typically specify a amountOutMin to manage slippage—the difference between the expected and actual swap rates due to price movements or liquidity variations. For fee-on-transfer tokens, the automatic fee deduction exacerbates this slippage, as the actual receivable amount post-fee can fall below the user’s tolerance threshold, potentially leading to failed transactions or outcomes that are not aligned with user expectations.

Code Snippet

https://github.com/sherlock-audit/2024-02-jala-swap/blob/main/jalaswap-dex-contract/contracts/JalaRouter02.sol#L390C5-L390C64

uint256 amountIn = msg.value;
        IWETH(WETH).deposit{value: amountIn}();
        assert(IWETH(WETH).transfer(JalaLibrary.pairFor(factory, path[0], path[1]), amountIn));
        uint256 balanceBefore = IERC20(path[path.length - 1]).balanceOf(to);
        _swapSupportingFeeOnTransferTokens(path, to);
        if (IERC20(path[path.length - 1]).balanceOf(to) - balanceBefore < amountOutMin)
            revert JalaLibrary.InsufficientOutputAmount();

Tool used

Manual Review

Recommendation

Allow for dynamic adjustment of slippage settings specifically for swaps involving fee-on-transfer tokens. This adjustment would account for the expected fee deductions and provide a more accurate reflection of the user's slippage tolerance.

sherlock-audit / 2024-02-jala-swap-judging

cheatcode - Inaccurate Handling of Fee-on-Transfer Token Swaps Due to Slippage Tolerance Mismatch #236