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
Upgrade to use uniswap universal router instead of uniswap swap router for swaps.
Motivation
The current swap adapter is affected by 2 bugs: 1) unwrapETH method clashing between swap router and npm contracts and 2) bypass of token whitelist on multi-hop swaps, plus preventing a swap to a whitelisted token when the first pool involves a non-whitelisted token. These fixes require an upgrade of the Uniswap adapter, but since Uniswap has released a universal adapter, it is desirable to use the universal swap router, which simplifies the process of approving swap methods.
Specification
A new Uniswap universal router adapter should be written and deployed. It will support ERC20 tokens only initially. Technically, we want to see if we can use the current uniswap adapter for npm methods, but since the unwrap method calls the uniswap swap router, it will still be affected by the inability to unwrap eth when withdrawing liquidity. In this context, we want to identify whether it is desirable to keep the swap router adapter and the npm adapter separate, but we clearly need to assert that method selectors do not clash.
Summary
Upgrade to use uniswap universal router instead of uniswap swap router for swaps.
Motivation
The current swap adapter is affected by 2 bugs: 1) unwrapETH method clashing between swap router and npm contracts and 2) bypass of token whitelist on multi-hop swaps, plus preventing a swap to a whitelisted token when the first pool involves a non-whitelisted token. These fixes require an upgrade of the Uniswap adapter, but since Uniswap has released a universal adapter, it is desirable to use the universal swap router, which simplifies the process of approving swap methods.
Specification
A new Uniswap universal router adapter should be written and deployed. It will support ERC20 tokens only initially. Technically, we want to see if we can use the current uniswap adapter for npm methods, but since the unwrap method calls the uniswap swap router, it will still be affected by the inability to unwrap eth when withdrawing liquidity. In this context, we want to identify whether it is desirable to keep the swap router adapter and the npm adapter separate, but we clearly need to assert that method selectors do not clash.
Notes
RigoBlock/v3-contracts#307
The text was updated successfully, but these errors were encountered: