Hyperliquid vs dYdX v4 vs GMX for Automated Perps Trading

Three venues dominate on-chain perps automation right now, and they disagree fundamentally on how a price gets set: Hyperliquid runs a full central limit order book on its own L1, dYdX v4 runs an order book across a Cosmos app-chain, and GMX prices fills off Chainlink oracles with no book at all. That single architectural choice changes everything downstream for a bot — how you get fills, what your worst-case slippage looks like, whether you can even quote, and how much your infra costs to run.

I've shipped strategies on all three. Here's the comparison that actually matters when you're writing code against them, not the marketing-deck version.

Pricing model decides your whole strategy space

Start here because it filters out half the strategies before you write a line.

GMX is oracle-priced. You trade against the pool at the Chainlink mark, and your fill price is the oracle price plus fees plus price impact, computed at execution. There is no maker side. You cannot post a resting order, you cannot quote a spread, and you cannot run any market-making or passive-liquidity strategy. What GMX is good for: directional bots that want zero price-book slippage on the mark, and delta-neutral plays against the GLP/GM pool. If your edge is "I know where price is going and I want to express it without walking a book," GMX is clean. If your edge is microstructure, GMX has nothing for you.

Hyperliquid and dYdX v4 are both real order books, so both support making and taking. This is where a Hyperliquid market-making engine actually has surface area to work — you post two-sided quotes, earn the spread, and manage inventory. On GMX that entire category is a non-starter.

Latency and the matching path

Hyperliquid's L1 uses HyperBFT with block times in the low hundreds of milliseconds, and — this is the part that matters — order placement and cancels go through the same consensus. In practice you're looking at roughly 0.2s end-to-end for an ack under normal load. Their WebSocket pushes l2Book, trades, and user fills fast enough that a quoting loop running a 200–500ms requote cadence is reasonable. It is not co-located CEX latency. Don't port a strategy that needs sub-10ms requotes.

dYdX v4 runs on CometBFT with ~1s blocks, but the clever bit is the off-chain in-memory orderbook: validators match orders in a mempool-like orderbook that isn't committed to a block until fills happen. So order placement and cancellation are effectively free and fast (they never hit chain state unless they match), while settlement waits for the block. That's great for cancel-heavy quoting — you can spam cancels without paying gas or waiting a full second. The gotcha is that your view of the book depends on which validator's indexer you're reading, and indexers lag.

GMX latency is a different animal entirely because fills are two-step: you submit a request, then a keeper executes it against a fresh oracle price a block or two later. On Arbitrum that's usually 1–3 seconds, sometimes worse when keepers back up. You are exposed to price movement in that window, and there is no way around it. Build for it.

API quality and the SDK you'll actually live in

Hyperliquid's API is the one I reach for first when prototyping. Signed EIP-712 actions, a coherent REST + WebSocket split, and Python/Rust SDKs that don't fight you. A minimal order looks like this:

from hyperliquid.exchange import Exchange
from hyperliquid.utils import constants

ex = Exchange(wallet, constants.MAINNET_API_URL)
# limit buy 0.1 BTC at 60000, ALO = post-only
ex.order("BTC", is_buy=True, sz=0.1, limit_px=60000,
         order_type={"limit": {"tif": "Alo"}})

The Alo (add-liquidity-only) time-in-force is the post-only flag you'll use constantly for making. If you're standing up a bot from scratch, the Python and Rust API walkthrough covers the signing scheme and the nonce handling, which is the part that trips people up first.

dYdX v4's SDK is Cosmos-native — you're signing protobuf messages and dealing with account sequence numbers, subaccounts, and quantums (integer price/size units you have to convert into). It's more ceremony. Fully capable, but plan an extra day for the "why is my order rejected" phase. The indexer REST API is decent; the gRPC streams are where the real speed lives.

GMX's contract interface is the whole API — you're encoding createIncreasePosition / createDecreasePosition calls (v2 uses the exchange router and order structs) and reading position state from the reader contract or a subgraph. No native trading SDK in the CEX sense. It's just Ethereum tooling: ethers/viem, event logs, and patience for keeper execution.

Fees, funding, and where the money leaks

• Hyperliquid: maker rebates and low taker fees, with funding settled hourly. The tight funding cadence makes it a strong venue for funding-rate arbitrage because you rebalance more often and drift less between settlements. The mechanics of running that spread against a CEX are laid out in this funding-arb breakdown.
• dYdX v4: volume-tiered maker/taker, funding on an 8h-style schedule but sampled continuously. Gas is paid in USDC and is tiny because unmatched orders never hit chain.
• GMX: no funding in the CEX sense — instead you pay borrow fees per hour on open interest, plus a per-trade fee and price impact. On a multi-day directional hold those borrow fees compound and will quietly eat a thesis that would've been fine on a funding venue.

The oracle-priced model also means your GMX liquidation logic differs: liquidations trigger off the same oracle mark, not off a book cascade, so a liquidation-hunting bot that works on Hyperliquid's book doesn't translate — there's no visible resting liquidity to pick off.

Liquidity and depth for programmatic size

Hyperliquid has the deepest book of the three on majors (BTC/ETH), and HLP backstops liquidity as a passive maker — worth understanding if you're sizing against it, and the HLP vault mechanics explain why the book behaves the way it does around large fills. dYdX v4 depth is solid on top pairs but thins out faster on the long tail. GMX "depth" is really pool size and the price-impact curve — a large order moves your own fill via impact rather than walking a book, which is more predictable but caps how much size you can push without paying for it.

How I'd pick

• Microstructure, quoting, market making, tight funding loops → Hyperliquid. Best API, hourly funding, real book, the widest strategy surface. Most of the perps-bot work I build lands here for this reason.
• Cancel-heavy quoting with a preference for Cosmos infra and gasless order churn → dYdX v4.
• Directional or delta-neutral against a pool, no interest in making → GMX, with borrow-fee accounting baked in from day one.

Whichever venue you land on, wire up per-venue latency and fill-quality monitoring before you scale size — if you want that visibility without building it yourself, the trading dashboard is where we usually start.