# Sifchain: AMM Specification

## Summary

In this analysis we focus on the economics of the automated market maker with special attention to fees.

The attached notes from the [Thorchain documentation](https://docs.thorchain.org/how-it-works/continuous-liquidity-pools#slip-based-fee-model-clp) provide notation for and rudimentary analysis of uniswap style, constant product automated market makers.

These notes address the constant fee model which exists in Uniswap and an alternative fee model in use by Thorchain. It goes on to identify the canonical form of all contemporary KYC AMM DEXes.

The note addresses the concept of virtual depth but provides no analysis thereof.

We focus our attention on the composition between the swapping mechanisms and the add/remove liquidity mechanisms. More complex fee structures may introduce unintended consequences in the form of "path planning" attacks that involve carefully sequencing (eg sandwiching) swap actions with add/remove liquidity actions to save on fees.

## Definitions

In this section, we will rely on the definitions as represented in the Thorchain documentation for ease of collaboration, although in future documents we use slightly different (more signal processing and control theory oriented) notation in our work on the subject.

### State Space

Consider a positive orthant with coordinants $(X,Y)$ where $X,Y>0$. We will let $X$ denote the prior quanitity of the token to be swapped into the AMM and $Y$ to be the prior quantity of the token to be swapped out. The action taken by a trader is denoted $x=\Delta X$ and the results number of tokens to be issued to the trader in the output of this transaction is $y=\Delta Y$.


### Actions available

While the focus of this note is on the swapping mechanism, that mechanism is dependent on the existence of an add/remove liquidity mechanism. For simplicity we will assume that the add/remove liquidity mechanism is a simple linear price preserving mechanism.

#### Adding and removing liquidity
Denote the price with units $Y$ per $X$ as $P = \frac{Y}{X}$, then adding liquidity can be modeled as simply adding $(x,y)$ such that $\frac{Y+y}{X+x} = \frac{Y}{X} = P$. Noting that in practice adding liquidity in only one token is supported but its a functional composition of this primitive with the swap primitive. Adding liquidity issues liquidity tokens (such that supply expands proportional to the increase in liquidity). Additionally they may be burned to withdraw $(x,y)$ such that $\frac{Y+y}{X+x} = \frac{Y}{X} = P$ with the $x=\alpha X<0$, and $y=\alpha Y<0$ where theta is the share of the total supply of liquidity tokens beeing burned.

#### Swapping
The swap primitive is explored in detail in this note but may be summarized in its general form as:

Given a prior state $(X,Y)$ and the deposit action $x=\Delta X$, the swap mechanism will return a quantity of tokens $y = f(x; X,Y)$. In order for such a policy to be meaningful it is prudent to derive it as an invariant preserving map.

For simplicity in this note, we assume $x$ is added to the pool and $y$ is removed, but this can be reversed without loss of generality. Noting that the generality is lost when assymmmetry is introduced, eg. when synthetic depth is introduced.

In order to design practical invariants that preserve properties of interest to Sifchain, we rely on a range of metrics which are computable over the state-space and the set of valid actions conditioned on a point in that statespace.

### Some Metrics of Interest

Even with such a simple state space there are a range of metrics of interest which can be used to construct analytic invariants. Such invariant choices should not be arbitrary but rather determined based on the desired trader and/or liquidity provider user experience.

**(Prior) Spot Price** $$ P = \frac{Y}{X}$$
**(Posterior) Spot Price (for a swap)** $$ P^+ = \frac{Y-y}{X+x}$$
**Realized Price (for a swap x for y)** $$\bar P = \frac{y}{x} $$
**Price Slippage (normalized)** $$\frac{P-\bar P }{P} = 1-\frac{\bar P}{P}= 1-\frac{Xy}{xY}$$
**Liquidity Level** $$ K = X\cdot Y $$
**Pool Value (local, in X units)** $$ 2X= X+\frac{Y}{P} = X + \frac{X}{Y}Y$$
**Pool Value (3rd party $\hat P$)** $$X+ \frac{Y}{\hat P} $$
**Arbitrage Equality (3rd party $\hat P$)** $$x\hat{P}= y+\epsilon = x\bar P +\epsilon $$
**Arbitrage Profit (in Y units)** $$\epsilon = \frac{\hat P - \bar P}{\hat P}x$$

Note that when designing a fee structure it is important to look at KPIs associated with the user's experience, eg. slippage, impermanent loss, and arbitrage opportunities.

### Existing Designs

A brief review of existing designs with visuals

#### Constant Product Market Maker: No Fees


This is the base design that most people reason about because it is the most intuitive. This is an idealized uniswap model.

#### Constant Product Market Maker: Flat Fee


There is an [implementation of uniswap in cadCAD](https://github.com/cadCAD-org/demos/blob/master/demos/uniswap/simplified-uniswap.ipynb) and an [overview with video of the model](https://community.cadcad.org/t/modeling-uniswap-in-cadcad/35).

#### Thorchain "Slip fee" (CLP)


This can be viewed as setting the fee $\phi$ according a regularizing rule that penalizes slippage and thus larger transactions, incentivizing smaller transactions, but also introduces angles for gaming the system to minimize fees. The derivation can be found in the [Thorchain docs](https://docs.thorchain.org/how-it-works/continuous-liquidity-pools#clp-derivation).

Comparing:
$$y_{ff} = \frac{xY}{x+X}(1-\phi)$$

with
$$y_{clp} = \frac{xYX}{(x+X)^2} =\frac{xY}{x+X} \frac{X}{x+X}$$

so $$(1-\phi)=\frac{X}{x+X} = 1 - \frac{x}{x+X}$$

this is simply choosing a functional fee, as
$$ \phi = \frac{x}{x+X}$$

#### "Slip fee" with virtual depth


Has analogies to connector weights in [Bancor](https://medium.com/@billyrennekamp/converting-between-bancor-and-bonding-curve-price-formulas-9c11309062f5#) and to non-uniform pools in [Balancer](https://medium.com/balancer-protocol/bonding-surfaces-balancer-protocol-ff6d3d05d577).

#### Generalized Fees


For choice invariant $V(X,Y)$ determine $f(x;X,Y)$ such that for all $x>0$ we have
$$V(X+x, Y-f(x;X,Y))=V(X, Y)$$

In order to call it a fee relative to a constant product market maker, there needs to be value accrued to the liquidity proviers which is accomplied by

$$(X+x)\cdot (Y- f(x; X,Y))>X\cdot Y $$

It is also prudent to satisfy the boundary condition that the non-action yields no payout $f(0;X,Y)=0$ for all $(X,Y)$ as well as for the limit of the realized price to be the spot price:

$$\lim_{x\rightarrow 0^+} \frac{f(x; X,Y)}{x}= \frac{Y}{X} =P$$

that latter denoting that the realized price should approach the spot price as the transaction size get arbitrarily small.

It is also prudent to consider whether the fee mechanism damages the liquidity pool's capacity to function as an estimator. The mathematics of AMMs as estimators are minor variations on the mathematics for bonding curves as estimators as presented in this academic paper: [economic games as estimators](https://pdfs.semanticscholar.org/c1c2/2e06ac3fab0bfdf08bfc85a837da13fe16c2.pdf).