Recently, AMMs like Curve Finance have created mechanisms which pool more than 2 assets, typically for tuples of stable tokens. These pools have been highly successful, with Curve’s 3Pool (USDC-USDT-DAI) attracting billions in TVL and large transaction volumes. Pools with n > 2 assets will herein be referred to as Multi Token Pools (MTPs) for simplicity. In this paper, we explore the tradeoffs between MTPs and traditional “2Pools” in stable pair AMMs, with a focus on Solana.
MTPs serve as useful DeFi liquidity legos, and provide excellent gas optimization on Ethereum. They are especially effective when focusing on deep liquidity for a small number of pools with non-overlapping assets. At Saber, we initially planned to implement MTPs for stable assets, but decided instead to use 2Pools connected with a router system. This decision was made due to our strategic positioning as the cross-chain liquidity foundation for DeFi. We want many pools rather than few pools, and we greatly value the increased composability of 2Pools that is necessary for cross-chain DeFi. On Solana, 2Pools can be more capital efficient and composable, have faster runtimes, and are safer for isolating systemic risks.
MTPs are great for gas optimization on fee-heavy blockchains such as Ethereum. Curve Finance’s 3Pool on Ethereum is highly popular due to the gas efficiency of its design. Throughout the contract, major functions like
add_liquidity use for loops through
N_COINS (3 in this case), an improvement on the quadratic scaling that would occur passing through each of C(n,2) (i.e. n choose 2 pairs). Further, the swap function runs in constant time with respect to the number of tokens. Curve’s Stableswap implementation also generalizes the computationally intensive AMM curve calculation for multiple variables, again saving instruction overhead. However, on Solana, gas optimization is not a priority due to the minimal fees, fast finality and transaction speeds. Coding in Rust involves a different mindset of maximizing security and smooth transaction execution.
Another great advantage of MTPs is that swapping between assets is easier within tuples such as USDC-USDT-UST. A user can easily exchange any of the n assets for any of the others in one trade. However, a similar user experience can also be achieved by 2Pools if a router is used. Saber’s smart router system routes trades through the minimal path between connected 2Pools, enabling transitive swaps between assets which do not have a direct pair such that they are automatically swapped at the best price. For example, there exists a pool containing A : B, and a separate pool B : C. With a router, the A : C relationship can be established transitively.
The most popular MTP implementations are on Curve. Consider for example the sUSD pool which holds 4 assets. Since LPs can add sUSD liquidity in USDC, USDT, and DAI, there is more available liquidity for constructing the sUSD pool. If only DAI were used for example, and we only wanted one sUSD pool, USDT holders would be locked out of LP’ing. Thus, MTPs help maximize deep liquidity trenches for a few pools of blue-chip cryptocurrencies. However, it should be noted that new MTPs with assets that overlap with other MTPs provide diminishing marginal benefits. Furthermore, the number of unique potential MTPs containing large blue chips such as USDT-USDC-DAI are limited.
Why Saber Chose a 2Pool-Router System Instead
Solana’s protocol-level architecture is vastly different from Ethereum. Not only are pools containing two assets more intuitive for the average retail user, 2Pools have distinct advantages in Solana’s environment.
I. Liquidity Is Efficiently Distributed
When handling a large number of assets, liquidity becomes thin in MTPs. Consider two pools USDC-USDT-UST and USDC-USDT-DAI. The liquidity providing the USDC-USDT relationship across the two MTPs is ‘duplicated’, and thus wasted. With the only difference between these pools being the third asset, the benefits of sharing assets in multiple 3Pools become limited. This overlap grows with O(n²) and as we consider the number of stablecoins in a multi chain ecosystem, for example UST and PAI and BUSD, this effect becomes nontrivial.
In 2Pools, however, direct relationships are established between pairs and liquidity is never wasted.
II. Decreased Systemic Risk and Impermanent Loss
All cryptocurrencies have varying levels of systemic risk. Fiat-backed, centralized stablecoins like USDC and USDT carry censorship risk, regulatory uncertainty, and have varying illiquidity for redemption. Algorithmic stablecoins like UST can de-peg based on the volatility of the market. If one of the stablecoins inside the pool becomes compromised, the entire pool is at risk. It is paramount to compartmentalize this risk in isolated 2Pools rather than spreading the risk across 3Pools. Importantly, Saber’s smart router system achieves the best of both worlds by allowing transitive swaps (virtually sharing liquidity between pools) without sharing risk. Only the liquidity providers who are directly affiliated with the spoiled currency bear the systemic risk.
Depegging is a disastrous scenario, and can be exacerbated by the Stableswap algorithm used by stablecoin DEXes. The stableswap invariant of the AMM curve is a modification to the constant product and constant sum curves, aggregating more liquidity near the middle of the curve. In order to achieve a flatter curve near price parity (low slippage), the Stableswap invariant makes a tradeoff by sacrificing steeper slippage at the extremes of the curve. Once depegged assets pass a certain extreme price threshold and fall off the linear plateau, positive feedback loops can cause a detrimental bank-run which exacerbates the depegging. If one of the stablecoins in the pool crashes significantly and never returns to the 1.0 peg, liquidity providers in the pool are effectively left holding almost all their liquidity in the spoiled cryptocurrency.
The threat of depegging is very real. A few months ago, Terra’s UST was depegged to $0.897 and failed to properly recover for several weeks. Under a 3Pool USDC-USDT-UST model, the failure of UST contagiously affects those trading and providing liquidity purely for the USDC-USDT relationship. This risk is mitigated by siloed 2Pools, and offers more discretion for LPs who may hold an opinion about the strength of peg for USDT or UST or any other stable asset.
III. 2Pools: Easy to Balance
Imbalanced pools result in poor capital efficiency and penalization of those holding the dominant assets in the pool (i.e. most people in the pool). Users can deposit single sided on most Stableswap platforms, contributing to the imbalance of assets. MTPs are inherently more sensitive to imbalance due to liquidity mining incentives, market dynamics, systemic risk, and the aforementioned reason of liquidity cannibalization. Maintaining a 33–33–33 or 25–25–25–25 etc. balance is a hard tightrope to walk, especially when each asset can differ significantly in volume, market cap, and accessibility. 2Pools tend to be more balanced and capital efficient simply because the relationship between two assets involves less variables.
How damaging are imbalanced pools? The stableswap curve is designed to encourage users who deposit minority assets that will help balance the pool, and penalize users who are depositing assets that already dominate the pool through higher slippage. The same principle of punishing users who exacerbate pool imbalancing applies to withdrawing from a pool.
To illustrate this, consider a 3Pool consisting of USDC (40%), USDT (40%), and UST (20%). Liquidity Providers depositing USDT or USDC would both be penalized by receiving comparatively less LP tokens for further imbalancing the 3Pool, despite these two assets being relatively in balance with respect to each other. Imbalanced pools also degrade swapping experience. Continuing with the USDC (40%), USDT (40%), and UST (20%) example, users who swap tokens of high supply into tokens of low supply (USDC → UST) are penalized by receiving less tokens in return.
IV. 2Pools: Simplicity and Efficient Code Execution on Solana
Rather than optimizing for overall gas efficiency, programs in Rust on Solana are focused on maximizing security and efficient code execution within a finite transaction instruction space. Solana transactions can only take 200,000 instructions (BPF compute budget) and handling three or more disparate accounts, rather than just two, adds a large number of instructions. There are computing costs associated with creating and maintaining many accounts, such as calling
Account storage is fundamentally different on Solana compared to Ethereum, where it costs nothing. Keeping accounts alive on Solana incurs rent — an epoch-based fixed-rate storage cost — because the blockchain cluster must actively maintain the data to process any future transactions.
A key advantage of AMMs is the composability of LP positions, explored further in our last paper. An MTP LP token is naturally more complex than that of a 2Pool, and this complexity places a limit on the amount of additional logic that can be implemented on top of LP positions. On Solana, for cross-program invocations, the programs invoked inherit the budget of their parent. If an invoked program consumes the budget or exceeds a bound, the entire invocation chain and parent are halted. Saber aims to leave as much free transaction storage as possible in the parent program so that projects built on top of Stableswap AMMs are not restricted by a ceiling.
Specifically, dealing with three accounts instead of two is inefficient for cross-program invocation because invoke functions require the caller to pass all the accounts required by the instruction being invoked. There are numerous other checkpoints (e.g.
pay_and_launch_missiles()) where runtime policy must check the state of all accounts. Since the invoking program is halted until the invoked program finishes processing the instruction, checking an extra account for each instance of the 3Pool state takes up time and introduces additional asynchronicity.
MTPs and 2Pools specialize in fundamentally different things.
MTPs are great for blockchains like Ethereum where gas optimization is important, and are especially effective when focusing on a few blue-chip pools with deep liquidity. However, the number of unique potential MTPs containing large blue chips such as USDT-USDC-DAI are limited.
On Solana, 2Pools tend to be more capital efficient, balanced, safer in isolating systemic risk, more efficient code execution-wise, simpler in math, more composable, and easier to build on top of. For Saber specifically, we decided to build using 2Pools due to our strategic positioning as the cross-chain liquidity foundation for DeFi. We want many pools rather than few pools, and we greatly value the increased composability of 2Pools that is necessary for cross-chain DeFi.
Ultimately, 3Pools and 2Pools have their own strengths and use-cases. We look forward to continued innovations in stableswap AMM designs as the number of cross chain assets continues to grow.
Saber is the leading cross-chain AMM for pegged assets on Solana, such as stablecoins and wrapped assets. As Solana’s core cross-chain liquidity network, Saber helps facilitate the transfer of assets between Solana and other blockchains. Users deposit crypto into a Saber liquidity pool to earn passive yield from transaction fees, token-based incentives, and eventually automated DeFi strategies.