Skip to content
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

Amounts order in remove_liquidity #18

Closed
bogdan-manole opened this issue Dec 13, 2021 · 0 comments
Closed

Amounts order in remove_liquidity #18

bogdan-manole opened this issue Dec 13, 2021 · 0 comments

Comments

@bogdan-manole
Copy link
Contributor

bogdan-manole commented Dec 13, 2021

!!! they come back sorted, so we can't assume the order here

Originally posted by @thepiwo in #10 (comment)

@thepiwo thepiwo 11 days ago
!!! they come back sorted, so we can't assume the order here

@thepiwo thepiwo 11 days ago
maybe we should return records that indicate we operate on SORTED or UNSORTED token/amount

Author
@bogdan-manole bogdan-manole 6 days ago •
edited
they don't come back sorted. In the Router, all the entrypoints (as remove_liquidity is) will return the values in accordance/order with what the user specify as A and B in the parameters. So, if you have Router.entrypointX(tokenA,tokenB,amountA_min,amountB_min) => (amountA * amountB), the order of the returned tuple will remain as you specified in parameters. So, remove_liquidity(token,wae) will return (amount_token*amount_wae).

We should not specify if it is sorted or unsorted since always they come back sorted by the parameters order.

One might wonder the following questions:

why Pair is not doing the same sorting/unsorting with the token0 and token1 ?, at least three reasons:

Pair does not have any of the tokenA,tokenB in the parameters of it's entrypoints (for example burn,mint,etc) to be able to understand what an caller/user might refer to tokenA/tokenB
Pair does not have to deal with the sorting/unsorting since upper level contracts will do it for it, if it is the case.
From the point of view of the Pair there is just his state.token0 and state.token1, and the fact that token0.address < token1.address, is just a convention of the Factory not of the Pair constraints. In other words the Pair doesn't care if there will be other Pair with same tokens in reverse order or even the same as it's own, or even if token0.address > token1.address. It is Factory's business to ensure any constraints of pair/tokens uniqueness or order.
why the router is doing this?

the Router has to find the pair for the user, so every time he has the tokenA and tokenB is normal to match the values given by the pair to those provided by the user
the Router in the case of the multiple swaps might have [tokenA,tokenB,tokenC] in the form of a path of tokens and it should return the same order [amountA,amountB,amountC]

@thepiwo thepiwo 4 days ago
remove_liquidity is sorting token0, _, then amount_a will be the amount of previously sorted token0 in the if/else so I feel it is sorted and we can't know the order of (amount_token, amount_ae). Or do I missunderstand that somehow?

agree

all good explainations, agree

Author
@bogdan-manole bogdan-manole 1 hour ago
The amount_a will be the amount of token0 only if token_a == token_0, otherwise will be the amount of token1. Keeping this in mind we know that remove_liquidity will always return as first value in the tuple the value representing the first token provided in the parameter for remove_liquidity => remove_liquidity(tokenA,tokenB) will return (amountA,amountB). In our case tokenA == token and tokenB == state.wae_aex9. In other words the remove_liquidity_ae is just a special case when we don't have parameters for both tokenA and tokenB but just for the tokenA, tokenB being used as state.wae

@bogdan-manole bogdan-manole changed the title amounts order in remove_liquidity Amounts order in remove_liquidity Dec 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant