Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Liquidity provision

Given a liquidity pool consisting of two assets, A and B, and the invariant , where and are the amounts of the two assets in the pool (the "pool reserve"). For simplicity, we denote this as .

Suppose a user provides liquidity with amounts and . After the liquidity is added, the invariant value is . For simplicity, we denote this as .

Suppose before adding the liquidity, the supply of LP token is . We mint user new LP tokens of the following amount:

Here, is a fee rate we charge on the amount of LP tokens mint. Without this fee, the following exploit would be possible: provide unbalanced liquidity, then immediately withdraw balanced liquidity. This effectively achieves a fee-less swap.

The fee rate should be a function over , reflecting how unbalance the user liquidity is:

  • If user liquidity is prefectly balanced, that is, , fee rate should be zero: .
  • If user liquidity is prefertly unbalanced, that is, one-sided (e.g. but ), then the fee rate should be a value such that if the attack is carried out, the output is equal to doing a swap normally.

Our objective for the rest of this article, is to work out the expression of the fee function .

Fee rate

Consider the case where the user liquidity is unbalanced. Without losing generality, let's suppose . That is, the user provides a more than abundant amount of A, and a less than sufficient amount of B.

Scenario 1

In the first scenario, the user withdraws liquidity immediately after provision. He would get:

Here, is the portion of the pool's liquidity owned by the user. We can work out its expression as:

where , which represents how much the invariant increases as a result of the added liquidity.

Scenario 2

In the second scenario, the user does a swap of amount of A into amount of B, where is the swap fee rate, which is a constant. The swap must satisfy the invariant:

The user now has amount of A and amount of B.

As discussed in the previous section, we must choose a fee rate such that the two scenarios are equivalent. This means the user ends up with the same amount of A and B in both scenarios:

We can rearrange these into a cleaner form:

We can use the first equation to work out either or , and put it into the second equation to get .

Xyk pool

The xyk pool has the invariant:

Our previous system of equations takes the form:

TODO...