Numerical Stability Challenges in Uniswap V3 and Curve Pools

[liewmanchoi]

Background

I am currently developing an optimization process that encounters numerical stability issues due to the large range of values in liquidity pools. For Uniswap V2-type pools, we have found that simply applying a proportional scaling to the reserve values of the same token effectively mitigates these numerical issues. This scaling transformation allows us to adjust the values into a more manageable range for computation without affecting the accuracy of the Uniswap V2 trading formula.

Problem Description

However, this straightforward scaling method fails in Uniswap V3 and Curve-type pools due to their more complex trading formulas. Below, we detail the key differences and explain why the scaling approach that works for Uniswap V2 does not apply to these pools.

1. Uniswap V3 Pools

   In Uniswap V3 pools, the trading formula is represented by the following equation:

   $$(R_1 + \alpha)(R_2 + \beta) = K$$

   where:

   • $R_1$ and $R_2$ are the reserves of two tokens in the pool,
   • $\alpha$ and $\beta$ are constants that define the price range or liquidity characteristics of the pool,
   • $K$ is a constant that represents the pool’s invariant.

   This equation maintains a product invariant with constants $\alpha$ and $\beta$, which are essential to controlling price ranges and liquidity in Uniswap V3. Proportionally scaling $R_1$ or $R_2$ independently disrupts this invariant relationship, leading to inaccuracies in trade calculations. As a result, the scaling method that works for Uniswap V2 is ineffective for Uniswap V3.

2. Curve Pools

   Curve pools have a more complex formula to facilitate stable swaps between assets, designed to minimize slippage for assets of similar value. For a two-asset Curve pool, the full pricing formula is:

   $$A \cdot n^n \cdot \left( \sum_{i=1}^n R_i \right) + D = A \cdot n^n \cdot \sum_{i=1}^n \frac{D}{n R_i} + \prod_{i=1}^n R_i$$

   where:

   • $A$ is an amplification coefficient that adjusts the pool’s curve shape, promoting low slippage in stable swaps,
   • $n$ is the number of assets in the pool (e.g., 2 for a two-asset pool),
   • $R_i$ represents each asset’s reserve in the pool,
   • $D$ is the invariant representing the total liquidity in the pool.

   This equation is more intricate than those for Uniswap pools, as it involves both additive and multiplicative terms, which collectively define the invariant $D$ in terms of reserves $R_i$. Simple proportional scaling of any reserve disrupts the balance of these polynomial terms, causing inaccuracies in the calculated output amounts due to the breakdown of the invariant balance.

Request for Assistance

While our current approach addresses numerical stability for Uniswap V2 pools, it fails for Uniswap V3 and Curve pools due to their more intricate formulas. I seek guidance or recommendations on methods that can manage numerical stability in these more complex pool environments, ensuring the optimization algorithm is practical and accurate under real-world conditions.

Any insights or suggestions from the community would be greatly appreciated!