GMX vs Hyperliquid: Which Perp DEX for Trading Bots?

Both GMX v2 and Hyperliquid will fill your bot's orders, but they disagree on something fundamental: where the price comes from. GMX v2 quotes you off a Chainlink-plus-Chainlink-Data-Streams oracle and settles trades against a shared GM pool. Hyperliquid runs an actual central limit order book on-chain, matched by its own L1 validators, with the HLP vault standing in as a backstop market maker. That single difference cascades into everything a bot builder cares about — fee model, slippage behavior, how you get fills, and whether you can run a market-making strategy at all.

I've built execution layers against both. Here's how they actually compare when you're the one writing the code.

Price discovery: oracle vs order book

On GMX v2, there is no order book you trade into. You open a position and the protocol prices it off the oracle at execution time. Your fill price is the oracle mark, adjusted by a price impact function that pushes the pool toward or away from balance. This is great and terrible depending on what you're doing.

The great part: no slippage in the classic sense on liquid markets. A $50k ETH long on GMX doesn't walk a book. You pay a fixed open/close fee (recently around 4–7 bps depending on the market) plus borrowing and funding, and price impact only bites when your trade worsens the pool's long/short skew. A trade that balances the pool can even get a small rebate.

The terrible part: you're a price taker against a lagging oracle, and you cannot post liquidity. There's no maker side to be on. Data Streams cut the latency versus the old push-oracle model, but you're still executing at a mark someone else defines, and keeper execution adds a delay between request and fill. That delay is the whole ballgame for latency-sensitive strategies.

Hyperliquid is the opposite. It's a real CLOB with price-time priority. Your bot posts bids and asks, they rest in the book, and you get maker rebates when you're filled. Market discovery happens in the book, not off an oracle. If you've built anything on a centralized venue's order book, the mental model transfers almost directly — which is exactly why teams porting CEX strategies find it easier. The tradeoff mirrors what shows up across venue types generally, the same way the Meteora DLMM versus Orca Whirlpools comparison for LP bots turns on how each pool discretizes liquidity.

Fee model, and where it quietly eats you

GMX v2 fees look clean on paper:

• Open/close fee: a flat bps cut on notional
• Price impact: variable, can be positive or negative
• Borrowing fee: scales with pool utilization on your side
• Funding: paid to the lighter side of open interest

The gotcha is borrowing fees on a crowded side. If everyone's long ETH, your long pays a continuous borrow rate that can dwarf the entry fee over a multi-hour hold. Bots that don't model this bleed out slowly. You have to read getBorrowingFees state before sizing, not after.

Hyperliquid's fee schedule is taker/maker tiered by 14-day volume. Makers can hit negative fees (rebates) at volume; takers pay a few bps. No borrowing fee mechanic — you pay funding, settled hourly, and it's a straight OI-imbalance transfer. For a market maker this is decisive: on GMX you literally cannot earn the spread, on Hyperliquid earning the spread is the strategy. If you're weighing execution cost across venues the way you'd compare Trojan and Maestro against a custom Solana bot on fees and latency, the maker-rebate line item is what tips Hyperliquid for anyone quoting.

API surface: what you actually integrate against

This is where the two diverge hard for developers.

GMX v2 is contract calls. You submit orders through the ExchangeRouter, positions execute via keepers, and you read state off Reader and datastore contracts. There's no native websocket for your fills — you watch on-chain events or poll. You're doing multicall reads, decoding datastore keys, and handling the two-step request/execution flow where a keeper picks up your order. Expect to write a lot of ABI-level plumbing. On Arbitrum, gas is cheap but the async execution model means your bot must track pending orders and handle the case where a keeper reverts your request.

Hyperliquid ships a proper API. REST plus websocket for market data, order placement, and fills. Orders are signed EIP-712 payloads posted to the exchange endpoint — no gas per order, no keeper wait. A minimal quote loop looks like this:

from hyperliquid.exchange import Exchange
from hyperliquid.info import Info

info = Info(skip_ws=False)
book = info.l2_snapshot("ETH")
best_bid = float(book["levels"][0][0]["px"])
best_ask = float(book["levels"][1][0]["px"])

# quote inside the spread, post-only so we stay maker
exchange.order("ETH", is_buy=True,  sz=0.1,
               limit_px=best_bid + 0.1, order_type={"limit": {"tif": "Alo"}})
exchange.order("ETH", is_buy=False, sz=0.1,
               limit_px=best_ask - 0.1, order_type={"limit": {"tif": "Alo"}})

Alo is add-liquidity-only (post-only): if the order would cross and take, it's rejected instead of paying taker fees. That one flag is why market making is even viable here. The websocket pushes your fills in real time, so you can cancel-replace on quote drift without polling. Nothing on GMX comes close to this ergonomically — if you tried to run this same loop against GMX contracts you'd be fighting keeper latency the whole way. Before you wire real capital in, the async edge cases on both sides are exactly the kind of thing a dedicated bot code review and audit catches before they cost you.

Market-making viability

Short version: GMX is not a market-making venue for your bot. There's no book to quote into. The "maker" role belongs to GM pool liquidity providers, and that's a passive LP position, not an active strategy you drive from code. You can run directional, mean-reversion, or hedging bots on GMX, but not spread capture.

Hyperliquid is built for it. Post-only orders, maker rebates, per-asset books, and the HLP vault as a reference for how the protocol itself market-makes. The catch: you're competing with sophisticated flow and with HLP itself, so naive quoting gets adversely selected fast. You need inventory skewing, funding-aware quote placement, and fast cancel logic. Getting bundle-style execution priority right matters here the same way bundle landing on Solana via bloXroute versus Jito decides whether your fills land — latency to the matching engine is a real edge. This is involved enough that most teams shipping serious quoting run it as a purpose-built Hyperliquid market-making system rather than a weekend script.

How to actually choose

Pick GMX v2 if your bot is directional or hedging, you want oracle-priced fills with no book-walking on size, and you can model borrowing fees. Pick Hyperliquid if you're quoting, arbing, or porting a CEX order-book strategy — the CLOB, the real API, and maker rebates are the whole reason to be there.

One thing that bites everyone: don't benchmark them on backtested PnL alone. GMX's price-impact rebates and Hyperliquid's adverse selection are both execution-layer effects that a naive backtest won't show. Model fills against real historical book and oracle data, or you'll ship a strategy that looks great and dies in production.

If you're still deciding which venue fits your edge before committing engineering time, a focused strategy consultation will save you from building the wrong execution layer twice.