-
Notifications
You must be signed in to change notification settings - Fork 620
fixed issue with example #944
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The fee charging example was incorrect because it was charging the fee in currency0 when swap zeroForOne, while it should take into account the amountSpecified together with zeroForOne to determine the specifiedAmount thus feeAmount is in currency0 or currency1, thus should charge the corresponding currency to the user.
@fasteater is attempting to deploy a commit to the Uniswap Team on Vercel. A member of the Team first needs to authorize it. |
We need clarity as soon as possible since we are using the original example. If it is incorrect, we must know before going to the mainnet. 🙏 |
Hey I have validated this issue in the uniswap discord channel, I am sure this is a problem and I think it's important to fix this asap because I know some devs are using this example in live project.
|
I will contact the Uniswap team in X to speed up the response. |
From @georgeciubotaru the flag zeroForOne is for explicitly say which is the token input that will be taken by the Uniswap pool to pay for the swap.
so amountSpecified > 0 means I want x token1 take y of token0 using conversion so no matter of the value of amountSpecified the token will be taken for paying the swap is based on the zeroForOne flag. |
@lwtsn I dont think this is correct, as per your comment
So depending on amountSpecified being neg or positive, the value means differrent token type. Thus the fee based on this value is also in different token type.
I believe this is a different pattern from normal uniswap fees which is always charged in token0. In case of |
@georgeciubotaru could you please follow up /w @fasteater |
Is not the high-level logic the following?: Given: Token A and Token B If you want to spend exact amount (exactIn) of token A, then you will get in exchange the amount of B where B_amount=getAmount(exactIn) and where getAmount takes care of conversion rate and fee which is paid in token A. If you want to receive exact amount of B (exactOut), then you will need to exchange the amount of A where A_amount=getAmount(exactOut) and where getAmount take care of the conversion rate and fee which is paid in token A. If the above is correct understanding of the swap logic, then the current documentation example is correct, so is the @georgeciubotaru |
Sorry, my previous comment went wrong. I believe @zolotokrylin and @georgeciubotaru are correct. In Uniswap, fees should be based on the input token, which is determined by the zeroForOne flag. @fasteater — I think you're using amountSpecified to determine the fee token directly, which seems to be a misunderstanding. The amountSpecified parameter is used to determine whether it’s an exact input or exact output swap, but not which token the fee is paid in. |
@fasteater could you please weigh in - we are confident that the existing solution in the docs is correct. Please let me know your thoughts |
make the change more efficient, logic remains the same.
I am confident this issue is legit, I have also found evidence in the V4 core tests which does the same thing as I proposed here. When determine specifiedCurrency, it takes into account both ZeroForOne and specifiedAmount, we need both of these, not just one as in the example. I have also updated the proposed fix to be more efficient, but the logic remains the same. And I have further looked into the issue and I can confirm the proposed changes is sufficient to deal with the fees here, we do not need afterSwapHook at all. This update fully fixes the issue, should be merged asap. Also let me try to clear any confusion here
|
The fee charging example was incorrect because it was charging the fee in currency0 when swap zeroForOne, while it should take into account the amountSpecified together with zeroForOne to determine the specifiedAmount thus feeAmount is in currency0 or currency1, then it should charge the corresponding currency to the user.