Maverick 101: A Short History of AMMs
Welcome to the first edition of Maverick 101, a regular blog series where we explain some of the fundamental concepts of DeFi, and some of the specific features of Maverick itself!
In this installment, we’ll be looking at Automated Market Makers (AMMs), the smart contracts that enable trading to be decentralized, permissionless, and immediate. To borrow the words of Vitalik Buterin, AMMs can be defined as “fully automated on-chain mechanisms that act as always-available counterparties for people who wish to trade one type of token for another.” AMMs manage deposits of assets supplied by liquidity providers (LPs), which the AMM offers to traders in peer-to-contract trades.
DeFi is basically built on AMMs. AMMs replace traditional intermediaries like centralized order books and market makers to facilitate truly permissionless trading on the blockchain. According to DeFi Pulse, around $17.75b is currently locked up in the top ten DEXs, all of which are powered by some version of an AMM.
Where did AMMs come from? How have they developed over time? And what are the pros and cons of the different types of AMM? Read on to find out!
We’ll begin by taking a look at constant sum and constant product AMMs, followed by concentrated liquidity AMMs, and then a couple of variations on all three of these models. We’ll finish with the Maverick AMM, which we believe represents the next generation of AMM technology.
Constant Sum AMMs
A constant sum AMM is perhaps the most basic way of setting up a smart contract that can manage swaps between two assets in a pool. It is based on the simple formula x + y = k, and follows a computational rule that basically states that the value of k must remain constant at all times. If x and y represent the two assets being traded in a pool, then the rule effectively states that whenever the value of x changes the value of y must also be changed in order to keep k–their sum–constant (and vice versa). So if the value of x were to decrease, the value of y would have to be increased by whatever amount is necessary to keep k at a constant value.
This formula is sufficient to set up a very basic pricing mechanic, which tells the contract how much x to charge for y in any given swap (and vice versa). The answer is always: whatever it takes to balance the asset being removed from the pool, in order to keep k constant.
For example, imagine a pool that contains 10,000 USDT (x) and 10,000 USDC (y). The sum of these assets would be 20,000 (k). If a trader came to the pool and wanted to remove 1,000 USDT, the AMM could use the formula x + y = k to know that it should demand 1,000 USDC in return (since 20,000–1,000 = 19,000, and 1,000 would therefore be required to keep k constant).
The formula can be represented on a graph like this:
A constant sum AMM can offer no-slip trading and lots of market depth at a single price. But there are limits on the liquidity it can supply, and it only works well for a pair of assets where we can expect that the price will not change. If the price on exterior markets were to drift from the pool price, it would be straightforward for an arbitrageur to empty a constant sum pool of one asset and sell it elsewhere for a profit.
Simply put: such a basic AMM is not sufficient to run efficient, independent markets that protect investments and facilitate robust trading activity between a variety of assets.
Constant Product AMMs
In 2017, Hayden Adams began developing the AMM that would become Uniswap V1. Adams was inspired by Vitalik’s blog-post, which itself developed ideas about a constant product AMM credited to Alan Lu. The realization of a functional constant product AMM was a critical moment in the history of DeFi.
How does a constant product AMM differ from a constant sum AMM? A constant product AMM also works by keeping a certain value (k) constant at all times. But whereas the constant sum AMM maintains k according to the sum of the values of the two assets in a pool (x + y), a constant product AMM maintains it according to the product of the values of the two assets (x * y). For this reason, constant product AMMs are also sometimes referred to as xy = k AMMs.
For example, imagine a user wishes to trade in Uniswap’s ETH/USDT pool, at a point when the liquidity of the pool is at 10 ETH and 30,000 USDT. If x is the amount of ETH in the pool and y the amount of USDT, then the k for this pool is 300,000 (because 10 * 30,000 = 300,000). Whatever interactions the user has with the pool, the AMM will always adjust prices to keep the k at 300,000.
As in a constant sum AMM, a decrease in x must be matched by a proportional increase in y, sufficient to keep k constant (and vice versa). But basing the governing formula around a product (x * y) instead of a sum (x + k) creates a very different pool: one that allows for dynamic pricing and theoretically infinite liquidity.
This formula can be represented on a graph as an invariant curve (so named because it is the curve produced by the formula which has the constant or invariant product k).
The constant product formula was a practical solution to automatic price discovery in trading pools. Provided that the pool begins at a sensible liquidity ratio, the formula will balance the prices of assets in a way that both disincentivizes trades that move the price dramatically and incentivizes arbitrageurs to keep the pool price in line with exterior markets, instead of simply draining it.
Uniswap V1 hit the Ethereum mainnet in November, 2018, using constant product AMMs to facilitate swaps between ETH and any ERC20 token. Uniswap V2 followed in May, 2020, extending its swap markets to include any ERC20 pair. Together, these two versions of the constant product AMM represent the inspiration for the majority of AMMs that would follow.
The Problem of Slippage
While Uniswap succeeded in automating market making in a functional and transparent manner, these constant product AMMs are not without their drawbacks. Chief among them is slippage, meaning that the price a trader sees in the pool is different from the price they will actually have to pay for their swap.
Suppose a user decides to remove 0.1 ETH from the pool we imagined earlier. Simple arithmetic would tell them that the pool currently values 1 ETH at 3,000 USDT (since its current balance of liquidity is 10 ETH and 30,000 USDT, and 30,000/10 = 3,000). Therefore, they might assume the price for 0.1 ETH would be 300 USDT (0.1 * 3,000). But the price the user will have to pay for this ETH will actually be slightly higher, because of the constant product formula.
The transaction works as follows:
- The user authorizes the swap of 0.1 ETH for 300 USDT (current pool price)
- The AMM removes the 0.1 ETH from the pool, reducing x to 9.9 (10–0.1)
- Based on the new value of x (9.9), the AMM calculates what value of y is required to keep the value of k constant at 300,000
- If xy = k, then it follows that k / x = y. In this case: 300,000 / 9.9 = 30,303.03
- This means that for k to remain constant, 303.03 USDT must be deposited to the pool to balance the removal of 0.1 ETH (30,303.03–30,000)
- The AMM proceeds to swap 0.1 ETH for 303.03 USDT (actual price)
The problem here should be immediately obvious: the actual price paid by the trader is always going to be different from the current pool price (here, 303.03 USDT instead of 300 USDT). Generally, the larger the trade, the greater the slippage: e.g., if the user wanted to swap for 1 ETH, they would have to pay 3,333.33 USDT to keep k constant! Slippage in constant product AMMs is also directly affected by the amount of available liquidity, which means that pools with lower liquidity will experience higher slippage.
In addition to slippage, constant product AMMs are not terribly capital efficient, meaning that they do not make effective use of the investment deposited by LPs. In a simple constant product AMM, liquidity has to be distributed equally along the invariant curve from zero to infinity. This usually results in big chunks of liquidity sitting stagnant, since pricing and arbitrage will tend to keep trades away from either end of the price curve.
Stagnant liquidity is liquidity that isn’t earning fees for LPs. Ideally, an AMM would be able to make more of its managed liquidity available around the market price…
Concentrated Liquidity AMMs
In May 2021, Uniswap V3 set out to do exactly that by introducing concentrated liquidity: LPs could now choose to concentrate their liquidity in custom price ranges (called buckets) and earn fees from any swaps that take place within that range. If the swap price moves outside of an LP’s defined bucket, they cease to earn fees until such time as the swap price returns to the range or until they reallocate their liquidity.
We can immediately appreciate the difference between V2 and V3 by comparing the two graphs below:
The graph on the left is the familiar invariant curve created by a constant product AMM (e.g., V1/V2) that automatically distributes liquidity within a pool in order to preserve the constant value of k. The graph on the right represents notional liquidity distribution in Uniswap V3, with liquidity concentrated by LPs within a certain zone. This concentration of liquidity flattens a section of the curve so that the slope is more constant, along which the price of y remains more stable (compared to the invariant curve). Traders can effectively make swaps on this slope with low-to-zero slippage.
Theoretically, concentrated liquidity solved both of the problems endemic to constant product AMMs: high slippage and low capital efficiency. But there were some trade-offs, too. The concentrated liquidity model demands active management by LPs if they want to keep their capital active, and there are many Uniswap V3 pools where liquidity is severely misallocated (leading, of course, to high slippage for traders).
The need to manage liquidity actively and intelligently is increased because of the heightened risk of impermanent loss (IL) in a concentrated liquidity pool: with more liquidity available at the market price, arbitrageurs can trade more of an asset before the price moves. When this occurs, it is usually figured as a loss for LPs, who could potentially have profited more from simply HODLing (stay tuned for a Mav 101 post all about IL!).
Many LPs find themselves having to resort to third-party tools or services to manage liquidity for them. Otherwise, they risk losing out to institutional investors who can bring greater resources and superior strategy to bear in the competition to capture fees. Moreover, Uniswap V3 has been shown to be vulnerable to just-in-time flash maneuvers, where bots add liquidity to a pool and remove it in the same block in order to grab a share of trading fees.
Other Variations of AMM
One interesting twist on the constant product AMM is the weighted pool offered by Balancer.
The expected norm for a constant product AMM is that a trading pool will start from a point of equal weight between two assets (i.e., the ratio of their value will be 1:1, or 50/50 as Balancer calls it), and that LPs will add equal values of both assets when they provide liquidity to the pool. If a Balancer pool is weighted 50/50, it simply behaves like a constant product pool.
But Balancer’s weighted pools also give LPs the option to add liquidity to pools that are weighted more towards one asset than the other (e.g., 80/20, or even 95/5). Theoretically, this can help protect LPs from IL, since the weighting of one asset over another will limit volatility in the price of the first asset.
For example, an LP who wishes to stake an ETH/DAI pool may be bullish about ETH (i.e., they believe the value of ETH is going to increase compared to DAI). In that case, they will expect the price of ETH in an ETH/DAI pool to increase as traders come to swap their DAI for ETH. Based on these assumptions, it makes sense for the LP to stake a weighted pool (e.g., 80/20), where there is a significantly larger quantity of ETH present and the price impact of the expected trades will therefore be lower.
If LPs make the right decision between weighted pools, they can collect fees on their stake while limiting their exposure to IL. This does not come without a cost, however, since these asymmetric pools will also incur high slippage for traders, due to the limited liquidity of one of the assets in the pair. Moreover, weighted pools require LPs to adopt the right strategy if they want to maximize returns, requiring more market knowledge and foresight than other AMMs.
Curve V1 presents a clever combination of a constant sum AMM and constant product AMM. It launched in August, 2020, and was designed to facilitate the swapping of stablecoins such as USDT, USDC, and DAI.
All stablecoins are designed to have a fixed, equal value, and thus the goal of a stablecoin AMM should be to minimize slippage as much as possible, since traders will naturally seek out the market that offers them the closest to 1:1 pricing they can get on their swaps. Curve V1 accomplished this by developing an AMM that included a central constant sum portion within what is otherwise a constant product curve.
Curve V1 uses Uniswap V3’s concentrated liquidity model, but while the constant slope portion of a Uniswap V3 curve can move about in response to LP’s moving their buckets, a Curve V1 slope is always pegged in the middle.
The resulting curve is a good solution for facilitating swaps between stablecoins, since it has extremely low slippage for trades occurring in the central zone. But it is limited in its utility, since it is not designed to work for non-pegged asset pairs.
Maverick AMM
One way of looking at the story of DeFi is as a journey to optimize constant product AMMs. These original AMMs enabled the rapid scaling of decentralized and permissionless trading–from simple swaps to more complicated derivative products–but had problems with capital efficiency and slippage. Many players have iterated on the constant product AMM to find solutions to these problems, but these have invariably come with trade-offs, usually involving increased complexity and higher IL risk.
Maverick believes we have designed a solution that will offer DeFi everything it wants without compromise. Maverick AMM is similar to Uniswap V3, but with an important difference: Maverick AMM natively automates the dynamic movement of concentrated liquidity in order to get the best of both worlds–lower slippage than non-concentrated models but lower IL than other concentrated models.
By intelligently shifting the liquidity concentration in response to market activity, Maverick AMM ensures there is always a strong supply of liquidity around the market price. What’s more, Maverick AMM doesn’t require active liquidity management by LPs, freeing them from the need to compete with each other to collect returns on their investment. Click here to learn more about Maverick AMM!
DISCLAIMER: The information provided in this Medium Post pertaining to Maverick Protocol (the “Project”), its crypto-assets, business assets, strategy, and operations, is for general informational purposes only and is not a formal offer to sell or a solicitation of an offer to buy any securities, options, futures, or other derivatives related to securities in any jurisdiction and its content is not prescribed by securities laws. Information contained in this Medium Post should not be relied upon as advice to buy or sell or hold such securities or as an offer to sell such securities. This Medium Post does not take into account nor does it provide any tax, legal or investment advice or opinion regarding the specific investment objectives or financial situation of any person. The Project and its agents, advisors, directors, officers, employees and shareholders make no representation or warranties, expressed or implied, as to the accuracy of such information and the Project expressly disclaims any and all liability that may be based on such information or errors or omissions thereof. The Project reserves the right to amend or replace the information contained herein, in part or entirely, at any time, and undertakes no obligation to provide the recipient with access to the amended information or to notify the recipient thereof. The information contained in this Medium Post supersedes any prior Medium Post or conversation concerning the same, similar or related information. Any information, representations or statements not contained herein shall not be relied upon for any purpose. Neither the Project nor any of its representatives shall have any liability whatsoever, under contract, tort, trust or otherwise, to you or any person resulting from the use of the information in this Medium Post by you or any of your representatives or for omissions from the information in this Medium Post. Additionally, the Company undertakes no obligation to comment on the expectations of, or statements made by, third parties in respect of the matters discussed in this Medium Post.