Liquidity Pool

Abstract

Liquidity pool is a virtual container of funds deposited(Locked) on smart contract by liquidity providers. In exchange, liquidity providers receive LP tokens representing their share in the pool in proportion to how much liquidity they supplied to the pool.

Context

With standard cryptocurrency exchanges or traditional stock markets trading is based on the order book model. In this model buyers and sellers come together and place their orders.
In purpose of making a transaction, seller and buyer have to reach an agreement on the price, which often means that seller has to lower price, while buyer has to rise bid. And that creates a space for misunderstandings and disagreements. Way to avoid this kind of situation is engaging market makers, who always willing to buy or sell assets. Thanks to that, liquidity to the market is provided, and the users can always trade and do not have to wait for different offer to come up.
Unfortunately, implementing this solution into decentralized world wouldn’t work well, because it would be slow, expensive and unpleasant to the users.
Need of something more fitting brought liquidity pools to life.

Setting up a pool

Liquidity Pool in its basic form holds two tokens and each pool creates a new market for that particular pair of tokens. Within yield.vote we use FVT/ETH pools.

When the pool is created, balance of both tokens are 0. To start working, someone has to seed a pool with initial deposit for each token. This someone is a first provider, who sets initial price of the pool and initial ratio between tokens.
Let’s see this over an example:

Example

Carl wants to deposit funds into ETH/FVT pool. He wants to add 1 ETH worth 1000 USD and 1000 FVT worth 1000 USD. Market algorithm obligates that both values of tokens must be equal. As can be easily observed, Carl deposited tokens are worth 2000 USD at the moment of depositing into the pool.

Carl was providing liquidity into the pool which was already existed, and even though he wasn’t the one who makes an initial deposit, he still had to follow the rule of providing equal token values into the pool.

Yes, we now that what are you thinking right now is: but why?
Initial price of deposit token is set in the moment of setting, that means ratio between FVT and ETH is taken from current global market price. Obviously, because prices there are dynamic, there is a certainty that value of ETH or FVT will change next day, hour or even minute which creates arbitrage opportunity.

Example

Let’s stay with Carl a little longer. He provided liquidity into the pool but now market price of ETH has changed, which caused arbitrage opportunity. Because of that, arbitrage traders wants to buy ETH in exchange for FVT until the pool ratio reflects the current market price.

Note

Remember that ratio of the pool changes through LP deposits or trades, and is strictly connected to the amount of tokens in the pool. Also pool ratio determines the price of the assets in the pool.

Probably are you wondering why user need to put both tokens?

Right, that’s another thing. To provide liquidity in the pool, there must be enough amount of both tokens. That is ensured by a constant product maker algorithm, which formula is depicted below:
../../_images/const.png
x,y - reserves of tokens, A and B
k - constant

Thank to this mathematic check, we may be sure that a pool can always provide liquidity, regardless how large a trade is. The main reason for this is that the algorithm asymptotically increases the price of the token as the desired quantity increases(so trying to buy all tokens from the pool is a tremendous and, to be honest, impossible challenge).

Imagine you would like to withdraw ETH from the pool, let’s say this would be token A. When you take out of the pool some amount of one token, the balance breaks and the constant k changes. To prevent that, you would have to put some FVT (token B) into the pool to maintain balance. As parameter x changes, y changes as well.
It’s worth to mention that the k parameter will change anyway due to fees of transaction, which has small impact on the k value, but this shouldn’t concern user since k parameter needs to be maintained before fees.

Liquidity Pool Tokens

As mentioned in the beginning, liquidity providers receive LP tokens representing their share in the pool in proportion to how much liquidity they supplied to the pool.

To encourage users to become liquidity providers, every pool has a transaction fee, which is distributed to LPs upon completion of the trade. Fees vary depending on the pool, but the principle remains the same, that is transaction fees are distributed proportionally to all LP token holders in the pool.

Because LP tokens are themselves tradable assets, their holders may sell, transfer and use it in any other way they see fit.

In purpose of retrieving underlying liquidity (plus any fees accrued), users must “burn” their liquidity.

Price impact

Because ratio of the tokens in the pool dictates prices of assets, then buying ETH from the pool will decrease amount of it in the pool, while increase amount of the FVT in it. That transaction will reflect in prices of ETH and FVT.
Current market price in the pool always shows only marginal token price, while in practice, a trader buy or sell more than one token at once. And as ratio of tokens dictates prices, every token taken out or put into the pool will affect price of the next token.
This difference between the current market price and the execution price is called price impact.
Change of the prices depends on the size of the trade, in proportion to the size of the pool. The bigger the pool is, the lesser price impact is.

Price impact is a function of the trade size relative to the liquidity pool size.

Note

It’s worth to remember that large(deeper) pools can take bigger trades without significant price impact.

Example

Imagine you want to buy 3 apples. You go to the local fruit market and there are only two farmers. Because you are the mathematic maniac, you want a product of multiplication of <fruit amount> and <money farmer has on hand> to be constant. But also you want to pay as little as possible.

  1. first farmer has 5 apples and 10$ in the hand. So constant would be 5 * 10 = 50

    1. You take 3 apples: 5 - 3 = 2

    2. To keep the constant: 50 = (5 - 3) * x

    3. x = 25

    4. So you have to add to farmer hand 15$ (he had 10$ in the beginning, 10 + 15 = 25) to keep the constant on the initial level.

  2. second farmer has 78 apples and 100$ in the hand. So constant would be 78 * 100 = 7800

    1. You take 3 apples: 78 - 3 = 75

    2. To keep the constant: 7800 = (78 - 3) * x

    3. x = 104

    4. So you have to add to farmer hand 4$ to keep constant on the initial level.

So the best deal is to buy apples from the second farmer, because to keep the constant on the initial level, you would only have to pay 4$ for 3 apples, while with the first farmer it was 15$.

But let’s stay a little longer on this to clear up price issue. We keep rule of constant alive (price increases as apples amount decreases).

First farmer has 5 apples and 10$ in the hand. If we calculate price of the first apple simply dividing 10$ / 5, then we got 2$, which would be wrong, since 4 * 12$ = 48 while we need to keep the constant on the same level, which is 50. However, that is actually the way of calculating a ratio between apples and dollars, so that makes it a market price.
Anyway, we need to calculate as we did before: (50 / (5 - 1)) - 10$ = 2,5$, and that is the execution price of the first apple, which means that is exactly what you will have to pay.
Out of that we can simply calculate, that price impact is 25%, because 2,5$ is 25% higher than 2$.

Let’s do the same for the second farmer. Market price is a ratio between apples and dollars, so 100$/78 = 1,2821$
But as we calculate execution price, we got (7800/ (78-1)) - 100$ = 1,2987$
Price impact in this case is 1,2948%.