Constant-function market makers (CFMM) are a paradigm in the design of trading venues where a trading function and a set of rules determine how liquidity takers (LTs) and liquidity providers (LPs) interact, and how markets are cleared.
In CFMMs, both conditions state that price formation happens only through LT trades (see below).
In decentralized platforms running on peer-to-peer networks, CFMMs are hard-coded and immutable programs implemented as Smart Contracts,[3] where LPs and LTs invoke the code of the contract to execute their transactions.
A particular case of CFMMs are the constant product market makers (CPMMs) such as Uniswap v2 and Uniswap v3 where the trading function uses the product of the quantities of each asset in the pool to determine clearing prices.
Assume that the liquidity pool of the CFMM initially consists of quantity
is referred to as the reserves of the pool (the following definitions can be extended to a basket of more than two assets[5]).
The trading function is continuously differentiable and increasing in its arguments (
For instance, the trading function of the constant product market maker (CPMM) is
Other types of CFMMs are the constant sum market maker with
The quantities to exchange are determined by the LT trading condition: where
is the depth of the pool[2] (see the LP provision condition below) and is a measure of the available liquidity.
, akin to the midprice in a limit order book (LOB), is the price for an infinitesimal trade in a CFMM: It is proven that no roundtrip arbitrage in a CFMM implies that the level function
[2] LP transactions involve depositing or withdrawing quantities
The LP provision condition requires that LPs do not change the marginal rate
Note that the LP provision condition holds for any homothetic trading function.
[2] For LPs, the key difference between the traditional markets based on LOBs and CFMMs is that in LOBs, market makers post limit orders above and below the mid-price to earn the spread on roundtrip trades, while in CFMMs, LPs earn fees paid by LTs when their liquidity is used.
Without fees paid by LTs, liquidity provision in CFMMs is a loss-leading activity.
[1] One source of PL is the convexity cost (losses due to adverse selection, they can be regarded as generalized LVR) whose magnitude depends on liquidity taking activity and the convexity of the level function.
PL shows that liquidity provision generates losses for any type of LT trading activity (informed and uninformed).
The level of fee revenue must exceed PL in expectation for liquidity provision to be profitable in CFMMs.
[9] Impermanent loss compares the evolution of the value of the LP's assets in the pool with the evolution of a self-financing buy-and-hold portfolio invested in an alternative venue.
More precisely, the alternative buy-and-hold portfolio is not exposed to the same market risk as the holdings of the LP in the pool, and the impermanent loss can be partly hedged.
In contrast, PL is the predictable and unhedgeable component in the wealth of LPs.
[1] Concentrated liquidity is a feature introduced by Uniswap v3 for CPMMs.
The key feature of a CPMM pool with CL is that LPs specify a range of exchange rates in which to post liquidity.
The bounds of the liquidity range take values in a discretised finite set of exchange rates called ticks.
Concentrating liquidity increases fee revenue, but also increases PL and concentration risk, i.e., the risk of the exchange rate exiting the range.
[10] An early description of a CFMM was published by economist Robin Hanson in "Logarithmic Market Scoring Rules for Modular Combinatorial Information Aggregation" (2002).
[11] Early literature referred to the broader class of "automated market makers", including that of the Hollywood Stock Exchange founded in 1999; the term "constant-function market maker" was introduced in "Improved Price Oracles: Constant Function Market Makers" (Angeris & Chitra 2020).
[12] First be seen in production on a Minecraft server in 2012,[13] CFMMs are a popular DEX architecture.