[AMM Pool] Rename variables and extract methods #1772
Merged
Conversation
This file contains hidden or 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
dong77
changed the title
|
It seems like uniswap does have very similar checks: https://github.com/Uniswap/uniswap-v2-periphery/blob/master/contracts/UniswapV2Router01.sol. So both uniswap and balancer check this (for a good reason I assume). I do think this doesn't matter a lot in most cases (I think it only really matters when the pool is small, otherwise it's just small potential slippage risks, but pools can be small so we have to make sure that scenario also works). |
Brechtpd
approved these changes
Sep 19, 2020
Brechtpd
added a commit
that referenced
this pull request
Sep 22, 2020
* [protocol 3.6] AMM pool testing * [protocol 3.6] More AMM pool testing * [protocol 3.6] Improved AMM pool + testing * [protocol 3.6] Small optimizations * [protocol 3.6] Misc improvements/fixes AMM pool * unify submitBlocksCompressedWithCallbacks (#1761) * unify submitBlocksCompressedWithCallbacks * unify submitBlocksCompressedWithCallbacks * Amm approve erc20 on setup (#1762) * approve upon setup * approve upon setup * allow withdraw all tokens (#1763) * make agent explicitly inherit IAgent (#1765) * [protocol 3.6] Small fixes * [protocol 3.6] uint96 safe math (#1766) * [AMM Pool] Rename variables and extract methods (#1772) * rename variables * extract methods * extract methods * [AMM Pool] Some small improvements (#1773) * add changes based on my questions * more Co-authored-by: wangdong <wangdong@zhongan.io> Co-authored-by: Brechtpd <Brechtp.Devos@gmail.com> * [AMM pool] Changed approvals + locking logic (#1771) * [protocol 3.6] Changed approvals + locking logic * [protocol 3.6] LP tokens * [protocol 3.6] Use minPoolAmountOut for joins * [protocol 3.6] AMM pool signature assisted L1 withdrawals + fixes * [protocol 3.6] Small improvements/fixes Co-authored-by: Daniel Wang <daniel@loopring.org> Co-authored-by: wangdong <wangdong@zhongan.io>
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.
@Brechtpd After working on this PR, I finally figured out how your design works :) I do have the following suggestions regarding the pool token's mint/burn logic:
Now we calculate the amount of tokens that will be accepted into the pool based on the Join's
poolAmountOutparameter. IfpoolAmountOutis large enough, this join will likely to fail; otherwise, if it is small enough, the user ends up with a smaller amount of pool tokens than he deserves. I suggest we calculate the amount of pool tokens assuming his join will be accepted, then compare the new pool tokens to mint to him with aminPoolTokenAmountparameter that the user provides. IfminPoolTokenAmountis smaller than or equal to the pool tokens to be minted, then this Join will be accepted, otherwise, the join will be rejected. By doing this, a user will feel really comfortable by providing a small value forminPoolTokenAmount, or even zero if he doesn't care about slippage.For exits, I suggest we only take one parameter - the amount of pool tokens the user would like to burn. Then calculate the amount of each token that will be released back to layer1 for withdrawal. There should be no slippage option for exits at all, as users collectively owns what's left in the pool anyway. I believe this is also the case with uniswap.