A Brief History of StableSwap
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, Curve utilizes concentrated liquidity, allowing the majority of liquidity to be used effectively as long as the price stays close to the 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.
Curve defines pool equilibrium as having equal amounts of all assets, which can create inefficiencies. For example, if a pool holds 10M USDC, 8M USDT, and 3M DAI, the AMM artificially incentivizes swaps into DAI to balance the pool, despite DAI already being in excess relative to market needs. This results in idle liquidity and inefficient capital use.
To address this, users often need to create a balanced USDT-USDC pool and a separate, smaller DAI-LP token pool (using LP tokens from the first pool). However, this solution is suboptimal as it introduces manual intervention and increases operational complexity as liquidity conditions evolve.
LP positions always represent a proportional share of the pool. This means that if LPs deposit one type of asset, the system swaps portions of it for all other assets in the pool. As a result, when withdrawing, LPs receive a mix of assets, not necessarily the one they originally deposited. This forced exposure can lead to undesired asset holdings, slippage, and additional friction, making the user experience less optimal for liquidity providers.
To address the limitations of existing Stable Swap designs, we outline the essential qualities that an ideal system should possess. The next section will explain how Möbius achieves these goals through its innovative architecture.
High Liquidity Utilization Concentrate liquidity effectively around the peg to maximize trading volume and minimize idle capital.
Liquidity Sensitivity Adjust prices dynamically based on pool imbalances, ensuring that the AMM reflects real supply-demand conditions.
Flexible Asset Composition Allow LPs to deposit and withdraw single assets without forced swaps into multiple tokens, preserving user intent and reducing slippage.
Efficient and Simple Invariant Function Use a closed-form or near-closed-form solution for the invariant to minimize gas usage, rounding errors, and potential attack surfaces.
Multi-Asset Pool Efficiency Support pools with more than two tokens without requiring manual pool chaining or creating fragmented liquidity.
Gas-Efficient Operations Minimize on-chain computation costs for swaps, liquidity provisioning, and pool updates.
Curve’s stable pools use a complex invariant function without a closed-form solution, requiring being computed on-chain. This increases gas costs, introduces rounding inaccuracies, and creates potential attack vectors if the numerical method fails to converge properly or is manipulated under edge cases.
