A breakdown of the two exchange designs: which makes more sense for your token's liquidity?
Liquidity is the most important characteristic of a well-functioning Secondary market. Liquid markets will allow your project’s stakeholders to trade tokens efficiently and may also positively influence community-wide sentiment for your protocol. In the time immediately following your TGE up until your protocol achieves a sufficient degree of decentralization, bootstrapping Secondary market liquidity needs to be a top priority.
Simply put, liquidity is the appetite of patient buyers to purchase an asset and the appetite of patient sellers to sell an asset. Liquid markets allow investors, protocol participants, and traders to buy & sell what they want, when they want, with minimal transaction costs.
Patient traders who provide liquidity allow others to trade aggressively, with immediacy and minimal market impact. In this sense, individuals who provide liquidity create positive externalities in the marketplace.
Poor liquidity conditions can catalyze an awful user experience for stakeholders aligned with a blockchain project. Buyers can’t buy, and sellers can’t sell without adversely moving the market. Market impact causes rampant volatility and may catalyze negative price performance despite no meaningful change to a protocol’s fundamentals or underlying issues with the project.
When a buyer or seller places an order to provide liquidity on a traditional centralized or decentralized exchange (“CEX” or “DEX”), the order is categorized in a file called a central limit orderbook (“CLOB”). When visualizing a CLOB and the liquidity organized within it, the most common illustration is a depth chart. A depth chart represents an asset's cumulative buy-side and sell-side depth at various price levels. See below for a visualization of liquidity being provided on a CLOB depth chart:
The green area of the above depth chart shows patient demand to buy a token, while the red area shows the patient supply of sellers. The Y-axis shows the quantity of tokens, and the X-axis shows the price per token. When market participants come to trade on a CLOB, they are either takers or makers, with takers being those to “take” liquidity and makers being those to “make” liquidity. For instance, if token ABC is trading at $8.5 and I want to buy one token, I go to an orderbook and see the lowest price I can buy the one token for (as I’m a profit-motivated actor). After going to the orderbook, I see that the lowest price someone is asking for one ABC token is $8.6 (this is the “ask”) — this means that this seller placed a limit order to sell one ABC token at $8.6 and consequently “made” liquidity. Subsequently, I “take” this liquidity by bidding for 1 ABC token at $8.6. Since exchanges want more liquidity on their orderbook, i.e., more makers (of liquidity), they charge lower fees for orders that make liquidity and higher fees for orders that take liquidity (whether it be on the bid, i.e., buy-side or sell, i.e., ask-side).
Usually, liquidity on orderbooks is provided by market makers (MMs), who quote (i.e., place bids and asks) near but not at the current price to make a profit from the spread between the bid and the ask (bid-ask spread as it’s called). So,in the example above, excluding fees, the seller, i.e., the MM, pockets $0.1 as that was the difference between the market price and what I bought from the MM.
In contrast, when liquidity is provided on a DEX or, in some cases, a CEX powered by an automated market-making (“AMM”) protocol, the assets are deposited into a liquidity pool (“LP”). At its core, a liquidity pool is a shared pot of tokens. Instead of trading at defined prices as you would on a CLOB, users on an AMM swap directly with the LP. A mathematical formula determines the price of the tokens involved in the swap. The most common formula popularized by Uniswap v2 is:
tokenA_balance(p) * tokenB_balance(p) = k
or
“x * y = k”.
The constant, represented by “k” means a constant balance of assets determines the price of tokens in the LP — this is why x * y = k. AMMs are called constant product AMMs For example, if an AMM LP holds token ABC and token XYZ, every time token ABC is bought, its price increases as there is less ABC in the pool than before the purchase. Conversely, the price of token XYZ goes down as there is more XYZ in the pool than before the purchase. The LP stays in constant balance, where the total value of token ABC in the pool will always equal the total value of Token XYZ in the LP. There are also other AMM formulas, i.e., designs like concentrated liquidity AMMs (clAMMs). But we won’t get into that for now. It's a newer iteration of the AMM idea but with increased capital efficiency.
A common misconception for blockchain projects is that marketplace metrics such as liquidity and volume are unrelated to their protocol functionality and therefore have no impact on the future success of their project. This couldn’t be further from the truth. A lack of liquidity can negatively influence a token’s performance and erode the monetary value of token incentives. Without token incentives, most protocols will struggle to achieve widespread decentralization.
There are three major ways that a lack of liquidity can impact a token:
First, a lack of liquidity can result in runaway price depreciation of your token. For example, a lack of bid-side liquidity from patient buyers means that even small orders to sell your token will have a significant market impact. Existing token holders may perceive dramatic price shifts and large “red candles” on a trading chart as deteriorating fundamentals or a “flaw” in the underlying protocol. As a result, they may sell their tokens, thus catalyzing further price depreciation.
Second, illiquid markets are prone to low trading volumes, which are unlikely to attract speculative traders or convince new exchanges to list your token. Since buyers and sellers cannot trade at efficient prices, they are unlikely to interact; therefore, no trades are consummated, and no volume is conducted. With no promise of revenues from trading fees, CEXs are unlikely to list your token if it has low trade volume. Furthermore, many CEXs will de-list tokens with poor liquidity and low volume due to the poor user experience they provide their customers. DEX liquidity pools are also unlikely to attract liquidity given that minimal fees are generated from swaps, thus resulting in minimal revenue share to liquidity providers via yield farming.
Third, if you have really poor liquidity conditions, it can frighten existing investors and probably more likely deter potential investors. This is because existing investors will find it hard to exit their position without inducing significant price impact, and potential investors are deterred because they can't enter a position for the same reason.
For instance, imagine that a liquid fund/VC wants to deploy a large amount of capital. Based on their research, they believe the price of a dollar is significantly undervalued relative to the fundamentals that they've analyzed for the ABC token. Accordingly, they look to place a trade on their preferred exchange when they realize that they can only acquire a large amount of ABC tokens at a steep premium (take, e.g., $1.3 per ABC token). This party then will not buy ABC tokens, as they don't deem ABC to be undervalued at any price over $1.1 per ABC. In essence, you could be losing out on onboarding those potentially bullish investors if you have poor liquidity conditions.
As we’ve established, liquidity is king. It’s one of the most important aspects of a project’s token. But the question is, as a project, where do you want your liquidity to reside? It’s very important to know the answer to this pre-TGE, as projects often have a significant amount of their token distribution carved out for liquidity deepening initiatives, whether this be to engage market makers (more on market makers or “MMs” later), to provide liquidity on a CEX (e.g., Binance), or to have yield farmers deposit liquidity in a pool2 contract. Therefore, not having a clear idea of where to incentivize liquidity will result in suboptimal outcomes such as rewards and effort, and, subsequently, liquidity will be fragmented, giving traders suboptimal UX. For instance, if you incentivize the liquidity proposition of AMMs too heavily, you might not have enough tokens to engage MMs. Don’t get us wrong, though — you can have enough tokens carved out for both AMM liquidity incentivization and to engage MMs. However, it is still good to know ahead of time where efforts and resources should be allocated, which is what this blog post will help you do.
AMMs make it very easy for your community to provide liquidity. In a few clicks, a token holder can become a liquidity provider on an AMM without the need for active management of this position. This means that the holder can put his tokens to use, earning trading rewards and potentially token emissions from the project (pool2 rewards).
From the project's POV, these AMMs act as a supply sink for the token, taking tokens off the market to induce upward price movements. However, with AMMs (especially constant product ones which appeal to communities, i.e., retail) LPs face adverse selection risk, leading to what is known as impermanent less (IL). This is the main cost for LPs of providing liquidity (in other words, LPs have a downside to providing liquidity, which means that trading fees plus any additional pool2 rewards must compensate for this cost to make providing liquidity appealing). However, a better way to quantify the cost for LPs is by computing loss-versus-rebalancing (LVR). a16z puts it well:
“Liquidity providers in automated market makers suffer losses from adverse selection, which is part of the price of doing business as an LP. By virtue of offering to take either side (buy or sell) of a trade at a given price, every LP in an AMM runs the risk of taking the wrong side of a trade by a trader with better or more recent information about a token’s market price. For example, if the price of ETH on the open market suddenly increases, a speedy arbitrageur may buy ETH from an AMM (at a stale, lower price) and resell it on a centralized exchange like Binance (at the new, higher market price), pocketing a profit. Because there are only two types of participants in an AMM, profit to traders must correspond to losses to LPs.”
Essentially, due to information asymmetry in these markets, LPs take on a loss due to toxic orderflow, which in this case is orderflow coming from participants with more information than the LP (for instance, arbitrageurs know the price of said asset across different markets, i.e., venues, and can take advantage of the discrepancy in these prices at the expense of the LP by arbitraging them — resulting in a cost for the LP).
For those interested in understanding LVR, refer to this article. We tend to think of LVR as impermanent loss plus an opportunity cost for providing liquidity. For now, though, we will quantify the cost of providing liquidity as the impermanent loss faced by LPs.
The problem with impermanent loss is that you can’t tell what it will be ahead of time. It depends on the volatility of one asset in the pool against the other. For instance, take an example of an AMM for ETH and BTC (ETH/BTC) — if ETH goes up 100%, but so does BTC, LPs don’t have any cost to provide liquidity (in other words, IL is zero).
Now, if some token ABC goes up 200% and ETH goes up 50%, that causes LPs to bear a 5.72% loss — it’s called impermanent because if ETH and ABC both go back to initial price levels (when the LP deposited both tokens), the LP is back to bearing zero loss. You can play around with the IL numbers for any x * y = k pool (for example, on certain DEXs like Balancer, you can configure your pool so that your token represents 70% of the notional value in the pool, while some other token like ETH constitutes the rest) here.
If you’re a project that wants to incentivize/seed/understand how to optimize AMM liquidity provision, we suggest taking the following points under consideration:
Most often than not, you do not need to have a dynamic reward schedule for the pool2 (which is your token paired against a base asset like ETH, USDC, USDT, etc.) to ensure that rewards combined with trading fees are higher than potential impermanent loss. This is because impermanent loss cannot be predicted and because the market will naturally find an equilibrium quantity of liquidity in said AMM. Since, as a project, you will be allocating “X” tokens to emitted per slot, essentially a block (say 12 seconds like on Ethereum) over a certain timeframe (e.g., 1000 ABC tokens will be carved out for pool2 rewards over 12 months), the yield will be a function of the price of ABC and the TVL, i.e., liquidity in the pool. This means that if the market anticipates a high impermanent loss and provides less liquidity, then the 1000 ABC rewards over the 12 months are shared with less liquidity in dollar terms, implying a higher APY, which is an incentivize for LPs to take on said IL risk and provide liquidity. In this way, the market will find an equilibrium. As a project, all that needs to be done is to allocate a certain amount of tokens to pool2 rewards over a certain amount of time, and let the market determine what a fair amount of liquidity is for the pool.
If you’re a project building on Solana, pair your token against SOL. If you’re a project building on Ethereum, pair your token against ETH — why? A few reasons: firstly, if you’re building a project on a certain base layer, chances are that the stakeholders of the project (LPs, team, etc.) are bullish on the base layer’s future and, by extension, its native token, just like they are the project’s token. If stakeholders like LPs anticipate both tokens (the base layer’s and the project’s native token) to go up in price over the long term, chances are that the IL they’ll have to bear would be less than if the project’s token was paired against USDC, which will not move in tandem with the project’s native token’s price. Holders of said project’s native token usually view that token as a high beta play relative to the base layer’s token, which automatically means they should provide liquidity for the project’s native token against the base layer’s token. Apart from the fact that this little change can drastically reduce IL for LPs (making liquidity provision more attractive and allowing said project to spend fewer tokens to acquire liquidity), it also means that the paired asset for the project’s native token is also one of the most liquid tokens in the entire base layer’s economy (SOL has some of the highest levels of on-chain liquidity on Solana, ETH for Ethereum, and so on). This means that users (traders in this case) will have a great UX when buying or selling the project’s native token, as the base layer asset is easy to acquire and desirable to swap into when selling the project’s native token.
As mentioned above, IL is hard to predict and model. However, by using our token designer (completely free!), you can attempt to model your token’s price action. This can clue you in to what potential IL for LPs can look like, allowing you to carve out more or fewer tokens to incentivize liquidity provision based on potential costs for LPs.
Try launching your token on a “fast,” i.e., low-latency network (e.g., Solana/Arbitrum/Optimism) if possible. Doing so will drastically increase your pool's profitability of LPs. This is because, ceteris paribus, the shorter the block times on said network, the lower the LVR for LPs.
Take, for example, a blockchain on which XYZ token is issued. Also, imagine this blockchain has one-week block times (a hypothetical scenario). So you’d imagine that in that one week, a lot of off-chain trading would happen for XYZ. At the end of every week, arbitrageurs can close the price discrepancy of XYZ on the DEX (which resides on said blockchain with 1-week block times) and off-chain (e.g., on a CEX). Besides the clear fact that longer block times push trading off-chain to venues that provide instant settlement and hence better UX (e.g., Binance), it also clearly causes more LVR to LPs, as elucidated in the above example.
Now imagine a blockchain with 24-hour block times. Every 24 hours, an arbitrageur can come onto said DEX trading XYZ and close the CEX<>DEX price discrepancy. In this example, LPs will roughly make ~7x what LPs would on the blockchain with 7-day block times. Therefore, as you keep reducing the block time, arbitrageurs can close price discrepancies (arbitrage the XYZ pool) more frequently, subsequently paying more fees to LPs to rebalance (i.e., arbitrage) the pool and making them (the LPs) more profitable.
If you’re a relatively big project, it’s worth looking into owning your AMM curve. What if you forked the Uniswap v2 contract and took a portion of the protocol's trading fees (a few basis points) while avoiding Uniswap governance overhead?
Currently, Uniswap v2 pools don’t take a portion of trading fees for the Uniswap protocol (i.e., all 30 basis points of trading fees go to LPs). However, Uniswap v2’s parameters are subject to UNI governance, which is pushing harder and harder to implement a fee switch (that directs some protocol fees to the Uniswap DAO). This is value extractive from protocols incentivizing liquidity provision on said Uniswap pool. Owning your AMM curve allows you to decide what to do with the fees (give 100% to LPs or give a little bit to stakers of the native token?).
Furthermore, owning your AMM curve also avoids Uniswap governance overhead (if a proposal passes tomorrow to increase trading fees to 100 basis points, would you want your liquidity to still be hosted on Uniswap?) and gives control of these parameters to your protocol’s DAO governance, which can introduce an avenue for value accrual for your token.
Owning your AMM curve can prove to be straightforward. A potential scenario for the following can look like this: fork the Uniswap v2 contract (fun fact: Uniswap, as seen below, is the most forked protocol in all of DeFi), allow trading for your token through your UI, and get integrated with a DEX aggregator (like 1inch) where most of the orderflow (trading) originates anyway (orderflow originating from the DEX aggregator will route through your smart contract hosting liquidity).
Unlike AMMs, liquidity provision on CLOBs is often highly specialized, only appealing to market makers (MMs) and HFTs, which are highly specialized institutions with many proprietary trading strategies to provide liquidity while staying profitable. Most of the liquidity you see, especially for new launches, comes from MMs. Projects engage these institutions to create liquid markets for their token, which, as explained above, is crucial for your token.
At the core of optimizing liquidity provision on CLOBs is engaging the right MMs for your needs with the right structures (to align incentives and deter the relationship from going parasitic). A great example of a badly structured MM engagement can be found in the case of WLD’s (Worldcoin) TGE. As highlighted by Kaiko Research, almost all of the WLD tokens generated at launch (TGE) were loaned to MMs (at the time, these tokens were worth ~$220 million), yet ±1% liquidity depth (i.e., the amount of liquidity near the current prices) was a mere $3 million.
It’s also important to note that market makers can deplete your stablecoin balance by trading unintelligently, crush your token price by engaging in predatory practices, and more. Navigating the market maker landscape without prior knowledge or experience is a recipe for disaster.
This blog post only aims to give a high-level overview of both AMMs and CLOBs, their differences, drawbacks, advantages, and other considerations. Many factors affect the decision on whether to go down the AMM route or the off-chain CLOB route through a CEX. However, the fact of the matter is that both AMMs and CLOBs have their unique advantages, and there is no one-size-fits-all approach to determining the right strategy for a project. Often, a mix of initiatives to strengthen both on-chain AMM liquidity and off-chain orderbook liquidity with well-structured market maker arrangements is the best way to go.