SAMM: Sharded Automated Market Maker
The DeFi ecosystem is rushing at an exponential rate towards a bottleneck due to one of its cornerstones: Automated Market Makers (AMMs). AMMs work on top of decentralized blockchains. They allow users to trade virtual tokens immediately, not waiting for a matching trade as with traditional order books. The demand for this service indeed grows exponentially, as the next figure shows.
But we show that AMMs do not scale well. State-of-the-art blockchains parallelize computation; for example, Sui reaches over 290,000 transactions per second (tps), and Solana can manage over 65,000 tps. Nevertheless, AMM processing cannot be parallelized. Our experiments show that the maximal tps for an AMM contract is slightly above 200 tx/sec in Sui and no larger than 130 tx/sec in Solana. If AMM trading volume continues its current trajectory, neither blockchain can handle the demand by 2029.
To address this, we present a novel AMM architecture: Sharded Automated Market Maker (SAMM). The basic idea follows the classical distributed computing approach of sharding: SAMM uses multiple independent AMM shards, all operating in the same blockchain, and each processing part of the workload. But unlike the classical case, here we cannot assume the users would distribute their requests among the shards. Indeed, we show that a naive implementation would only harm performance. Instead, by redesigning the AMM fee structure, we incentivize all users to follow the desired behavior.
Our experiments show SAMM scales with the number of shards, though Sui and Solana exhibit different behavior. In Sui, throughput increases sublinearly with the number of shards, following Amdahl’s Law. In contrast, Solana’s throughput increases linearly until it reaches the system bottleneck.
Before getting into the details, we provide a short overview of automated market makers. You can skip ahead if you already know all about AMMs and their slippage issues.
The full report is here.
Automated Market Makers
Automated Market Makers (AMMs) are smart contracts that facilitate the trading of digital assets without a traditional order book. Instead of listing buy and sell orders that intermediaries match, traders can trade directly with these smart contracts. AMMs (see Figure 2) use liquidity pools and algorithms to determine prices and execute trades automatically. These pools are funded by users known as liquidity providers, who deposit pairs of tokens into the pool. In return, they earn fees from the trades executed by traders that occur within the pool. For simplicity, we’ll only consider AMMs with exactly two tokens, or one pair.
A popular type of AMM is the Constant Product Market Maker (CPMM ). In a CPMM, the product of the quantities of the two tokens in the pool remains constant after each trade. For example (Figure 3, below), consider a liquidity pool containing 50 token A and 120 token B, with a product of 6,000. A user wants to buy 10 token A using token B. After the user buys 10 token A, the pool will have 40 token A. To keep the product constant, the amount of token B in the pool must satisfy 40 * new_tokenB_amount = 6,000. Solving for the new_tokenB_amount gives us 150. Therefore, the user must add 30 token B to the pool to buy 10 token A. This mechanism ensures that the price of the tokens adjusts according to supply and demand. AMM contracts usually charge a fixed ratio of trading volumes as the trading fee, which forms the revenue of liquidity providers. In the example, the AMM charges a 0.3% trading fee for the input token B, which is 0.09.
It’s important to note that when the trader wants to acquire more token A, they experience increased per-unit costs. For example, if a trader wants to buy 20 token A, the price of each unit of token A is raised to 4 token B (Figure 4, below), instead of 3 when he bought just 10. This phenomenon is called slippage.
CPMMs Don’t Scale
AMMs face significant scalability challenges due to their non-parallelizable nature. This limitation arises because AMMs require sequential processing of transactions, as each transaction’s outcome depends on the current state of the liquidity pool, which is altered by the transaction. Consequently, transactions cannot be parallelized, restricting throughput to the performance of a single CPU core.
Our experiment (Figure 5) on the Sui blockchain verifies this important observation. Mysten reports that Sui can handle over 297,000 tps due to parallel execution, and we verify it can handle more than 2,000 token transfers per second with marginal latency. However, the maximal throughput of Omniswap, a Uniswap v2-like AMM on Sui, is only 214 tps. Our Solana experiments show similar results, with 129 CPMM transactions per second. As we mentioned, this limitation (214 tps) is expected to be surpassed by 2029 by Uniswap’s demand.
Naive Sharding Is Even Worse
An intuitive idea to parallelize is to deploy multiple CPMM instances, so traders would use different instances. Unfortunately, we find that this is against their interest. Due to slippage, traders split their trades across multiple AMM instances to get better prices. Consider a scenario (Figure 6) where a trader wants to get 20 token A. There are two shards, each with 50 token A and 120 token B. If the trader attempts to buy all 20 token A from one shard, the total cost is 80.24 including the trading fee. Instead, by splitting the trade and buying 10 token A from each pool, the trader could reduce slippage and pay a lower cost of 60.18 token B. In fact, this is true in general, whatever the traded amount is and whatever the liquidity state is. Therefore, each trade would span all instances, increasing overhead but not improving throughput.
SAMM: Sharded AMM
To address these challenges, we present SAMM. SAMM is a sharded Automated Market Maker, comprising multiple AMM instances, called shards. All shards operate as independent AMMs on the same blockchain, allowing for parallel processing of transactions.
To address the challenge of transaction splits, we design the incentive structure with a variable trading fee mechanism. Instead of the fixed proportional fee used by existing AMMs, our function charges higher proportional fees from trades with smaller amounts. This discourages most trades from splitting, as they would incur higher trading fees. Additionally, this design results in higher costs in shards with less liquidity. Consequently, traders are incentivized to use smaller shards, so liquidity providers are encouraged to deposit more tokens in these smaller shards for the trading fees. This leads to a balanced distribution of liquidity across all shards. As a result, the trader would randomly choose a shard for trading. We verify this both by game-theoretic analysis and by simulation. Figure 7 shows the number of trades executed in each shard compared to the average in the simulation using Uniswap v2 data we sampled (condensed to match our high throughput). Error bars show the range of relative trade numbers in each shard compared to the average. They confirm that the difference from the average is always under 5%.
Performance
We implemented SAMM on local test networks of both Sui and Solana. Our evaluation shows that with more shards in Sui (Figure 8) and Solana (Figure 9), SAMM achieves higher throughput (X axis) with low average latency (Y axis). SAMM handles a fivefold and sixteenfold increase in throughput in Sui and Solana, respectively, compared to a standard single-contract AMM.
The manner of performance improvement in the two blockchains is quite different. In Sui, the maximal tps of SAMM as a function of the number of shards follows Amdahl’s Law (Figure 10), indicating that the parallelizable part of an AMM transaction is about 80%. We also observe that if the blockchain’s serial processing elements’ proportion is reduced, we can achieve a higher throughput. In Solana, there is an artificial throughput limitation imposed by the gas limit in each block. We tested both the default setting (marked as Solana-Default) and a setting with the block gas limitation removed (marked as Solana-NoBlockLimit). In both scenarios, throughput increases linearly with the number of shards (Figure 11), showing up to 4 times and 16 times improvement, constrained by the gas constraints and processing limitations, respectively. Removing those last constraints harms system stability resulting in frequent failures.
Conclusion
In summary, SAMM addresses the scalability challenges of AMMs by distributing the load across multiple shards and incentivizing balanced liquidity distribution and trade workload. This not only enhances the performance and efficiency of AMMs but also provides a new methodology to scale DeFi solutions on blockchain platforms.
Our full report with the formal model definition, trading fee functions, game-theoretic analysis and simulations with real data is here.
