[GIP-38]: Updating Uniswap V2/V3 adapters to prevent paths through arbitrary tokens

Overview

This GIP aims to improve the security of the protocol by disallowing arbitrary tokens in Uniswap V2/V3 paths and limiting the maximal path length to 3 hops.

Problem statement

Currently, UniswapV2Adapter and UniswapV3Adapter only check that the input and output tokens in a swap are allowed tokens, without performing any sanity checks on intermediate tokens.

This leads to an ability to set up an intermediary pool with custom tokens and use it to call untrusted code during a swap. Normally, this does not pose an issue, due to health checks being performed after any swap. However, in certain rare circumstances and with additional techniques there is a potential of bad debt being created.

Proposed changes

The UniswapV2/V3 adapters will be updated to new implementations:

• UniswapV2Adapter
• UniswapV3Adapter

The new adapters reference a common contract called UniswapPathChecker to determine whether a path passed during a swap is valid, which implies:

• The intermediary tokens belong to a fixed list of allowed connector tokens stored in UniswapPathChecker;
• The path length does not exceed 3 hops (at most 4 tokens are in the passed path array);

The proposed initial list of allowed connectors is [DAI, USDC, WETH, FRAX] These settings should allow all Router-generated paths and all practical use-cases in general, while prohibiting custom connectors (or known, but exotic, connectors, which can be used as a substitute to a custom token for the purpose of creating an attacker-controlled Uniswap pool).

Additional notes

This change is required to enable partial withdrawals in a safe way down the line.