You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently it's complicated to join or withdraw a pool at the right moment, unless user is using a smart contract wallet with custom logic.
To facilitate and reduce gas costs, add a secondary function which allows the swap ("correction of price") + deposit in pool, so the uniswap interface can be extended to allow user to correct the price of the pool to then deposit on the pool.
This procedure is even is even a requirement in the docs: When other liquidity providers add to an existing pool, they must deposit pair tokens proportional to the current price.
If the docs themselves suggest this, then the contract could and should allow this to happen in a single call.
Users without smart contract wallets with custom code, cannot safely do this, because they are in risk of being front-runned while doing this two transaction operation, so is important that the contact provide this common use.
As a workaround for current pools contracts and router, a secondary contract, common to any pool, could do the two calls from one call, and the uni-swap interface can start using it.
Currently it's complicated to join or withdraw a pool at the right moment, unless user is using a smart contract wallet with custom logic.
To facilitate and reduce gas costs, add a secondary function which allows the swap ("correction of price") + deposit in pool, so the uniswap interface can be extended to allow user to correct the price of the pool to then deposit on the pool.
This procedure is even is even a requirement in the docs:
When other liquidity providers add to an existing pool, they must deposit pair tokens proportional to the current price.
If the docs themselves suggest this, then the contract could and should allow this to happen in a single call.
Users without smart contract wallets with custom code, cannot safely do this, because they are in risk of being front-runned while doing this two transaction operation, so is important that the contact provide this common use.
As a workaround for current pools contracts and router, a secondary contract, common to any pool, could do the two calls from one call, and the uni-swap interface can start using it.
See this discussion from last year, on reddit: https://www.reddit.com/r/UniSwap/comments/bf1g9q/how_to_mitigate_impermanent_loss/.
The text was updated successfully, but these errors were encountered: