.png)
.png)
Is this only due to their implementation? No. Major trading venues in traditional finance use central limit order books (CLOBs) to manage trades. On the other hand, more than 90% of all trades on DEXs are matched on the dealer-based model of automated market makers (AMMs) (see here). This post highlights the essential differences in market making dynamics between AMMs and CLOBs, and showcases why CLOBs provide users the best capital efficiency, market liquidity, and user experience.
What is a Central Limit Order Book?
Let’s quickly recap the definition of a central limit order book. You can refer to our primer on the
basic mechanisms of AMMs here.
ZA CLOB facilitates the creation of a market for exchanging any type of assets, for example, tokens. To achieve this, the traders’ orders are stored in an order book, and a matching engine transacts the orders according to a set of rules. More precisely:
- Central Limit Order Book: Market participants specify the quantity, the price, and the side (buy or sell) in their limit orders. The CLOB stores the buy orders and sell orders as bids and asks in the book (see Figure 1). Traders can replace, modify and cancel them at any time. When, for example, a new buy order arrives with a price which is equal or beyond the best ask price, the order is immediately transacted (“taker order”) at the best ask price, and the filled quantity on the ask side is removed from the order book. On the other hand, if the bid price is less than the current best ask price, then the new buy order (“maker order”) is added to the order book, behind other limit orders at the same price.
- Matching Engine: this component defines the rules to transact the orders. Limit order books commonly employ a price-time priority system (“continuous limit order book”), which first ranks orders by price and then by the time they arrive at the order book. Orders are transacted respecting this priority rule. As a side note, C3’s matching engine will be based on a continuous double auctions model to evade front-running issues (more on that below).
C3’s Off-chain Matching & On-chain Settlement
As discussed in our previous post, a complete on-chain CLOB implementation leads to severe performance limitations and to high fees which impede market making activities. An on-chain CLOB over Ethereum immediately reaches its limits, and even high performance L1 or L2 chains (e.g. Solana or Polygon) can hardly provide the infrastructure to run a CLOB completely on-chain while guaranteeing the trading experience in TradFi.
In order to provide a first-class trading experience, C3 runs the order book and matching engine off-chain. Traders cryptographically sign their order operations, where only the off-chain filled orders are sent to the Algorand blockchain (with transaction finality of under 4 seconds). The validity of the trades is approved or disapproved, and account balances are updated accordingly. This design, which is similar to dYdX and StarkEx/0x, allows for trustless and non-custodial trading, since any trade execution occurs on-chain and requires the user’s signature. Before tackling censorship-resistance and decentralized order matching, priorities are set on improving the DeFi experience to TradFi standards. Nevertheless, all trade events will be transparent from the beginning, and correct matching behavior can be verified by anyone using cryptographic accumulators.
Major Differences between CLOBs and AMMs
Let’s walk through some aspects which work differently when comparing CLOBs with AMMs on a high-level. When it seems appropriate to make a further distinction between on-chain CLOBs and C3’s hybrid CLOB implementation, we make that explicit.
Slippage refers to the difference between the average execution price of a trade and the market price of the asset before the trade. In plain words, when the trade becomes executed, the trader may end up with a higher execution price than the market price might suggest. In CLOBs and AMMs, slippage depends on the size of the trade. In a CLOB, however, market orders are transacted against counterparties' limit orders resting in the order book, and the average execution price is dependent on the bids and asks at the top of the order book. In contrast to this, in an AMM based DEX the execution price is determined algorithmically according to a formula (e.g. product formula; see our last post). The price impact of a trade is completely deterministic depending on the trade size, the pricing curve, and the reserve sizes (“inventory”) of the AMM.
This difference in price making radically changes the market makers’ activities. But before getting to this point, a note on the inventory dependency: Most AMMs use convex pricing curves as a protection against a complete exhaustion of one of the reserves (see our last post). If a reserve size tends to zero, the price of this token becomes prohibitively high. The problem arises when the market price on the primary market moves. In order to adapt to the new price, the inventory has to change, meaning that one of the reserves shrinks, which causes higher slippage for orders at the new price level (see Figure: todo). This kind of “artificial” economic reason for slippage is not present in CLOB based exchanges. Market makers adjust their bids and asks according to the movement of the token value without (necessarily) changing slippage. Another important driver for high slippage in AMM designs relies again on their specific price discovery mechanism. This leads to the next difference.
Capital efficiency refers to the ratio of the executed trading volume and the liquidity provided. In AMMs liquidity providers deposit tokens into a reserve pool which holds the capital to swap trade orders immediately. Therefore, capital for trades at prices far above the market must be reserved, although these trades are very unlikely to occur. This strongly reduces capital efficiency, and increases slippage. In CLOBs, most liquidity “sits” close to the current market price on the bid and ask side, and does not reserve capital for unrealistic price levels as in the case of AMMs.
Concentrated liquidity in Uniswap V3 is an attempt to tackle this problem. LPs can define a price range mimicking – in some sense – limit orders. Unlike limit orders, range orders stay active independent of being transacted once, and LPs provide liquidity as long as they close their range orders. Ironically, this brings us back to where we started from: an order-driven model, though with different market making strategies (cf this article for first simple strategies such as resetting the range each time the price moves outside a certain range).
Liquidity provision ensures that an asset can be converted or swapped to another asset without affecting its market price. In traditional CLOB based exchanges, trading firms use advanced technology and run sophisticated market making strategies to provide liquidity. They choose a spread around the token price, and are incentivized to keep it close to the fundamental token value, since they earn a profit each time their orders are filled. In AMMs, however, liquidity providers deposit tokens into the reserve pool and incoming orders are transacted immediately against the reserve at the algorithmically determined prices. LPs earn passive income from the trading fees charged on each executed swap. For mature markets, it is not really questionable that order books, where many market makers constantly compete about the best prices, provide better market liquidity than any single market maker approach (e.g. based on the product formula) can achieve.
In both designs, liquidity providers’ profit depends on the operational costs. This aspect made on-chain CLOBs obsolete since any order operation would charge a fee. In the case of AMMs, another very important aspect has to be considered. Arbitrageurs monetize the fact that an AMM does not know the current price at the primary market. This information cost comes at the expense of the LPs in the form of impermanent loss (see our last post). LPs simple passive liquidity strategy generates no payoffs (not taking the fees into account) if prices end where they started, but loses money if prices diverge. In Figure 2 one can see the dimension of net loss for LPs in Uniswap V3.
AMMs are a good ready-to-use solution to create markets of new illiquid tokens. Nevertheless, thin markets usually are very volatile and have an increased risk of impermanent loss. Even for markets with high trade volumes, LPs’ loss can often only be compensated by additional protocol token earnings which in the long run cannot be a sustainable solution.
Front-running is a challenge for either market structure. It refers to the race between messages (swap, take order, cancel order etc.) changing the order of their arrivals. In blockchain applications the main cause of front-running lies in the nature of how transactions are processed by the validators (or miners). More precisely, by setting higher transaction fees (or due to their own interest), validators give higher priority to some pending transactions over others which are stored in the so-called mempool. This causes a serious problem for blockchain applications, and is (partly) captured under the term Maximal Extractable Value (MEV). In AMMs it allows for “sandwich attacks” which seriously harm retail and institutional traders: hundreds of millions in USD volume for MEV per day is used on Ethereum (see here). In short, in such a scenario the attacker places a large buy order just before the trader’s order by setting a higher fee. As a result, the token price increases (here the deterministic price discovery comes into play), and after the retail trader executed his order at the higher price, the attacker reverses his trade making a profit on the cost of the retail trader. Although there are ways to lower the risk of such attacks, in C3’s CLOB based exchange design with an off-chain matching engine, this type of front-running through validators is not even present. Nevertheless, front-running due to infrastructure latencies needs a solution since it can harm market makers who commit liquidity. They run the risk that after a price jump on the primary market, they are left with a stale order that can be taken by other faster traders (“snipers”). C3 addresses this problem by a continuous double auction model for the matching engine which greatly reduces such arbitrage rents.
C3’s Take Summarized
- CLOB based DEX: Retail and institutional traders can experience on a mature CLOB based market the best liquidity and lowest slippage. Moreover, market inefficiencies and arbitraging which are intrinsic to the AMM design cause a huge drawback for liquidity providers due to the resulting impermanent loss they suffer. On a CLOB, this problem is not present, and market making strategies can be run enjoying all customizable order types known from TradFi. C3 allows for capital delegation which can be leveraged by less professional traders to delegate capital to trading experts.
- Hybrid CLOB: This is the only architecture which allows for a performant trading venue competing with TradF, without making any compromise on trustless and non-custodial trading. It also avoids the serious problem of front-running through validators which cost the traders over the past years millions of dollars. Moreover, C3’s matching engine is based on a frequent batch auction model taking care of any front-running related to sniping.
