Verdict
GMX executes at an oracle price with no order book and no slippage, which is genuinely useful for size. The liquidity providers are the counterparty to every trade, and understanding that is the whole of understanding GMX.
- Best for
- On-chain traders who want oracle pricing and no order book
- Cost
- ~0.05–0.07% open/close plus borrow fee
What works
- Execution at the oracle price with no slippage regardless of order size
- V2 isolates markets so one bad asset cannot drain the shared pool
- Fee revenue is distributed transparently to stakers and liquidity providers
- Fully on-chain positions on Arbitrum and Avalanche with self-custody throughout
What does not
- Borrow fees make holding a position for weeks expensive
- Liquidity providers take the other side of every trade and can lose badly
- Oracle dependency is a real attack surface with a real incident history
- Available markets are a fraction of any centralised venue's list
The mechanism, because everything follows from it
There is no order book on GMX. When you open a long, the protocol quotes you the oracle price for the asset and fills your entire order there — $500 or $500,000, same price, no book to walk up. The other side of that trade is a liquidity pool funded by depositors.
For anyone who has watched a large market order chew through an order book, the appeal is immediate. Slippage is the single biggest hidden cost of trading size, and here it is zero by construction rather than by luck.
The cost shows up somewhere else: you pay roughly 0.05–0.07% to open and the same to close, plus a borrow fee charged continuously while the position is open, scaled by how much of the pool's capacity your side of the market is currently using.
Doing the arithmetic
A day trade on GMX is often cheaper than the same trade on a centralised venue once slippage is counted honestly. A swing position held for three weeks, on a crowded side of the book, can cost several percent in borrow fees alone — more than the move you were waiting for.
Before you open anything here, look at the current borrow rate for your side and multiply it out over your intended holding period. That number, not the 0.06% open fee, is your real cost, and it is the number the interface shows least prominently.
Check the borrow rate for your direction, not the average.
Multiply by your expected holding period in hours, not days.
Compare the result against the slippage you would actually have paid on an order book of realistic depth.
If the position is longer than a few days, the answer is usually a centralised venue.
If you are providing liquidity
GM pools pay a share of fees, and the advertised yields are usually attractive. What you are being paid for is taking the opposite side of every trader on the platform.
When traders are collectively wrong, pool depositors make money on top of the fees. When traders are collectively right — a sharp directional move with the crowd positioned correctly — depositors absorb that loss directly. The yield is compensation for a real short-volatility exposure, not a savings rate, and the historical returns were generated across a particular sequence of market conditions that will not repeat identically.
Every 'passive yield' figure on a perpetuals DEX is the market's estimate of how often its traders lose. Treat it as a risk premium, because that is exactly what it is.
Oracle risk
Oracle pricing removes slippage and creates a dependency. If the reference price can be manipulated on a low-liquidity venue, a trader can open at a price that does not really exist and extract value from the pool. This is not hypothetical — the category has a documented history of exactly this attack, executed successfully more than once.
GMX's V2 design with isolated markets and tighter price validation exists because of it. The isolation is the important improvement: a compromise in one market no longer reaches the collateral backing every other one, which converts a protocol-ending event into a contained loss.

What is actually listed
A short list of major assets, deliberately. That is the correct decision for a design where every listed market shares a risk surface with real depositors behind it, and it is why GMX has not had the kind of thin-market squeeze that Hyperliquid experienced.
How it compares
Against Hyperliquid: GMX is worse for active trading and better for large single entries where slippage would dominate. Against a centralised venue: self-custody throughout, at the cost of a holding fee that has no equivalent on an order book.
Verdict
Liquidations without an order book
Because positions are marked against the oracle rather than a book, liquidation is a clean calculation: when your collateral no longer covers the maintenance requirement at the oracle price, the position closes. There is no cascade of stop orders walking the book down, and no wick on a thin venue taking you out at a price that never existed on any other exchange.
That is a genuine advantage over centralised perpetuals, where wick liquidations are a recurring complaint and the venue's own index construction is the only thing standing between you and one. The trade-off is that the oracle becomes the single thing you are trusting, which is the subject of the section above.
Where the fees actually go
Trading fees are split between liquidity providers and stakers according to rules published on-chain and verifiable by anybody. There is no discretionary treasury allocation and no undisclosed share to an operating company.
For a protocol asking depositors to underwrite trader losses, that transparency is not a nice-to-have. It is the only way a depositor can evaluate whether the compensation is adequate for the risk, and it is the main reason GMX retained liquidity through periods when its competitors did not.
Score: 7.2. Genuinely useful for short-dated size where slippage would dominate, genuinely expensive for anything held long, and honest about both. The LP side should be understood as a short-volatility trade rather than a yield product — and the protocol's own documentation says so, which is more than most of its peers manage.
