Introduction

Perpetual futures are one of the most traded instruments within crypto, with volumes that dwarf spot trading. These instruments enjoy greater parity with spot prices relative to futures and enable capital efficiency through leverage. However, most perp volume resides on CEXs. Despite the multitude of designs to try and bring perpetuals to DeFi, most still lack strong adoption. dYdX is an outlier, but they use a cheat code of sorts – a centralized order book and matching engine rather than an on-chain one.

GMX – an oracle-based spot and leveraged trading DEX – flipped the game by bringing the simplicity of perpetuals to leveraged trading. Of late, GMX has found a strong product-market fit with traders and liquidity providers alike.

GMX’s success has resulted in competitors attempting to replicate it with designs inspired by GMX. Mycelium (previously TracerDAO) and MUX (previously MCDEX) are two protocols designed very similarly to GMX. Mycelium is a direct fork of the GMX codebase with some changes, while MUX is not a fork – it’s using an adjusted codebase from a previous iteration of its product (MCDEX v3). With that being said, the current design is inspired by and competes with GMX.

Before comparing these protocols, we need to understand how the oracle DEX model works and why protocols are moving towards this model.

The Recipe for Oracle-Based DEXs

The success of GMX comes from its innovative liquidity pool index that consists of 50% stablecoins and 50% risk-assets (ETH, BTC, and other alts). Each of the tokens has a target-weight allocation. The pool acts as the liquidity source for all spot and leveraged trades. Oracle price feeds are then used to determine the execution price for trades. Each protocol handles its oracles differently. We’ll dive into specific differences in the next section.

Spot swaps on these platforms execute like an RFQ trade between LP assets. The oracle determines the price, and spot swaps execute without slippage – regardless of trade size. Swap fees are dynamically adjusted based on how the trade will affect the liquidity pool’s asset composition.

For example, ETH is at $1,400, and traders want to swap ETH for USDC.

Scenario 1: 1 ETH for 1,400 USDC with a 0.29% swap fee
Scenario 2: 10 ETH for 14,000 USDC with a 0.31% swap fee
Scenario 3: 1,000 ETH for 1,400,000 USDC with a 0.4% swap fee

Leveraged trading works similarly, with prices executed based on oracle price feeds with an extra open/close fee based on position size. The liquidity pool loans a certain quantity of an asset to a trader so they can achieve their desired leverage level. When traders lever up to the long side, they borrow the underlying asset from LPs. When a trader goes levered short, they borrow stablecoins from LPs. The trader pays LPs an hourly borrowing fee for the asset borrowed. The cumulative liquidity pool is hence the counterparty in all levered trading positions. So if a trader wins, LPs lose; and if a trader loses, LPs win.

However, it’s important to note that the GMX model is very different from traditional leveraged trading. Normal leveraged trading involves borrowing cash/stablecoins and using that to buy an asset to long; or borrowing an asset and selling to short. For example, with a long, your loan is denominated in USD (the asset you borrowed), so you are short USD and long the asset you bought on margin. With GMX, you are long, and not short, the asset you borrow. As such, it’s easier to think of it as LPs renting their spot exposure to traders rather than an outright loan.

Note: For those looking to attain a deeper understanding of how GMX works, you can view our initial coverage of the topic here.

So far, we’ve dug into how this DEX design works. W