Curve V2 Plan Analysis: The Battle Between General and Customized AMM

This article is sourced from BlockBeats, author: Rhythm Research Institute.

The release of Curve V2 was extremely low-key, with no beautifully crafted introduction page, no explanatory videos, and even no proper promotion. The entire release event consisted of a white paper published on the project's official website that introduced the basic principles of V2. Although this white paper is only 5 pages long, it is filled with mathematical formulas that can be daunting for ordinary users. Therefore, before formally introducing the significance of Curve V2, it is necessary to explain in the simplest terms how Curve supports non-stablecoin trading pairs in the V2 version.

Plain Language Interpretation of Curve V2's Basic Principles

Don't be intimidated at the outset by the summation "∑" or product "Π" symbols in the Curve white paper; the complexity of Curve's formulas does not stem from the sophistication of its algorithms. Rather, Curve aims to natively support multi-currency trading pools from the ground up, which is why the originally simple and understandable two-dimensional constant product formula xy=k needs to be elevated to a seemingly complex multi-dimensional constant product form like .

To help readers better understand, we will reduce the multi-dimensional model back to a more comprehensible two-dimensional state (dual-currency liquidity pool). So, what does the price curve of Curve V2 look like in this simpler two-dimensional model?

The above image is an excerpt from the price curve in the Curve V2 white paper. Similar to how Curve V1 fits the two basic price curves xy=k and x+y=k with certain weight ratios, the price curve of Curve V2 is also derived from other basic curves. Simply put, the curve is closer to the shape of Curve V1 (blue) near the trading price, while it approaches xy=k (the dashed line in the lower left) further away from the trading price. This forms a price curve (orange) that is smoother near the trading price but has a greater curvature as it moves away from the trading price range. Compared to the price curve in V1, which is closer to a straight line, V2's curve has a greater curvature at the far end, thereby increasing support for non-stablecoin trading pairs.

Of course, if Curve V2 merely reconstructed a fixed shape price curve, it would not achieve its goal of dynamically aggregating liquidity at all price points. The most critical improvement in Curve V2 is that when the price deviates from the original aggregation range, it can automatically rebalance liquidity, reconstructing a curve suitable for the new price.

Another issue that needs to be addressed is how the system perceives changes in market prices and performs rebalancing operations at the appropriate time. Most similar projects choose to directly connect to external oracles, but introducing external oracles also brings new external risks to the system; if the oracle fails or is manipulated, the safety of LP's funds becomes difficult to guarantee.

To completely eliminate external risks, Curve V2 relies on internal data as a reference price, and the official term for this mechanism is the EMA (exponentially moving average) oracle. Readers do not need to understand what EMA is; they just need to know that the price provided by this EMA oracle is a reference price calculated based on Curve's historical transaction prices and the latest trading information. This reference price is somewhat similar to the 30-day moving average in technical analysis; it dynamically adjusts based on the latest transaction prices but retains a certain lag to avoid triggering the rebalancing mechanism too frequently during sharp price fluctuations.

With the reference price provided by the internal oracle, the system has a trigger basis for rebalancing. When the price reported by the EMA oracle deviates from the original price beyond a certain range, the protocol automatically adjusts the shape of the entire curve, allowing liquidity to re-aggregate near the latest trading price.

How Curve V2 Differs from Uniswap V3's Solutions

When Curve V2 was first released, some commentators believed that it would directly compete with Uniswap V3. After all, both propose a universal solution for aggregating liquidity across all price ranges. However, a careful analysis of the specific implementation methods of these two projects reveals significant differences.

Difference 1: How to Decide Where to Aggregate Liquidity

In Curve V2, market makers do not need to actively choose the range for liquidity aggregation. The system will automatically concentrate LP's liquidity near the trading price based on market price fluctuations. In contrast, Uniswap V3 requires LPs to judge market price trends and independently select the price range for market making.

Difference 2: Whether LP Positions are Homogeneous

We know that since each LP's market-making amount and range vary, Uniswap uses NFTs to represent LP's market-making positions in V3. In Curve V2, this issue does not exist; every LP's liquidity distribution in the pool is identical, differing only in quantity, allowing the use of homogeneous ERC20 tokens to represent LP's positions. This greatly reduces the difficulty for other protocols to combine with Curve.

Difference 3: How to Rebalance Funds

It is often said that after upgrading to V3, Uniswap's passive market-making management scheme is no longer effective; LPs need to continuously judge price trends and adjust positions. In contrast, Curve V2 fully integrates the rebalancing strategy into the protocol layer itself, so users no longer need to understand the basic principles of rebalancing or choose from various proxy solutions in the market; they only need to consider when to deposit and when to withdraw, leaving the rest to be automatically executed by Curve's protocol layer.

Difference 4: How to Determine Transaction Fees

Regarding transaction fees, Uniswap has not provided a universal solution. The system natively offers only three fee tiers for LPs to choose from, with each tier corresponding to a separate liquidity pool. This not only limits users' choices but also increases the fragmentation of liquidity.

In contrast, Curve V2 still adopts an automated solution, with the system's built-in fee rate range being 0.04%-0.4% (this ratio comes from community discussions; corrections are welcome). When the market price approaches the midpoint of liquidity aggregation, the fee is at its lowest, while it gradually increases as it deviates. The entire process is completed automatically, requiring no management or intervention from LPs.

Through these comparisons, we find that compared to Curve V2's one-stop solution, Uniswap V3 seems both complex and difficult to use. Almost all key parameters for market making need to be chosen by users, and continuous rebalancing is required during the subsequent market-making process. So why do these two top DEX projects, both with leading development teams, deliver such vastly different solutions for the same demand?

Methodological Debate: Building Applications vs. Building Ecosystems

The two distinctly different solutions are clearly not constrained by the technical capabilities of the development teams; the fundamental reason lies in the differing understandings of the core demands of the industry by the founders of the two teams.

The core idea of Uniswap V3 is to develop a universal solution that can simulate any shape of price curve, fundamentally addressing the ongoing emergence of customized AMM fork projects. Therefore, the development team must leave the decision-making power of various key parameters to the market and continuously support ecosystem development through the establishment of a developer fund. They hope that the market can form several mature active market-making management solutions through free competition to meet the ever-changing market demands.

The core philosophy of the Uniswap team is to acknowledge that individual and team judgments cannot always be correct and to fully open the choice to the market and community, participating only in the construction of the underlying infrastructure.

In contrast, the Curve team takes the opposite approach. They believe that users' time and attention are limited and should not be trapped in complex choices. The development team should directly provide users with a complete optimal solution, allowing users to only consider when to deposit funds and when to withdraw, with all other processes handled automatically by the protocol.

Acknowledging that most users lack professional analytical skills, and as more professional industry elites, it is necessary to provide a comprehensive solution to address all potential obstacles users may encounter, is the core philosophy of Curve V2.

The most important difference in the development philosophies of these two top teams lies in whether to create a powerful product directly or to become a universal underlying architecture that empowers ecosystem development. Which of these two different methodologies will ultimately pass the test of the market may only be answered with time.