When talking about UniswapV2’s router, mostwill 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.
100e18 TAX Token
100e18 USDC
Upon the addLiquidity function, the_addLiquidity function is invoked which calculates the optimal amounts based onthe current pair ratio. It will first calculate amountB based on the pair ratioand amountA and if that does not satisfy the conditions, it will calculateamountA based on amountB and the pair ratio:
The problem: It assumes that in fact 100e18of the TAX Token are being transferred in. If for example the pair has1_000_000e18 TAX Token and 1_000_000e18 USDC, the amounts will be exactly asprovided: 100e18 TAX Token and 100e18 USDC.
Now both amounts are transferred to thepair and the mint function is invoked, which then calculates the to be mintedliquidity. The trick hereby is that it uses the lower of both products, whichin our scenario should be exactly equal:
However, if the balance of the LP pair isonly increased by 90e18 due to the tax, then it will use the lower of bothbalances to calculate the liquidity and it will effectively only add 90e18 TAXToken and 90e18 USDC to the pair. The other 10e18 USDC are donated to the pair.
In reverse, this means if you already knowthe pair will only receive 90e18 TAX Token, it is sufficient to provide only90e18 USDC and you still will get the full liquidity amount.
