Simple understanding of how Curve V2 operates, and how is its liquidity strategy different from Uniswap V3?

The release of Curve V2 was extremely low-key, with no beautifully crafted landing page, no explanatory videos of the principles, and not even a decent promotional campaign. The entire launch event was simply the release of a whitepaper on the project's official website that introduced the basic principles of V2. Although the whitepaper is only 5 pages long, it is filled with mathematical formulas that may intimidate the average user. Therefore, before delving into the significance of Curve V2, it is necessary to first explain in the simplest terms possible how Curve supports trading pairs of stablecoins in the V2 version.

(This article is authorized to be reprinted from BlockBeats. The original title is "Analysis of Curve V2 Solution: The Battle Between Generalization and Customization AMM." For the original article, please see here.)

Explaining the Basic Principles of Curve V2 in Plain Language

Don't be intimidated by the mathematical symbols such as summation "∑" or product "Π" in the Curve whitepaper. The complexity of Curve's formula is not due to its algorithm being overly mysterious, but because Curve aims to natively support multi-currency trading pools from the underlying logic. Thus, the simple two-dimensional constant product formula xy=k needs to be elevated to a more complex multi-dimensional constant product form.

This seemingly intricate multi-dimensional constant product form is the result of this necessity.

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

The above image is an excerpt from the Curve V2 whitepaper describing the price curve. Similar to Curve V1, which combines two basic price curves xy=k and x+y=k in a certain weighted ratio, Curve V2's price curve is also composed of fitting other basic curves. Simply put, the curve is closer to Curve V1's shape (blue) near the trading price, while it approaches xy=k (dashed line in the bottom left) further from the trading price. This forms a smoother price curve near the trading price but with a larger curvature further away from it (orange), providing more support for unstable coin pairs compared to V1's price curve, which is closer to a straight line.

Of course, if Curve V2 merely reconstructed a fixed-shaped price curve, it would not achieve its goal of dynamically aggregating liquidity at all price points. The key improvement in Curve V2 is the automatic rebalancing of liquidity when the price deviates from the original aggregation range, reconstructing a curve suitable for the new price.

Another issue to address is how the system detects market price changes and performs rebalancing at the right time. While most similar projects would directly integrate external oracles, introducing external oracles also brings new external risks to the system, as the security of LP funds becomes challenging if the oracle fails or is manipulated.

To completely eliminate external risks, Curve V2 relies on internal data as a reference price, a mechanism known as the EMA (exponentially moving average) oracle. Readers do not need to understand what EMA is; they only need to know that this EMA oracle provides a price calculated based on Curve's historical transaction prices and the latest trading information. This reference price is somewhat similar to a 30-day moving average in technical analysis, adjusting dynamically based on the latest transaction prices while maintaining a certain lag to prevent excessive triggering of the rebalancing mechanism 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 by a certain range, the protocol automatically adjusts the shape of the entire curve to reaggregate liquidity near the latest trading price.

Differences Between Curve V2 and Uniswap V3 Solutions

When Curve V2 was first released, there were comments suggesting that Curve V2 would directly compete with Uniswap V3. After all, both proposed universal solutions for aggregating liquidity across all price ranges. However, upon closer analysis of the specific implementations of these two projects, significant differences between them become apparent.

Difference One: How to Determine Liquidity Aggregation Areas

In Curve V2, LPs do not need to actively choose the liquidity aggregation range when providing liquidity. The system automatically concentrates LP liquidity near the trading price based on market price changes. In contrast, Uniswap V3 requires LPs to assess market price trends and independently select the price ranges for liquidity provision.

Difference Two: Homogeneity of LP Positions

Due to varying LP liquidity amounts and ranges, Uniswap V3 uses NFTs to represent LP liquidity positions. In Curve V2, each LP's liquidity distribution in the pool is identical, with differences only in quantities, allowing the use of homogeneous ERC20 tokens to represent LP positions. This significantly reduces the difficulty when integrating with other protocols compared to Uniswap V3.

Difference Three: Rebalancing Liquidity

Uniswap V3's passive liquidity management approach became ineffective after the upgrade to V3, as LPs need to continually assess price trends and adjust positions actively. Curve V2 fully integrates the rebalancing strategy into the protocol layer, where users do not need to understand the basic principles of rebalancing or choose from various market agent solutions; they only need to consider when to deposit and withdraw funds, leaving the rest to the automatic execution by the Curve protocol layer.

Difference Four: Determining Transaction Fees

In terms of transaction fees, Uniswap does not offer a universal solution. The system provides three fee tiers for LPs to choose from, each corresponding to an independent liquidity pool, limiting user choices and fragmenting liquidity.

In contrast, Curve V2 adopts an automated solution with a built-in fee range of 0.04% - 0.4% (this ratio is sourced from community discussions, corrections are welcome). The fee is lowest when the market price is near the midpoint of liquidity aggregation, gradually increasing as the price deviates. The entire process is fully automated, requiring no management or intervention from LPs.

After comparing the above points, it seems that Curve V2's all-in-one solution is simpler and more user-friendly compared to Uniswap V3. Almost all critical liquidity provisioning parameters in Uniswap V3 require user decisions and continuous rebalancing during the liquidity provisioning process. Given that both projects have top-tier development teams, why do they offer such different solutions for similar needs?

Methodological Disputes: Application vs. Ecosystem

These two fundamentally different solutions are not constrained by the technical capabilities of the development teams; the root cause lies in the founders' divergent understandings of the industry's core demands.

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

Recognizing that individual and team intentions are not always correct, and fully opening the choice to the market and community, while only participating in the construction of the underlying infrastructure, is the core principle of the Uniswap team.

In contrast, the Curve team takes a different approach, believing that users' time and attention are limited and should not be burdened with complex decision-making. The development team should directly provide users with a complete optimal solution, where users only need to consider when to deposit funds, when to withdraw them, leaving all other processes to be automatically handled by the protocol.

Recognizing that most users lack professional analytical abilities, it is essential for more professional industry experts to provide a comprehensive solution, attempting to solve all possible obstacles users may encounter, which is the core concept of Curve V2.

Whether to directly create a powerful product or become a universal underlying structure empowering ecosystem development is the most significant difference in development philosophies between Curve and Uniswap, and only time will tell which approach will ultimately pass the market test.