I realize this could be a lot more gas efficient, either by going to the pair directly or using the router ETH methods, but this unoptimized version works for now

Some tokens like USDT do not allow approving an amount M > 0 when an existing amount N > 0 is already approved. This is to protect from an ERC20 attack vector described here https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit#heading=h.b32yfk54vyg9.

We are encountering some issues adding/removing liquidity with ExampleCombinedSwapAddRemoveLiquidity using such tokens. ExampleCombinedSwapAddRemoveLiquidity approves UniswapV2Router to pull some tokens from itself but UniswapV2Router does not always use its full allowance and sometimes leaves some residual allowance after the transaction. As a result, the next time ExampleCombinedSwapAddRemoveLiquidity tries to approve UniswapV2Router, the residual allowance makes the approval fail for tokens such as USDT.

A simple fix would probably be to just clear any residual allowance at the end of a call.

cc @elenadimitrova

Any progress on the above issue reported? It is blocking a lot of transactions atm and there's also the KNC token suffering the same symptoms on token.approve as USDT.

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.