Uniswap v2 AMM Math
This article is a gentle mathematical introduction to Uniswap's market maker. before we get into the working of the model, let's look into why it was needed in the first place.
The Problem
Tradfi exchanges use an order-book mechanism to settle trades. This system relies on institutional market makers to provide liquidity to the system where they make money on the bid-ask spread [1]. Unfortunately, the order book mechanism doesn't translate well to a decentralised system such as ethereum due to several reasons, most importantly –
Latency: Ethereum can support ~15 transactions per second with a block time of 10-19 seconds which is too slow from a performance and scalability perspective.
Gas costs: Every operation on the ethereum blockchain requires gas [2] and a traditional market making mechanism involves high-volume of cancellation and re-submitted orders to maintain liquidity and a fair price for the asset. To replicate this on ethereum would mean spending a significant chunk of money on gas, which would increase trading costs for users and transaction costs for market makers to provide liquidity and avoid wide spreads.
The Solution
The solution to this problem came in the form of liquidity pools [3] which were widely popularised by uniswap. A liquidity pool is essentially a collection of locked funds used to facilitate certain operations using smart contracts— in this case trading. With liquidity pools, market makers are replaced by liquidity providers (LPs) and anyone can become an lp by adding funds to a pool. Uniswap provides LPs with tokens proportional to their share in the pool which can be burnt later to redeem their liquidity. LPs are incentivized to add funds by earning trading fees for providing liquidity.
These pools replace conventional order-books in DEXs (decentralized exchanges) by forming a collective source of liquidity. Uniswap v2 pools contain equal values of both tokens and LPs are incentivized to add tokens of equal values since they risk losing capital to arbitrageurs if this is not the case. from a trading perspective, Uniswap prices these assets in the liquidity pool using automated market makers (AMMs) [4] which can be described as protocols that price assets algorithmically without the need for any counterparty. These AMM algorithms can be complex and are implementation-specific. Uniswap v2 uses a constant product market maker model, with the invariant where and are the quantities of two tokens in the liquidity pools and is the invariant product that must remain constant.
To understand how this model prices an asset and facilitates a trade, let's run through a trade on uniswap.
Swapping Tokens with Uniswap
Consider a liquidity pool of token pair and holding reserves and respectively at the moment. the invariant for this pool is the product of quantities of these tokens which should remain constant over time. Simply put, you can exchange tokens of using this pool for tokens of such that so that the invariant product of the quantities of two tokens in the pool remains constant. Solving the previous equation for it can be seen that we get tokens of in exchange for tokens to ensure that the invariant holds true.
This hyperbolic graph for the constant product equation also defines the pricing model thus implemented by the market maker. In this case, the marginal price is the derivative of the curve . this mechanism is eponymously called the constant product market maker and is a major feature of Uniswap v1 and v2.
While the above equations represent the ideal case, uniswap charges users a 0.3% fee per trade which still needs to be factored into these calculations. This fee is added to the liquidity pool reserves and forms the incentives for LPs to provide liquidity. Let's see how this fits into the original equation. Once again, assume that you wish to swap tokens of for tokens of to a uniswap pool which currently holds tokens of and tokens of .
When you trigger this swap, Uniswap first collects its trading fee – assume that the fee rate (as part of total exchanged value) is and . accordingly, after this fee collection, you're left with tokens of which are to be swapped. The remaining are out of the equation for now, but we'll get to them later. We now go back to our original product invariant, but the equations are slightly modified, we add of tokens instead of the original tokens. putting this in the original equation solving for —
So in this case we get a lesser bang for our buck, owing to the fees lost earlier. The fee component is now added back to the pool and the total reserves now stand at tokens of and tokens of , with the updated value of as computed above. This implies that product is not constant but actually increases gradually over time with every trade. The difference here forms the incentives given to LPs which can be claimed when they burn their liquidity tokens.
For a detailed formalization of this model and it's implementation you can refer to the Uniswap whitepaper [5] and the formal model specification [6].