The Future of On-Chain Trading

It’s been more than 5 years since the first comment on “Automated Market Makers” (AMMs) was published to r/ethereum and nearly 4 years since the first real implementation of the x*y=k went live. In that time, there’s been more than a dozen variations of AMMs deployed with live trading and full functionality to trade without a centralized entity on the backend. In that 4 year span, we’ve seen more than a trillion dollars in volume traded across a number of exchanges and AMMs quickly became one of the most used venues for trading in crypto. Yet as we’re seated here looking out to the future of not only a multi-DEX world but a multichain one, where the expansion of trading mechanisms are still being questioned.

The Showdown

Thankfully across the years there’s been a lot of fruitful discussions arguing extremely specific aspects of the Central Limit Order Book (CLOB) and AMM technical frameworks. Instead I’ll offer a simple walk-through and a friendly pros/cons list as well as an explanation of the inevitable future of on-chain trading. But first a brief into how these two work on a fundamental basis:

CLOBs are the most dominant form of order books historically. Every centralized exchange entity, whether it’s in traditional finance or in crypto, uses a CLOB. At a glance, a central limit order book allows a user to place (for simplicity’s sake) 2 unique types of orders: limit orders and market orders.
AMMs are the newest type of orderbook as they’re increasingly used in decentralized trading. Unlike CLOBs, AMMs are constantly streaming a quote of prices to users and only exist (again for simplicity’s sake) with 1 type of order: market orders.

In addition to understanding the importance of the execution mechanism of AMMs, it’s also important to understand why they were created. Ethereum, being the largest decentralized network, has some limitations as a network. Gas fees and public broadcasting being the two largest contributors. For a CLOB, gas fees would be incredibly expensive to constantly adjust orders and place other orders, but this isn’t what we’ll focus on, instead we’ll focus on the issue of frontrunning.

In a fully decentralized orderbook, every transaction has to be publicly available for everyone to see. This isn’t a problem when you’re only executing market orders but when you need to place limit orders to seed liquidity for an asset to create a market, it becomes a big problem to always know where and when someone is bidding or selling. If a large trader is seeking to enter a specific market and placed bids or an automated bid based on time (TWAP order) then the execution would be streamed to the entire market, leaking their information and likely leading to frontrunning problems. In the traditional and centralized worlds, orders are generally obfuscated from the end market participant but in the decentralized market, everyone can peer into market activity. “How do we allow users to trade in a decentralized market without letting the whole world know where people are placing limit asks and bids?”

Enter AMMs. Simply put, AMMs operate differently by allowing any user to pool capital and be a market maker and forces every participant to use the same quoting mechanism for both the bid-side and ask-side. By quoting at every price level in a 50/50 pool you’re able to solve the problem of being the known liquidity provider at a specific price. The problem instead becomes that every order must be executed on market and slips edge to the “market maker”, as they have to cross the spread in order to execute an order and pay above the market rate instead of being able to quote above or below for bid and asks, respectively. (Visuals for both liquidity depths are in the Appendix)

The Darker Horse

For all the love that AMMs and CLOBs get, there’s a dark horse in the race for best mechanism for execution, pricing, and privacy; RFQs. The 0x team has already written a terrific piece on RFQs so I won’t regurgitate their example instead a simple breakdown of the mechanism. RFQs use large market makers and trading desks as a backend for liquidity and optimally price larger orders. In their best instance, they can provide a much more robust crossover between centralized exchange liquidity (CLOBs) and decentralized pricing mechanisms (AMMs) to create a hybrid model that gets best execution for traders, via API. Think of it as a 1inch smart order router for cross platform liquidity. Simply put, RFQs are really freaking quality.

So how does this all stack up and is there a world where they all make sense? When thinking about execution there are two major considerations about a specific trade to put on: size and market cap (correlation/volatility). We can see an amended breakdown, from the 0x team, of these two contributors to trading activity and mechanisms.

Simplified further:

CLOBs are best for any size and low correlation
AMMs are best for any size but nearly perfect correlation
RFQs are best for large size with moderate correlation

The Finale

“In the grand scheme of things, what importance is there for anyone trading – why should anyone outside of a market maker care?”

It’s important to remember the original context of this piece being on Ethereum. While Ethereum is a beautiful world of decentralized architecture, it’s not the only chain anymore and with a new landscape of chains, it’ll become increasingly important to understand the technical capabilities of each chain. The thought behind a multichain universe in and of itself is a rejection of AMMs being a panacea to all on-chain trading. Looking deeper at different chains with differences in consensus mechanisms and block finality, it becomes clear that there needs to be a tailor-made approach to each chain and abstraction to the end user. It’s hard to imagine any chain that doesn’t have the limit that Ethereum has to build an AMM as the first iteration of an on-chain trading mechanism. Instead I imagine the future will end up looking much more like a hybrid of the various settlement mechanisms and power users will likely have to understand the distinct differences between each when pushing size on the screen. Even within the Ethereum marketplace of decentralized execution, we’re seeing the eventual state of AMMs starting to mimic more of their CLOB counterparts.

For protocol developers and trading experts on new chains, it’s going to not only be imperative to build the most robust trading system but also explaining the differences between each and why the specific mechanism makes the most sense for their chain. In addition, overcomplicating a trading system for the sheer benefit of users being comfortable with the ordering mechanism will likely end up being a large problem for the trading userbase. If you don’t have to, don’t. The end state of trading on-chain, whether it’s spot or derivatives, will likely not be a system of market orders that are constantly losing edge to liquidity providers. Instead, we will likely continue reaching equilibrium between AMMs, CLOBs, and RFQ systems (in some variation) that will offer both the best spreads and most liquidity. It’s still the early innings of our decentralized landscape, product iterations will consistently disrupt existing ideologies of trading and the best products and teams will understand that working towards efficiency will end up being the winning ticket.

Appendix:

AMM Model, shows a constant linear pricing function: