[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:

  1. The intermediary tokens belong to a fixed list of allowed connector tokens stored in UniswapPathChecker;
  2. 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.

1 Like

Totally support the initiative, it makes protocol more predictable and opens new opportunity for further innovations

Snapshot vote

Just for those wondering:

There are no risks of misuse of this - this case has long been known and does not represent a direct vulnerability. But when testing and predicting the operation of the protocol - it is always convenient to have a finite number of cases - and the prohibition of other tokens in the exchange paths significantly reduces them - which makes simulations and testing easier.