Liquidity

Decentralized Exchanges work on the premise that there are two sides of users: one group adds liquidity that can be bought while others sell their funds to get those funds that have been provided. Traders pay a trade fee which is given to the liquidity providers as to incentivize deposits.

Liquidity list

For each tradable currency on the DEX, there is a list of liquidity entries. When users add liquidity, the assets they are provided are sent to a dedicated module account. At the same time, a new entry is added to that currency's list of liquidity entries, indicating what amount of liquidity in the module address belongs to which address.

When executing trades and taking funds from the pool, funds are taken from the beginning of the list which is easiest computation-wise. When new funds are added, there isn't a new list entry created each time but new deposits are always added to the second entry. The reason for this is to create variety in which funds are used. Since it can be assumed that a lot of funds are held by the protocol itself, those liquidity entries would always be in first position. If funds where always taken from those entries, other liquidity would never be used. When adding at the end of list, liquidity deposits get more mixed.

// XKP liquidity
Address: kopi123, Amount 100

// List after new funds added by address kopi234
Address: kopi123, Amount 100
Address: kopi234, Amount 100 // No entry yet, so we add a new one at the end

// List after additonal funds added by address kopi123
Address: kopi123, Amount 100
Address: kopi234, Amount 100
Address: kopi123, Amount 100 // Added at the end of the list


// List after additonal funds added by address kopi123, again
Address: kopi123, Amount 100
Address: kopi234, Amount 100
Address: kopi123, Amount 200 // Added at the end of the list, but merged with existing entry

Positions

Apart from the wallet address, each deposit is also stored with an index as to keep track of individual liquidity deposits. Internally, those deposits are called positions. When adding liquidity users can decide whether they want fee income to be re-added to the DEX or sent to their wallets. It is also stored at what block height the position is created. That way, when users want to withdraw liquidity, the protocol knows which positions are old enough to be eligable for being withdrawn. This is to lock liquidity on the DEX for a certain amount of time.

Spread

The more liquidity there is when trading a currency pair, the less the spread is.

User sells 1 kUSD to buy USDC

// Example 1
Liquidity kUSD: 1000
Liquidity USDC: 10
Effectively used liquidity during trade: 10 kUSD + 10 USDC
Amount to receive when selling 1 kUSD: 0.91 USDC
Spread = 1 - (1/0.91) = -9.89%

// Example 2
Liquidity kUSD: 1000
Liquidity USDC: 1000
Effectively used liquidity during trade: 10 kUSD + 10 USDC
Amount to receive when selling 1 kUSD: 0.9999 USDC
Spread = 1 - (1/0.9999) = -0.01%

In the first example, there is very little liquidity for USDC, meaning for trading there is only 10 units of both currencies used. When giving 1 kUSD into the pool, the user receives 0.91 USDC. Given that both currencies are having the same value before trade, the user uses around 10% for this trade. In the second example there is much more liquidity present for USDC, the user receives 0.9999 USDC for 1 kUSD, thereby losing hardly anything to the spread.

Adding liquidity

As shown, adding liquidity can lower the spread when trading. This can have one unwanted side-effect that needs to be tackled:

Currencies with low liquidity have a high spread when trading and their prices are very volatile. This means, by trading small amounts a currency's price can be pushed high. When adding liquidity, more funds can be sold at a higher price due to the lower spread, thereby making a profit.

To counter that, added liquidity does not immediatly lower the spread. When deciding how much liquidity to use from each currency from a trading pair for price calculation, the protocol does not use the amount of liquidity from a pool but a value internally called MovingLiquidity.

// Example 3
Pool liquidity kUSD: 1000
Pool liquidity USDC: 10
MovingLiquidity kUSD: 1000
MovingLiquidity USDC: 10

// User adds 990 USDC liquidity
Pool liquidity kUSD: 1000
Pool liquidity USDC: 1000
MovingLiquidity kUSD: 1000
MovingLiquidity USDC: 10

At the end of each block, the MovingLiquidity gets updated to slowly adjust to the actually present amount. The old value is multplied by a factor (for example 0.99), while the new value is multiplied with the 1-factor, both values are then summed. The sum then represent the moving average value of the provided liquidity (thus the term MovingLiquidity).

When the price of a currency is pushed high (i.e. to a higher price level compared to other exchanges) and liquidity is added, the spread does not shrink and the higher price cannot be used to a bigger advantage (except selling funds to push it back to the "correct" value),

With MovingLiquidity, the fact that liquidity deposits are locked for a certain amount of time and trade fees the protocol ensures that price manipulatins