Before formally introducing the significance of Curve V2, it is necessary to analyze how Curve implements support for non-stablecoin trading pairs in the V2 version in the simplest and most understandable language.
Curve V2 Solution Analysis: The Battle between Universal and Customized AMM
The release of Curve V2 was extremely low-key, with neither a beautiful introduction page nor a video explaining the principle, nor even a decent promotion. The entire release was a white paper introducing the basic principles of V2 on the project’s official website. Although the white paper was only 5 pages long, it was full of mathematical formulas that would be intimidating to ordinary users. Therefore, before formally introducing the meaning of Curve V2, it is necessary to explain in the simplest language how Curve supports non-stable currency pairs in V2.
Explain the basic principle of Curve V2 in plain language
Don’t be intimidated at first by the mathematical symbols in the Curve whitepaper such as cumulative “∑” or cumulative multiplication “Π”. It is because Curve wanted to support multi-currency pools natively in the underlying logic from the very beginning, so the original simple and easy to understand two-dimensional constant product formula xy=k needs to be dimensioned up to
This seemingly complex multi-dimensional constant product form.
Therefore, to enable the reader to better understand it, we here re-reduce the multi-dimensional model to a more understandable two-dimensional state (a two-currency pool). So, what does the price curve of Curve V2 look like in the simpler two-dimensional model?
The above figure is an extract of the price curve from the Curve V2 white paper. Similar to Curve V1 where the basic price curves of xy=k and x+y=k are fitted with a certain weighting ratio, the price curve of Curve V2 is also fitted with other basic curves. In simple terms, the curve is closer to the shape of Curve V1’s curve near the trading price (blue), and closer to xy=k away from the trading price (dashed line at the bottom left). This results in a price curve that is smoother around the trading price, but more curved away from the trading price range (orange). Compared to the V1 version where the price curve is closer to a straight line, the V2 curve is more curved at the far end to increase the support for non-stable pairs.
The key improvement of Curve V2 is that it can automatically rebalance the liquidity when the price deviates from the original aggregation range, and reconstruct a new price curve for the new price. Another problem that needs to be solved at this point is the rebalance.
Another problem that needs to be solved at this point is how the system senses the changes in market prices and performs rebalancing at the right time? Most of the similar projects would choose to directly access the external prediction machine, but the introduction of external prediction machine also introduces new external risks to the system, if the prediction machine fails or is manipulated, it is difficult to guarantee the safety of LP funds.
In order to completely eliminate the external risk, Curve V2 relies on internal data as the reference price, which is officially called EMA (Exponentially Moving Average). The reader does not need to understand what EMA is, but only needs to understand that the price provided by this EMA is a reference price calculated based on Curve’s historical trading price and the latest trading information. This reference price is somewhat similar to the 30-day SMA in technical analysis, which is dynamically adjusted based on the latest transaction price, but with a certain lag so as not to trigger the rebalancing mechanism too often when the price fluctuates drastically.
With the reference price provided by the internal prognostic machine, the system has a basis for rebalancing. When the price quoted by the EMA prognosticator deviates from the original price by more than a certain range, the protocol automatically adjusts the shape of the entire curve, allowing liquidity to regroup around the latest trading price.
How Curve V2 differs from Uniswap V3’s solution
When Curve V2 was first released, there were comments that Curve V2 would be in direct competition with Uniswap V3. After all, both proposed a universal solution for aggregating liquidity across the price range. However, a closer analysis of the specific implementation of the two projects reveals clear differences between them.
Difference 1: How to decide where to aggregate liquidity
Market making in Curve V2 does not require LPs to actively choose the liquidity aggregation range. The system will automatically pool the LP’s liquidity around the trading price based on the movement of the market price. Uniswap V3, on the other hand, requires LPs to judge the price trend of the market and choose the price range for market making on their own.
Difference 2: Is the LP’s position homogeneous?
As we know, since each LP’s market making amount and range are different, Uniswap uses NFT to represent LP’s market making position in V3. In Curve V2, this problem is completely eliminated, as each LP has the same liquidity distribution in the pool, with only quantitative differences between them, so it is still possible to use homogeneous ERC20 tokens to represent the LP positions. This greatly reduces the difficulty of combining other protocols with Curve.
Difference 3: How to rebalance funds
We often say that after Uniswap upgraded to V3, the passive market making management solution is no longer effective, and LPs need to actively judge the price trend and adjust their positions. Users no longer need to understand the basic principle of rebalancing, nor do they need to choose among many proxy solutions in the market, they only need to consider when to deposit and when to withdraw, and the rest is automatically executed by Curve’s protocol layer.
Difference 4: How to determine transaction fees
Uniswap does not offer a universal solution to the issue of fees. The system natively provides only three levels of fees for LPs to choose from, and each level corresponds to a separate pool of funds, which not only limits the range of options for users, but also increases the degree of fragmentation of liquidity.
In contrast, Curve V2 still uses an automated solution, with a built-in fee rate range of 0.04%-0.4% (this rate is derived from community discussions, and any errors are welcome). The fees are lowest when the market price is close to the midpoint of liquidity aggregation, and gradually increase when it deviates. The whole process is fully automated and does not require LP management or intervention.
After comparing the above, we found that Uniswap V3 seems to be both complicated and difficult to use compared to Curve V2, a one-stop solution. Almost all the key parameters of market making need to be chosen by the user, and also need to be rebalanced during the subsequent market making process. So why did two headline DEX projects with the same top development teams in the industry deliver such different solutions for the same needs?
Methodology debate: application or ecology
The two very different solutions are obviously not limited by the technical capabilities of the development teams, but by the fact that the founders of the two teams have a very different understanding of the core requirements of the industry.
The core idea of Uniswap V3 is to fundamentally solve the ever-growing number of customized AMM bifurcation projects by developing a universal solution that can simulate any shape of price curve. Therefore, the development team had to leave the decision on various key parameters to the market and keep supporting the development of the ecosystem by setting up a developer fund. The hope is that the market will be able to develop a few mature active market making management solutions through free competition to address the ever-changing market needs.
Acknowledging that the will of individuals and teams cannot always be right, and leaving the choice fully open to the market and the community, while only participating in the construction of the underlying infrastructure themselves, is the core philosophy of the Uniswap team.
The Curve team did the opposite, believing that users have limited time and attention span and should not be trapped in a complex choice dilemma. The development team should simply provide the user with a complete and optimal solution, so that the user only has to think about when to deposit funds and when to withdraw them, and the rest of the process is done automatically by the protocol.
Acknowledging that most users do not have professional analytical skills, it is necessary for the more professional industry elite to provide a package solution that tries to solve all the obstacles that users may encounter, is the core concept of Curve V2.
Whether to make a powerful and good product directly, or to become a universal underlying architecture and empower the ecological development, this is the most important difference between Curve and Uniswap, the two top teams’ development thinking. Which of the two different methodologies will eventually pass the test of the market, perhaps only time will give the answer.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/curve-v2-solution-analysis-the-battle-between-generic-and-customized-amm/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.