Overview of StableSwap Designs
Last updated
Last updated
StableSwap concept has come a long way—but not without challenges. In this section, we explore the development of different StableSwap mechanisms, their limitations, and how Möbius design helps overcome these inefficiencies.
Uniswap V2 was a revolutionary Automated Market Maker (AMM) that enabled on-chain trading and liquidity provision by LPs. Price was determined algorithmically, based on the invariant function x*y = k. However, Uniswap V2 is not suitable for use as a StableSwap.
In CPMM model, liquidity is provided for a price range from 0 to infinity, which is not ideal for a StableSwap. For pegged assets, only a tiny portion of the pool's liquidity is used for trades, as these assets don't typically deviate significantly from their peg. Consequently, small trading amount in Uniswap V2 can cause substantial price impact, leading to uncompetitive pricing compared to other AMMs.
As an illustrative example, if the relative price of the pair of assets oscillates between 0.99 and 1.01, based on the invariant formula, the amount of each asset in the pool would oscillate between 94.8% to 105.4% of the original amount. That means the liquidity utilization for trades is only around 10.6%, leaving approximately 89.4% of the pool's liquidity idle. This inefficiency results in significantly lower potential trading volume compared to a scenario where all liquidity is actively used. The underutilization of liquidity translates to reduced fees generated and a lower overall APY for the LPs.
Uniswap V2 only supports two tokens in a pool. Listing three tokens necessitates two pools with an intermediary token, resulting in capital inefficiency, fragmented liquidity and as a result, additional fees for traders. This further diminishes the competitiveness of the rates offered.
Another option for the stableswap is mStable’s Constant Sum Market Maker (CSMM). It is an extreme case of concentrated liquidity, where the exchange rate remains 1 regardless of market price fluctuations. This design has a significant drawback.
The price offered by the AMM is fixed to 1 regardless of the liquidity in the pool. For example, if the pool has 90% USDT and 10% USDC due to loss of confidence in USDT, the CSMM AMM would still offer USDC at a 1:1 price. Resulting in a loss for the LPs.
Even with small price changes (e.g., 1:1.001), the pool becomes dominated by the cheaper asset. Additionally, if prices oscillate out of range (e.g., 0.99 to 0.995), no trading would occur in the pool as liquidity becomes ineffective.
Curve is a hybrid of CSMM and CPMM, offering a stable rate when pool liquidity is balanced (similar to CSMM) and rapid price adjustments when liquidity is imbalanced (similar to CPMM). This approach tackles the aforementioned drawback of liquidity insensitivity and non-concentrated liquidity. It is suited for stable assets. Similar to CSMM, by utilizing concentrated liquidity, the majority of the liquidity is used effectively, as long as the price remains relatively close to a 1:1 ratio.When the price deviates from 1, the Curve's behavior resembles that of a CPMM, and the price offered becomes sensitive to liquidity: As the proportion of the asset in the pool decreases, the price of the asset increases, and vice versa. While this hybrid design improves capital efficiency and stability for pegged assets, it is not without limitations.
One drawback is that equilibrium is still defined as having equal amounts of all assets. For example, if the pool contains 10M USDC, 8M USDT and 3M DAI, the AMM artificially favors swapping from other assets to DAI, in order to absorb more DAI into the pool. This creates idle liquidity, as the pool doesn't actually need the excess DAI.
As a solution, a balanced USDT-USDC pool and a smaller, balanced DAI-LP token pool (where the LP token is from the first pool) must be created to achieve equilibrium of both pools. This solution is clearly not optimal because additional pools must be created manually as liquidity changes.
LP positions always represent a proportional share of the pool. This means that if LPs deposit one asset, the system swaps portions of it for all other assets in the pool. Consequently, when LPs withdraw their liquidity, they receive a mix of assets rather than the exact asset they initially deposited. This forced asset composition can lead to unwanted exposure and inefficiencies, creating a suboptimal user experience.
