How GMX’s Liquidity Pools Actually Price Your Trade

Back to Blog

GMX · LIQUIDITY · ARBITRUM

Short answer: GMX fills trades against GM liquidity pools priced by an oracle feed, not against an order book. Each GM pool is isolated per market, so execution price depends on that specific pool’s depth and utilization rather than counterparty order flow — a meaningfully different model to account for when sizing trades or building execution logic.

No order book means no counterparty in the usual sense

On a centralized exchange or an order-book DEX, your trade fills against another trader’s resting order. GMX works differently: your trade fills against a GM liquidity pool, with price sourced from a Chainlink oracle feed rather than the last matched order. The pool itself is your counterparty.

This matters immediately for execution logic: there’s no order book depth to read before sizing a trade. What matters instead is the pool’s current utilization and how much price impact your order size will generate against that specific pool.

From GLP to isolated GM pools

GMX V1 used a single shared pool, GLP, backing every trading pair with one multi-asset basket of liquidity. V2 replaced this with GM pools isolated per market — a separate pool for ETH/USD, another for BTC/USD, and so on.

Isolation limits contagion: a liquidation cascade in one market’s GM pool doesn’t directly drain liquidity meant for another market. The tradeoff is that each market’s depth now depends entirely on how much liquidity has been provided to that specific pool, which can vary significantly between a heavily traded pair and a smaller one.

What this changes for a bot sizing trades

Price impact on GMX is a function of pool utilization, not order book slippage in the traditional sense. A trade that’s small relative to a deep GM pool executes close to the oracle price; the same notional size against a thin pool can move the effective price meaningfully more.

Any backtest or live execution model built for order-book venues needs a different slippage assumption here — one tied to on-chain pool state rather than a generic percentage. Pulling current pool utilization before sizing an order is the GMX-specific equivalent of checking order book depth elsewhere.

Trading through GMX’s pool model directly → open a position on GMX with TGL’s referral code for a fee discount — then run the resulting trade history through TGL’s auditor the same way you would any other venue’s export.

A different model, not a worse one

Pool-based pricing isn’t inherently riskier than an order book — it’s a different set of assumptions to model correctly. The traders who get caught out are usually the ones applying order-book intuition (assumed depth, assumed counterparty behavior) to a venue that works on entirely different mechanics.

Explore

More from the blog