Decentralized Exchanges With Order Books: dYdX and Serum

Decentralized exchanges are often associated with automated market makers, where trades execute against liquidity pools governed by mathematical formulas. Order-book exchanges take a different route. They preserve the familiar bids, asks, limit orders, and market depth used by traditional trading venues, while shifting custody and settlement to blockchain infrastructure.

dYdX and Serum became important examples of this hybrid design. Both separated the rapid process of matching orders from the slower, more transparent process of recording final results on-chain. That division helped them deliver a trading experience closer to a centralised exchange without requiring users to hand over their assets.

Why Order Books Need Off-Chain Matching

A blockchain is reliable because many independent computers verify transactions, but that reliability comes with limits. Every order update, cancellation, and fill submitted directly to a busy public chain consumes fees, takes block space, and competes with other activity. For an active market, continuously writing every change to Ethereum or Solana can become expensive and inefficient.

Off-chain matching solves this bottleneck. A matching engine maintains the live order book in memory, compares compatible bids and asks, and creates a proposed trade. The chain then verifies or records the outcome according to the exchange’s architecture. Users gain faster execution, while the protocol retains a verifiable settlement layer rather than relying entirely on a private database.

How dYdX Separated Speed From Settlement

The earlier dYdX model used an off-chain order book and matching engine alongside StarkEx, a scalability system built for Ethereum. Traders could sign orders without depositing funds into a conventional exchange wallet. The operator matched compatible orders, grouped activity, and submitted batches for StarkEx processing.

The key distinction is that the matcher did not have unrestricted control over customer assets. StarkEx used validity proofs to demonstrate that trades and account updates followed the protocol’s rules. Once accepted, the resulting state could be settled on Ethereum. This design made dYdX faster than putting every order directly on the Ethereum mainnet, although users still depended on the operator and proving system used by that version.

dYdX later moved towards its own Cosmos-based chain, changing the role of validators and the matching layer. Its newer architecture is more natively decentralised, with trading infrastructure integrated into a specialised network rather than relying on the original Ethereum scaling arrangement. That history matters when comparing “dYdX” references, because the answer differs between its earlier StarkEx exchange and its current chain-based system.

Serum’s Solana Order-Book Design

Serum was designed around Solana’s high-throughput environment and provided a central limit order book that other decentralised applications could access. Instead of keeping liquidity inside one application, Serum exposed markets and matching infrastructure as shared on-chain programs. Wallets and trading interfaces could interact with the same underlying order book.

A trader signed a transaction containing an order instruction, and Solana validators processed it according to the program’s rules. The matching process could occur through crank-style transactions that consumed resting orders and advanced the market state. When a bid crossed an ask, the trade’s asset and payment accounts were updated by the program, producing on-chain settlement without a central custodian.

This structure gave Serum strong composability. Projects across the Solana ecosystem could build interfaces, aggregators, and derivatives products around common markets. The trade-off was that network congestion, transaction fees, and the availability of market-making infrastructure still affected execution. Serum’s history also shows that technical decentralisation does not eliminate governance, security, or ecosystem risks.

What “On-Chain” Really Means

The phrase “on-chain order book” can hide important differences. In Serum’s original model, orders and matching instructions were represented within Solana’s account and transaction system. The chain could inspect the state directly, although external crankers and applications helped keep markets active. A cancellation or fill was therefore part of the public ledger’s operational history.

In earlier dYdX, the visible order book was largely maintained off-chain, while proofs and settlement commitments moved to Ethereum through StarkEx. The individual user experience looked similar to a conventional exchange, but the chain did not process every quote in real time. This approach reduced load, yet it required trust in the exchange operator’s availability and in the cryptographic system that verified batches.

For Australian traders, the practical question is less about a label and more about control. Check whether orders are signed locally, whether withdrawals remain permissionless, how liquidation is handled, and which chain records the final state. A trader in Sydney or Perth should also account for Australian Eastern or Western time zones when monitoring funding rates and volatile overnight sessions.

Costs, Liquidity, And Execution

An off-chain matcher can update quotes rapidly, but speed does not guarantee a good fill. Thin liquidity can produce slippage, while a delayed cancellation may leave an order exposed to a sudden price move. On a fully on-chain venue, network congestion can create a similar problem by delaying the transaction that places or removes an order.

Fees vary across the stack. dYdX users may encounter trading fees, withdrawal costs, and the economic cost of proof generation or network operations. Serum markets depend on Solana transaction fees and the liquidity available in each trading pair. Australian users converting through AUD may also face bank transfer timing, spread, tax-record requirements, and platform restrictions linked to local compliance policies.

Security extends beyond smart contracts. A compromised browser, phone, or signing device can approve a harmful transaction even when the exchange code is sound. Before trading from a mobile handset, review practical device-security details such as the Lightning connector guide, then use hardware-backed authentication and keep seed phrases offline.

Choosing Between The Two Models

dYdX’s earlier system prioritised a smooth derivatives experience by combining a responsive off-chain book with cryptographic settlement. Its newer chain aims to distribute more of the exchange’s operation across validators. Serum pursued a more openly composable on-chain order-book model, allowing multiple applications to share markets on Solana. The comparison is therefore between evolving designs rather than two fixed products.

Australian investors should also consider regulation and record keeping. ASIC’s treatment of crypto products depends on the asset, service, and financial-product features involved, while tax obligations can arise from trading, derivatives, and disposals. Someone in Melbourne or Brisbane should retain order records, fees, deposits, withdrawals, and Australian-dollar conversion rates instead of relying solely on a wallet history.

The local market has its own operational habits. Bank transfers and support desks may follow Australian business hours, while decentralised protocols run continuously. A quick “arvo” check of the book can look fine, yet liquidity may thin sharply during local late-night hours when global participants are reacting to United States data. That gap between local routine and global market timing is a real execution risk.

The core innovation behind these exchanges is the separation of matching from settlement. dYdX demonstrated how an off-chain engine could feed verifiable batches into Ethereum scaling infrastructure, while Serum showed how a shared on-chain order book could support a broader application ecosystem. Neither model removes risk, but each offers a different balance of latency, transparency, custody, and decentralisation.

Before placing a live order, open the relevant market in a small test account, verify whether the order is signed or submitted by a custodian, and record the transaction or settlement reference for that first trade.