The Ultimate DEX Landscape: An Open Source Compilation

Overview

Let’s dive into a brief overview of the current taxonomies and categories of DEXs available:

In general, there are 4(+1) typologies of DEXs:

1. AMM (Automatic Market Makers)
2. CLOB (Central Limit Order Book)
3. Oracle based
4. RFQs
5. Aggregators

AMM

Automated Market Makers (AMM) DEXs are the most common and the ones that achieve the highest volumes. They evolved from a simple constant product formula between two assets: y*x = k, with

• x: asset 1
• y: asset 2
• L = k^(1/2): liquidity

Liquidity providers (LPs) would put a fixed proportion of 2 assets into a pool and earn fees when people trade against the pool. This model has 2 big shortcomings:

1. Very capital inefficient: Since liquidity is equally spread across a price range from 0 to infinity, you need a large amount of liquidity to allow efficient trading.
2. Expensive: To attract large liquidity, fees need to be high. However, low fees would translate to low liquidity, leading to high slippage (i.e., a big price difference between the beginning and the end of a trade due to a large change in the relative composition of the pool) and, again, expensive trades.

The current generation of the most common AMMs introduced solutions to mitigate these problems:

• Concentrated liquidity: Each LP can select a price range where to provide liquidity, leading to higher capital efficiency. This system, however, requires an active management of the position to be really effective, which is expensive and technically complex.

• Multi assets: Generalises on the x*y=k formula to allow for multiple assets within a single pool. This gives LPs more flexibility in selecting the exposure the exposure they want to the different assets.
• Stable Swaps: reduces slippage for assets which are pegged to each other (e.g., DAI-USDT-USDC)

• PMM (Proactive Market Maker): Builds on the constant product formula by including external price information (e.g., from an oracle). In this way, the resulting price from a transaction will be closer to the market price even when the pool is off balance. This reduces slippage and impermanent loss.

CLOB

A Central Limit Order Book (CLOB) is how traditional exchanges and centralised exchanges work: with an orderbook of limit bids and asks to allow efficient price discovery. This system requires high throughput and cheap transaction costs. Only Solana has the necessary technical specs for this to happen fully on chain at the moment, with Serum being the main example. Non-Solana CLOB DEXs use a mixed solution, where the orderbook is kept off-chain and only the trade settlement is broadcast to the blockchain. Asset custody is still always in the hands of the user, though it lacks full transparency on the matching engine.

Oracle

These DEXs operate taking the current market price from an external oracle. This can require the participation of external actors running keeper nodes that periodically update the smart contract to maintain price alignment (e.g., GMX) or opting for a fully decentralized solution by taking the price from others AMMs (e.g., OpenLeverage). While third parties allow closer alignment with CEXs, they also expose the protocol to potentially devastating price manipulations (e.g., what happened with Mango Markets).

RFQ (Request for Quotation)

Trading on this type of DEX resembles an automated OTC desk. The user first asks for a quotation to buy or sell a currency. The market makers, on the other side, compete for the trade by sending their quotes. This system is MEV-resistant, has no slippage, and tighter quotes (e.g., Hashflow).

Aggregators

Aggregators are not DEXs in strict sense, rather they build on top of them: routing orders across and usually providing some level of slippage and price optimisation (e.g., 0x) . They prove particularly useful when submitting large orders, since liquidity will be sourced in multiple venues.

Known problems and proposed solutions

Today’s top DEXs all have some common problems like high trading costs and low capital efficiency. AMMs struggle with Impermanent Loss and Just-In-Time attacks, while Oracles face manipulation. Some protocols have introduced extra features to their core DEX to improve traders and LP experience, and address these problems. Here are some interesting ones:

Anti Just-In-Time Attack

When a trade is waiting to be executed in the mempool, it is possible for MEV players to front run this event and create an instantaneous LP position to absorb the whole trade and gain a disproportionate amount of trading fees, leaving little or nothing to the honest LPs who provide constant liquidity to the pool. Some AMMs introduced a time vesting factor to trading fees to discourage this behaviour, such as KyberSwap.

Impermanent Loss Protection

Impermanent loss happens when the relative price of the assets inside a pool changes in respect to when an LP initially contributed to it. This loss can be substantial and outweigh the fees generated by providing liquidity. Protocols, such as THORSwap, are providing incentives to protect against this and ensure that LPs are rewarded for their contribution.

Limit orders

Limit orders ensure that the orders are executed only at a given price or better. This is a standard feature of all CLOB exchanges and in now present also in several DEXs, like SushiSwap.

Crosschain liquidity

Some multi-chain DEXs are able to source liquidity not only on the chain where the order is generated, but across their whole network, like KyberSwap.

TWAP

TWAP executes an order along a determined time interval, instead of with a single order. This should help mitigating market impact, such as on Frax Swap.

Leveraged LP

By integrating the DEX with a lending pool, LPs to increase their position with borrowed asset. Leveraged Yield Farms are available on DEXs like MeshSwap.

Gasless

Currently this option is offered only by Dfyn. The protocol is built on top of the Biconomy SDK which allows it to prepay for all transactions that users submit on the DEX.

CLOB integration

Several protocols on Solana are built on top of Serum, creating a centralized order book where different DEXs provide and take liquidity and improving overall market efficiency. GooseFX is an example.

The Future of DEXs

Like many other developing models, different DEXs are “better” depending on your purpose— whether as a liquidity provider or trading. There is no clear “good” or “bad” model, but rather, it depends on how the user wants to use one or many of them.

Currently, the lines between the different types of DEXs are blurring, where newer DEXs are combining the attributes of the previously delineated categories into one. So perhaps, in the future, rather than being many individual types of DEX, there will be one DEX with many features.

The dynamic list of DEXs above can be filtered by type, asset classes, formulas, and other features. It is a living document so we invite the ecosystem to continue adding and sharing changes.