Perpetual futures are the largest product category in on-chain trading by volume, and every venue in the category will tell you it’s decentralized. The word is doing a lot of work. There are at least four distinct architectures behind it, with materially different exposures to operator risk, censorship risk, and chain dependence.
This post walks through how the four perp venues mackinac normalizes — Hyperliquid (HL), dYdX V4, GMX, and Ostium — actually execute trades and what each one means when it claims to be decentralized. Then it describes the more common patterns elsewhere in the perp DEX category, which often share the label without sharing the architecture.
The two execution models
Every perpetual venue resolves the same question — what price do I get filled at? — in one of two ways.
CLOB perpetuals maintain an order book. Every resting bid and ask is a price level put up by someone willing to trade at it. A market order matches against the existing book; you take what’s there. The book itself, the matching logic, and the post-trade settlement are all somewhere on a spectrum from “fully on-chain” to “off-chain with on-chain settlement only.” HL and dYdX V4 are CLOB venues.
Oracle perpetuals have no order book. The fill price is the current oracle price, plus a venue-defined spread or impact function. Liquidity is provided by a single pool of LP capital that acts as the counterparty to every trade. GMX and Ostium are oracle perps. There’s no book to lift; you trade against the pool at a quoted price.
The implications cascade from there: oracle perps don’t fragment liquidity across price levels, but they impose a structural funding cost on LPs whenever directional exposure persists. CLOBs have tighter top-of-book spreads but only at sizes the resting book supports. The decentralization profile of each architecture is different too, which is where this post actually starts.
Hyperliquid — order book on a sovereign chain
HL runs on its own L1, the HyperEVM, secured by a validator set that stakes HYPE. The order book, the matching engine, and the funding rate calculation all run inside the chain’s state machine. Every trade is a block-included transaction; every cancellation, every fill, every funding settlement is part of the chain’s history.
What this means in practice:
- There is no off-chain matching server. If you want to add liquidity at a particular price, you submit an order transaction. The validators run the matching algorithm as part of consensus.
- There is no foundation-controlled gateway you have to route orders through. You can submit directly to a validator’s mempool.
- The frontend at app.hyperliquid.xyz is one client. The official API is another. Third parties can — and do — build their own clients that talk to the chain directly.
- The chain itself can fork. If the validator set behaves badly, capital can theoretically migrate to a competing fork. The cost of a hostile validator action is bounded by the value of the staked HYPE position those validators would slash.
The trade-off: HL’s decentralization rests on its validator set being large and adversarial enough that no single party can re-order or censor trades. The set is small relative to Ethereum or Bitcoin, but it’s a sovereign trust assumption you can evaluate explicitly — not one hidden behind a “decentralized” label.
dYdX V4 — Cosmos chain plus memclob
dYdX V4 also runs on its own chain, a Cosmos SDK sovereign chain secured by validators staking DYDX. The architecture diverges from HL on one important point: short-term orders never commit to chain state.
dYdX V4’s “memclob” exists in the validator’s memory, not in chain state. Short-term orders (limit orders with a ≤20-block expiry, which covers most market-maker activity) stream out of the validator’s gRPC interface. They live in the validator’s RAM until they’re matched, cancelled, or expire. Long-term orders go on-chain through the normal transaction path; fills go on-chain regardless. But the order book that market makers actually use does not have a permanent on-chain record at every state transition.
What’s decentralized:
- Validator set is open. The matching logic is in the consensus code; you can run a full node and verify it.
- Long-term orders are censorship-resistant in the standard Cosmos sense.
- Fills hit chain state, so historical fills are reconstructable from the chain without trusting any indexer.
What’s worth understanding:
- Short-term order flow is visible only via the validators’ streaming interfaces. If every validator stopped serving the stream, the book would still match (consensus would proceed) but external observers would have no view of resting liquidity.
- The block time gates how fast cancels can clear. Quote-revision latency is bounded below by block time, not by network RTT.
dYdX V4 is decentralized in the sense that no single operator can pull the plug — but the highest-frequency layer of its order book runs in validator memory, which is a meaningfully different trust posture from HL’s fully on-chain book.
GMX and Ostium — oracle perps on Arbitrum
GMX (V2) and Ostium both run as smart contracts on Arbitrum. There is no order book, no matching engine, no validator set to argue about. Trades execute against an LP pool at the current oracle price, plus a venue-specific spread or impact model.
The decentralization story is shaped entirely by three external dependencies:
- The L2 itself. Arbitrum’s sequencer is operated by Offchain Labs. The sequencer can in principle re-order or temporarily censor a transaction. Force-inclusion via L1 is possible but adds a delay measured in tens of minutes — too slow to be useful for a perp position you want to close quickly. This is shared by every contract on Arbitrum; it isn’t specific to GMX or Ostium.
- The oracle. GMX uses Chainlink price feeds, with a custom low-latency feed for execution. Ostium uses Stork and Chronicle for RWA assets, Pyth for crypto. The oracle is the trade price; if the oracle is wrong or paused, the venue is wrong or paused. The oracle providers are distinct entities — GMX’s economic exposure is to Chainlink’s operational continuity; Ostium’s is to Stork’s and Pyth’s.
- The contracts themselves. Both protocols’ contracts can be upgraded via a governance process. The bar for that process — who holds the keys, what the timelock is, who can veto — is the most important single piece of due diligence on either venue, and the answer is different for each.
What’s decentralized here is the settlement layer: trades, positions, P&L, and liquidations are all recorded by Arbitrum state and reconstructable from any Arbitrum full node. What is not decentralized is price discovery — there isn’t any, in the order-book sense. The oracle just tells you the price, and the LP pool eats the resulting position.
What “decentralized” usually means elsewhere
A large fraction of the venues marketing themselves as “decentralized perp DEXs” do not look like any of the four above. The common pattern is a centralized matching engine running off-chain, with on-chain settlement of net positions. In practice this means:
- A single matching server, operated by the protocol team, accepts all orders via a private WebSocket. Orders that don’t pass through that server don’t get matched. If the team turns the server off, the venue stops trading.
- A centralized indexer is the only practical way to read historical fills, order book state, or even the user’s own position history. The chain stores enough to settle, but not enough to reconstruct a usable trading interface. If the team stops running the indexer, the venue effectively goes dark — positions still exist on-chain, but nobody can see them in a useful form.
- Upgradeable contracts behind a 2-of-3 multi-sig that the founding team controls. Any rule of the protocol can change with the team’s signatures. The advertised governance often turns out to be advisory, not binding, with the multi-sig retaining the operational override.
- A “sequencer” the team operates that orders incoming transactions. This is often pitched as a performance feature, but it’s also a single point of control over which orders get into the book and in what order.
- A frontend-as-control-point. If the only way to add or remove margin is through the team’s hosted frontend, and the frontend can be taken down or geofenced, the on-chain contracts are technically open but practically unreachable.
None of these patterns are inherently fraudulent. They’re trade-offs that buy real things — lower latency, simpler UX, lower gas costs — at the cost of a meaningfully different trust posture than what “decentralized” usually implies to someone evaluating counterparty risk. The honest framing is that those venues are settlement-decentralized but execution-centralized. They depend on the team continuing to run the operational stack the way they say they will.
Comparing the four
| HL | dYdX V4 | GMX | Ostium | |
|---|---|---|---|---|
| Execution model | CLOB | CLOB (memclob) | Oracle + LP pool | Oracle + LP pool |
| Settlement chain | HyperEVM (own L1) | dYdX Chain (Cosmos) | Arbitrum | Arbitrum |
| Matching | On-chain state machine | Validator memory (short-term); chain (long-term) | No matching — oracle price | No matching — oracle price |
| Order intake | Direct to validators or via any client | Direct to validators or via any client | Any Arbitrum transaction | Any Arbitrum transaction |
| Censorship vector | Validator set collusion | Validator set collusion | Arbitrum sequencer | Arbitrum sequencer |
| Trust dependency | Validator set, HYPE economic security | Validator set, DYDX economic security | Chainlink oracles, contract governance | Stork/Pyth/Chronicle oracles, contract governance |
| Historical data reconstructable from chain alone? | Yes | Yes (fills), partial (short-term book) | Yes | Yes |
The honest reading is that all four have meaningful decentralization claims and all four have meaningful single points of dependence. HL and dYdX have validator sets you have to trust. GMX and Ostium have oracles you have to trust. None of them have a team that can flip a switch and stop your existing positions from settling, which is more than can be said for a long list of venues that use the same word.
What this means for evaluating exposure
When you size a position on a perp DEX, the operator-risk part of the calculation is rarely zero. The question is what specifically you’re depending on:
- On HL and dYdX, you’re depending on the validator set continuing to run consensus correctly. That dependency is bounded and economically secured.
- On GMX and Ostium, you’re depending on the oracle continuing to produce a usable price and the L2 sequencer continuing to include transactions. The first is concentrated; the second is broadly shared with every other Arbitrum contract.
- On venues with a centralized matching engine, you’re additionally depending on the operator continuing to match your orders at all. There is no validator economic security backing that promise. The promise is operational rather than cryptographic.
These are different categories of exposure, and they show up in different parts of your tail. Decentralization isn’t binary, and the marketing usually obscures that. The four venues described here aren’t equivalent, but they’re all on a spectrum where you can identify and price the specific dependency. That’s the bar worth applying.