Fix to ExampleCombinedSwapAddRemoveLiquidity.sol: using MAX_UINT approvals with the router #38
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…that don't support changing a non-zero approval
moodysalem
reviewed
Jul 22, 2020
| // grants unlimited approval for a token to the router unless the existing allowance is high enough | ||
| function approveRouter(address _token, uint256 _amount) internal { | ||
| if (IERC20(_token).allowance(address(this), address(router)) < _amount) { | ||
| TransferHelper.safeApprove(_token, address(router), uint256(-1)); |
There was a problem hiding this comment.
don't we have to approve(0) first?
There was a problem hiding this comment.
Yes, indeed. I had assumed that tokens that forbid calling approve() with a non-zero amount when the existing allowance is non-zero would skip the allowance update in transferFrom() when the allowance is MAX_UINT (as is the case for USDT) but thinking about this more, I see no reason to make this assumption. Will fix.
…owance has shrank to less than the required amount
moodysalem
reviewed
Jul 23, 2020
| @@ -53,7 +53,7 @@ describe('ExampleCombinedSwapAddRemoveLiquidity', () => { | |||
| await wethPair.mint(wallet.address, overrides) | |||
| } | |||
|
|
|||
| beforeEach(async function() { | |||
| beforeEach(async function () { | |||
There was a problem hiding this comment.
prob causing a linter issue
moodysalem
approved these changes
Jul 23, 2020
|
code change lgtm, i don't see any way this could cause a security issue, could use a test but this is use-at-your-own-risk code, happy to merge this once you fix the linter error so the tests pass |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
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.
This PR resolves this issue by approving the router to transfer MAX_UINT tokens from ExampleCombinedSwapAddRemoveLiquidity.