[Loopring 3.6] Demo AMM pool #1737
Conversation
# Conflicts: # packages/loopring_v3/contracts/core/impl/libtransactions/TransferTransaction.sol # packages/loopring_v3/test/testExchangeUtil.ts
packages/loopring_v3/contracts/core/impl/libtransactions/WithdrawTransaction.sol
Show resolved
Hide resolved
|
One thing to keep in mind if we would allow changing the weights is that we shouldn't do so just based on what LPs deposit. If previous liquidity LPs were okay with a 50/50 pool that does not mean they are fine with being in a pool that is suddenly a 90/10 pool (which changes the risks completely) just because some LPs only want to deposit one of the tokens. If an LP only wants to provide a single token they could do so, but the weights should remain the same (like balancer does), unless a more advanced curve is just probably using oracles. Another thing is I think that we should really try to just use signature based joins/exits instead of needing Ethereum transactions by users (cheap and flexible). One of the difficulties here is with layer 1 balances and locking those. Currently this works kind of okay, but I think things can be made simpler when we by default lock all tokens up in the contract, and people need to unlock them (so the inverse what I do now for the amounts being deposited, having them unlocked by default and only locking them when they will be used). The other possibility here is that we only support joins from layer 2 + default locked behaviour of the liquidity tokens on layer 1 so they can be withdrawn only when specifically unlocked with some delay or with the help of a signature of the operator. |
|
Brecht, it will be ideal if the operator of the exchange can choose to skip some Join/Exit requests to avoid being Sybil attacked. |
|
Is the reason for introducing What's the worst thing that may happen if we remove the two parameters and calculate the number of liquidity tokens to mint/burn automatically? |
|
Update: Basically we want to make the AmmPool contract getting closer to what we desire for production. The feedback from the relayer team is that they prefer using a map instead of a queue for the join/exit requests, such that the operator of the exchange can choose which join/exit requests to process and in which order. |
Joins we can skip, but on-chain exit requests will all need to be processed to make sure people can exit the pool, same as with forced withdrawals on the exchange. Offchain requests > onchain requests in all normal cases though, so hopefully these onchain requests will rarely be used.
Especially for withdrawing is makes a lot of sense to just let users specify how many of their liquidity tokens they want to redeem back to tokens. Otherwise we/they have to approximate how many tokens need to be withdrawn to burn the required amount of liquidity tokens, it would be almost impossible for people to burn all their liquidity tokens like that. For joins I think not specifying it would be okay (maybe even better in some cases when the pool is small and amounts being deposited), still some other safety checks need though I think.
I think only some additional slippage losses when the pool is in an unbalanced state or is brought into an unbalanced state. But I think if we do things differently than uniswap/balancer we should have very good reasons to do so, seems needlessly risky otherwise.
Offchain requests > onchain requests, I don't want us to actually use these onchain requests. :) To support this we'll have to switch to lock all users funds by default. So do we want to handle this in the pool contract or do we just deposit funds directly to the exchange so we don't have to worry about that? This way we only need to really support joins from layer 2. Though for the liquidity tokens themselves, if we always want to keep them on L1, we'd still have to have some locking mechanism in the pool as well. |
* unify submitBlocksCompressedWithCallbacks * unify submitBlocksCompressedWithCallbacks
* approve upon setup * approve upon setup
* rename variables * extract methods * extract methods
* add changes based on my questions * more Co-authored-by: wangdong <wangdong@zhongan.io> Co-authored-by: Brechtpd <Brechtp.Devos@gmail.com>
* [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
Uh oh!
There was an error while loading. Please reload this page.