Decentralized Exchange Designs: Order Book Model Vs. Automated Market Maker (AMM)

Decentralized exchanges (DEXs) have emerged and evolved over the past few years to provide a solution to issues that have long plagued centralized exchanges (CEXs). These issues include hacks, lack of privacy, deposit limits, intermediary issues, and high fees.

DEXs eliminate the middleman and allow users to trade directly from their wallets in a non-custodial manner. However, DEXs also present a unique opportunity with regards to the trade execution model. The two most prominent models of exchange design often center around the order book model and the automated market maker (AMM). This article will provide a breakdown of both of these trade execution models and explain the key differences that can impact trading experiences.

The Order Book Model

Central limit order book (CLOB) is a trade execution model that matches orders from buyers and sellers based on a set of rules. The key difference between trading on a AMM- or a CLOB-based exchange is the mechanism of fair price formation at which the trade is going to be executed. For instance, exchanges that run a centralized order book rely on an aggregated list of buy and sell orders submitted by traders on a given pair. CLOB allows traders to either bid (buy) or ask (sell) an asset at a specified price.

The difference between the highest bid and the lowest ask is called the spread. Markets with high liquidity have much smaller spreads, since the depth of demand and supply at each price level is high.

Injective matches orders based on the Frequent Batch Auction (FBA) model which accepts orders over a discrete period of time (the auction interval) and fills them according to priority. The optimal batching interval for FBAs has been academically reported to be between 0.2 and 0.9 seconds, which falls in line with Injective’s auction interval with batch auctions executing at the end of each block. The instant finality feature of Tendermint’s BFT-based PoS consensus (which Injective is based on) corresponds startlingly well to FBA executions at the end of each block.

Market makers as liquidity providers

A key feature of order book models is that they allow users to submit two types of orders: a market order or a limit order.

A market order occurs when a trader buys or sells at the best market price instantly, thus pairing a buyer with a seller who currently has orders at the top of the book. The highest bid and lowest ask constitute the best available market price of a given asset.

On the other hand, in a limit order, traders buy or sell tokens at a specific price, but the order is not executed instantly and sits in the order book until it is filled. Central limit order books rely on market makers (MMs) to provide liquidity by placing a list of limit orders on both sides of the trade. Market makers will receive a net positive fee rebate to incentivize liquidity and the distribution of the said fee will take place periodically through snapshots. By submitting limit orders at more granularized price levels, MMs reduce the spread size. Therefore, the lower the trading volume, the wider the spread.

Pros:

Order book exchanges are ideal for liquid markets
Order book exchanges remain optimal for surfacing market prices and placing large orders
Order book exchanges reduce the risk of slippage
Order book exchanges are widely accepted by both institutional and retail traders alike

Cons:

An individual cannot trade if their highest bid is lower than the lowest ask, which presents a poor design for illiquid markets
Order books typically face the risk of front-running. Front running is the risk of miners being able to mine a particular block obtained from information provided when an order is placed. This means that miners can earn a risk-free profit. However, Injective will be the first exchange protocol to completely eliminate front-running by utilizing the FBA auction model.

The Automated Market Maker (AMM) Model

Liquidity is one the most prominent barriers in DEXs. Even though tokens are difficult to exchange efficiently, AMM designs come in handy in solving this problem. It acts as a bot for quoting prices at any time users wish to trade two assets. While the theory behind an AMM has existed for a long time in academic game theory and mechanism design circles, its application in the crypto market is recent.

Unlike an order book that specifies prices at which buyers and sellers wish to trade, an AMM exchange aggregates liquidity for both sides of a trading pair into a pool. The AMM pool then determines a single market price according to a deterministic algorithm. The price formula is usually based on the pool’s current liquidity, or in other words the availability of an asset in the pool.

AMMs do not require market makers, but rather heavily rely on liquidity providers to join the pool and expand its size to ensure that tokens reflect a fair price.

Various AMM DEXs use different mathematical formulas to quote prices for their liquidity pools. Let us consider the XYK formula pioneered by the Uniswap exchange as an example. In its original form in Uniswap V1, the price was calculated based on the ratio of the two assets in the pool as follows:

x*y=k (constant)

The constant k represents the total token balances in a liquidity pool that determine the token prices, x, and y at a given time. Let us assume that x = ETH and y = INJ. Each time users buy ETH, the price of ETH increases as the quantity of ETH in the pool decreases. Conversely, the price of INJ decreases as the number of INJ increases. Liquidity pools often provide arbitrage opportunities that can be exploited for a profit.

Let us assume that 1 ETH = 100 INJ at the time of the trade via a pool which has 10 ETH and 1000 INJ. If a trader wants to buy 2 ETH, they would need to swap 200 INJ for 2 ETH, leaving the pool with 8 ETH and 1200 INJ. The price of ETH is now 150 INJ causing impermanent losses (temporary losses of funds) for liquidity providers.

ETH = 1200/8 = 150 INJ

It is important to highlight arbitrage as a stabilizing mechanism, which incentivises traders to push the price determined by the AMM exchange closer to the spot price present in other exchanges. Expanding upon the example above, arbitrageurs can exploit this vulnerability and buy 2 ETH from a different market for a fair price of 200 INJ and sell them for 300 INJ in this liquidity pool. This would bring the price level of 1 ETH back to 100 INJ.

Front-running is more prevalent on AMM exchanges opposed to CLOB exchanges. A recent audit of Uniswap revealed that front-running can take place through two attacks.

Attack One: Moving the market against the trader

Public blockchains are fully transparent meaning that everyone can view buy and sell orders before they are successfully executed. In an algorithmic market, an attacker can leverage the blockchain's transparency and execute a transaction in front of another trader by setting a higher gas fee. The actors who influence the order of transactions in a block will affect the outcome of a given trade. This poses a huge challenge in crypto markets as arbitrage bots leverage this inherent vulnerability.

The process-flow of front-running in an algorithmic ETH/INJ market would take place as follows:

1. Alice wants to buy 1 ETH at price x with gas price y

2. Bob views this transaction on the blockchain

3. Bob pays gas price z where z > y and buys 100 INJ at price x

4. Alice's transaction goes through but she receives only 90 INJ for 1 ETH

5. Alice's transaction caused the asset's price to move upwards

6. Bob sells 100 INJ, making a profit in ETH

Attack 2: Sandwiching large traders with mint and burn

In this second attack, the malicious user observes trades on the blockchain and "sandwiches" a given trade x with mint/burn calls with a large position relative to the size of the pool. Therefore, the attacker extracts a substantial proportion of the LP fees of trade x without being exposed to inherent risks of providing liquidity in a pool such as impermanent loss.

To summarize, the AMM design presents different sets of tradeoffs:

Pros:

Liquidity is present for otherwise illiquid markets
AMMs enables traders to always get a price quote on their asset, regardless of the number of active orders submitted to the exchange

Cons:

There is a risk of high slippage for large orders due to small liquidity pools
Capital inefficiency, since most of the trades are executed within a narrow range of price levels unless the market is extremely volatile
Risk for liquidity providers, such as impermanent loss as described above
Higher risk of front-running compared to the CLOB trade execution model

Conclusion

These two approaches to designing exchanges offer a unique set of advantages and tradeoffs.

Order book exchanges currently dominate the market for voluminous tokens such as Bitcoin and Ethereum. On the other hand, automated market makers will help users to receive the best possible price on long-tail illiquid tokens.

The Central Limit Order Book has become mainstream among the largest traditional exchanges such as NASDAQ as it’s arguably the most capital efficient and transparent trade execution model. Even though prominent barriers such as front-running and wide spreads have prevented DEXs from adopting the CLOB model, Injective stands as a pioneer that rectifies both using its unique FBA model. The FBA model provides MMs with ample time to cancel stale orders before high frequency traders can execute them. In addition to sustaining rapid transaction times the Injective exchange model is able to tighten spreads with higher liquidity closer to the market price.

About Injective

Injective is a lightning fast interoperable layer one blockchain optimized for building the premier Web3 finance applications. Injective provides developers with powerful plug-and-play modules for creating unmatched dApps. INJ is the native asset that powers Injective and its rapidly growing ecosystem. Injective is incubated by Binance and is backed by prominent investors such as Jump Crypto, Pantera and Mark Cuban.