What are liquidity pools? How do they work? Why are they needed in decentralized finance?

Also, what are the differences between liquidity pools across different protocols such as UniSwap, Balancer, or Curve?

I'll be going through all of this in this article!

🤽 What are the liquidity pools?

All right, so let's talk about liquidity pools. Liquidity pools, in essence, are pools of tokens that are locked in a smart contract. They facilitate trading by providing liquidity and are extensively used by some decentralized exchanges, a.k.a. DEXs.

One of the first projects that introduced liquidity pools was Banker, but they became widely popularized by Uniswap.

Before I explain how liquidity pools work under the hood and what automated market making is, let's try to understand why we even need them in the first place.

If you're familiar with any standard crypto exchanges like Coinbase or Binance, you may have seen that their trading is based on the order book model. This is also how traditional stock exchanges such as New York Stock Exchange or Nasdaq work.

In this order book model, buyers and sellers come together and place their orders. Buyers, a.k.a. bidders, try to buy a particular asset for the lowest price possible, whereas sellers try to sell the same asset for as high as possible for trades to happen.

Both buyers and sellers have to converge on the price. This can happen by either a buyer bidding higher or a seller lowering their price.

But what if no one is willing to place their orders at a reasonable price level? What if there are not enough coins that you want to buy?

This is where market makers come to play.

In essence, market makers are entities that facilitate trading by always being willing to buy or sell a particular asset. By doing that, they provide liquidity so the users can always trade and don't have to wait for another counterparty to show up.

Okay, so can we do something like this in decentralized finance?

The answer is we can. But, unfortunately, it would be just slow, expensive, and always result in a poor user experience.

The main reason is that the order book model relies heavily on having a market maker or multiple market makers willing always to make the market in a particular asset.

Without market makers, an exchange becomes illiquid and is pretty much unusable for regular users. On top of that, market makers usually track the current price of an asset by constantly changing its prices, which results in a considerable number of orders and order cancellations being sent to an exchange.

Therefore, Ethereum, with a current throughput of around 12 to 15 transactions per second and a block time between ten and 19 seconds, is not a viable option for an order book exchange.

On top of that, every interaction with a smart contract costs a gas fee, so market makers would go bankrupt by just updating their orders.

📈 How about using an L2 for scaling?

Some of the L2 projects like Loopring look promising, but they are still dependent on market makers and can face liquidity issues.

On top of that, if a user wants to make only a single trade, they would have to move their funds in and out of the L2, which adds two extra steps to their process.

This is precisely why there was a need to invent something new that could work well in the decentralized world. And this is where liquidity pools come to play.

👷‍♂️ So, how do liquidity pools work?

Now that we understand why we need liquidity pools in decentralized finance let's see how they work in their basic form.

A single liquidity pool holds two tokens, and each collection creates a new market for that particular pair of tokens. DAI can be an excellent example of a popular liquidity pool on Uniswap.

When a new pool is created, the first liquidity provider is the one that sets the initial price of the assets in the pool. After that, the liquidity provider is incentivized to supply an equal value of both tokens in the pool.

Suppose the initial price of the tokens in the pool diverges from the current global market price. In that case, it creates an instant arbitrage opportunity that can result in lost capital for the liquidity provider.

This concept of supplying tokens in a correct ratio remains the same for all the other liquidity providers that are willing to add more funds to the pool later.

When liquidity is supplied to a pool, the liquidity provider LP receives special tokens called LP tokens in proportion to *how much liquidity they supply to the pool. *

When a trade is facilitated by the pool, a 0.3% fee is proportionately distributed amongst all the LP token holders (that fee can change on each DEX).

The liquidity provider must burn their LP tokens if they want to get their underlying liquidity back, plus any accrued fees. Each token swap that a liquidity pool facilitates results in a price adjustment according to a deterministic pricing algorithm.

This mechanism is called an automated market maker (AMM), and liquidity pools across different protocols may use a slightly different algorithm.

For example, basic liquidity pools, such as those used by Uniswap, use a constant product market maker algorithm that makes sure that the product of the quantities of the two supply tokens always remains the same.

On top of that, because of the algorithm, a pool can always provide liquidity, no matter how large a trade is. The main reason is that the algorithm asymptotically increases the token's price as the desired quantity increases.

🧮 What is the math behind the liquidity pools?

The math behind the constant product market maker is pretty interesting, but to ensure this article is not too long, I'll save it for another time.

The main takeaway is that the ratio of the tokens in the pool dictates the price.

So if someone, let's say, buys it from a DAI pool, they reduce the supply of ETH and add the supply of DAI, which increases the price of ETH and decreases the price of DAI.

How much the price moves depends on the size of the trade in proportion to the size of the pool. The bigger the pool compared to a trade, the lesser the price impact, a.k.a slippage.

So large pools can accommodate more significant trades without moving the price too much because larger liquidity pools create less slippage and result in a better trading experience.

Some protocols, like Balancer, started incentivizing liquidity providers with extra tokens for supplying liquidity to specific pools. This process is called liquidity mining, and we might dedicate an article only about that in a future post.

The concepts behind liquidity pools and automated market making are simple yet extremely powerful. We don't have to have a centralized order book anymore, and we don't have to rely on external market makers to keep constantly providing liquidity to an exchange.

Uniswap uses the liquidity pools that we just described, and they are the most basic forms of liquidity pools.

Other projects iterated on this concept and came up with a few exciting ideas.

Curve, for example, realized that the automated market-making mechanism behind Uniswap doesn't work very well for assets that should have a very similar price, such as Stablecoins or different flavors of the same coin, like WETH or SETH curve pools. Hence, they found that implementing a slightly different algorithm can offer lower fees and lower slippage when exchanging these tokens.

Another exciting idea for liquidity pools came from Balancer, which realized that we don't have to limit ourselves to having only two assets in a pool. And in fact, Balancer allows for as many as eight tokens in a single liquidity pool.

🚀 Some final thoughts

This is a quick talk about liquidity pools since the math behind them is fantastic. Currently, many projects are working on implementing more features and new ways to manage them (even with new algorithms like UniSwap V3).

But I hope that at least, with this article, you now have a better idea of how they work and why they are crucial for developing the DeFi tools!

So what do you think about liquidity pools? Feel free to place a comment!

✅ Follow my socials!

- Twitter: https://twitter.com/thenaubit