UniswapV2’s inability to properly handle transfer-tax tokens upon addLiquidity

When talking about UniswapV2’s router, most will assume that the router is transfer-tax compatible, due to the _swapSupportingFeeOnTransferTokens function.

This is however only partially correct, because the liquidity addition is not transfer-tax supportive.

What does that mean?

Assume you add the following tokens:

100e18 TAX Token

100e18 USDC

Upon the addLiquidity function, the _addLiquidity function is invoked which calculates the optimal amounts based on the current pair ratio. It will first calculate amountB based on the pair ratio and amountA and if that does not satisfy the conditions, it will calculate amountA based on amountB and the pair ratio:

The problem: It assumes that in fact 100e18 of the TAX Token are being transferred in. If for example the pair has 1_000_000e18 TAX Token and 1_000_000e18 USDC, the amounts will be exactly as provided: 100e18 TAX Token and 100e18 USDC.

Now both amounts are transferred to the pair and the mint function is invoked, which then calculates the to be minted liquidity. The trick hereby is that it uses the lower of both products, which in our scenario should be exactly equal:

However, if the balance of the LP pair is only increased by 90e18 due to the tax, then it will use the lower of both balances to calculate the liquidity and it will effectively only add 90e18 TAX Token and 90e18 USDC to the pair. The other 10e18 USDC are donated to the pair.

In reverse, this means if you already know the pair will only receive 90e18 TAX Token, it is sufficient to provide only 90e18 USDC and you still will get the full liquidity amount.

Link to the article