5 min read

The CLOB Wars — Monolithic vs. Modular in Next‑Gen On‑Chain Exchanges Part 1

Written by

Eclipse Labs

Published on

August 4, 2025

In mid‑2025, a widely reported nine‑figure loss on Hyperliquid was read less as a failure than as a stress‑test passed: a single on‑chain venue absorbed institutional‑scale taker flow without halting or dislocating, signaling that CEX‑grade liquidity and performance had arrived on‑chain. The episode—and Hyperliquid’s rapid growth that followed—exposed a gap left by first‑generation DEXs and accelerated what many now call the CLOB Wars.

Summary

On‑chain trading is shifting from AMMs toward CLOB designs that target low‑latency execution, richer order types, and institutional‑grade market structure. Two architectural camps are emerging:

Monolithic app‑chains (e.g., Hyperliquid, dYdX chain) vertically integrate execution, consensus, and data into a single high‑performance L1.
Modular stacks (rollups/L3s on Ethereum or Solana) unbundle Execution, Settlement & Consensus, and Data Availability (DA)—often using Ethereum/Solana for settlement and providers such as Celestia or EigenDA for DA—to leverage shared security and composability.

For traders, operators, and investors, three technical differentiators dominate outcomes:

Finality profile. Modular designs provide millisecond soft finality (sequencer acknowledgments) for a CEX‑like UX, while hard finality (irreversible settlement on the base layer) arrives later—typically minutes on Ethereum (though L1s can also provide similar preconfirmation guarantees). Monolithic app‑chains compress this gap with sub‑second block‑final confirmation. The resulting latency vs. irreversibility window is an operational risk to price into liquidations, large orders, and bridge flows.

Data availability economics and assurances. DA often represents the majority of a rollup’s operating cost and governs exit guarantees:

On‑L1 DA (Ethereum calldata/blobs) maximizes conservatism and exit properties.
Modular DA (e.g., Celestia with DAS) aims to reduce marginal cost at scale.
Restaked DA committees (e.g., EigenDA) seek higher throughput/cost wins while leaning on ETH‑secured economics.

Sequencer trust and user safeguards. Centralized sequencing remains common for performance, introducing censorship/MEV surface and downtime risk. Robust systems provide forced‑inclusion/withdrawal paths (“escape hatches”) using posted data; decentralized or shared sequencing is an active area of iteration.

Performance (project‑reported):

Monolithic hard finality: sovereign L1s report sub‑second block‑final confirmation (e.g., Hyperliquid ≈ 0.2 s median).¹
Rollup soft latency: modular CLOBs report 1–5 ms soft acks (e.g., Bullet, GTE).²
Throughput capacity: next‑gen stacks target high scale (e.g., GTE on MegaETH ≳ 100k TPS target; Hyperliquid ≈ 200k OPS).²
Hybrid finality: Solana‑based rollups have ≈ 12 s hard finality, narrowing the soft→hard gap.²

The remainder of this report evaluates CLOB platforms against a standardized framework—Execution Model → VM → Settlement/Consensus → Proof System → DA Layer → Sequencer Model → Key Differentiator—and closes each profile with “Why it wins / where it struggles.”

Footnotes:

Figures cited by the respective projects; treat as indicative.
Latency/throughput values are project‑reported or testnet‑observed and may vary under live conditions.

2. Introduction: “When a Loss Became a Catalyst.”

AMMs solved the cold‑start problem for permissionless liquidity but impose constraints that professional flow cannot ignore:

Slippage from curve‑based pricing. With pricing tied to pool inventories (e.g., x.y=k), large trades traverse the curve and incur path‑dependent slippage rather than matching against standing liquidity.
Capital efficiency trade‑offs. In constant‑product AMMs, most capital sits away from the current price; CLMMs improve utilization but push LPs into active management and greater impermanent‑loss exposure.
Order‑type limits and execution control. Native support for limit/stop/post‑only behavior—essential to systematic and risk‑managed trading—is absent or auxiliary. Public mempools and block‑level latency further expose order flow to frontrunning and sandwich risk.

CLOB‑based exchanges target these gaps: a price‑time priority book, richer order semantics, and low‑latency matching—paired with on‑chain custody, verifiability, and credible exit guarantees. The competition now centers on how to deliver those properties—monolithically at L1 or modularly via rollups—while balancing finality, DA economics, and sequencer trust models.

3. The Four Pillars Framework

To compare next‑generation CLOB DEXs rigorously, treat each as a stack rather than a single application. Four architectural pillars determine performance, security, and UX: Execution, Settlement & Consensus, Data Availability (DA), and Sequencing. The report analyses that follow apply this lens uniformly.

3.1 Execution

Where the order book logic runs and how matching is performed.

Placement. On‑chain books post place/cancel/match to the ledger (max transparency, higher on‑chain throughput required). Off‑chain books keep signed orders in memory and only settle matches on‑chain (very high throughput, different trust assumptions).
Runtime/VM. Teams either retain EVM for ecosystem compatibility or use specialized runtimes (e.g., SVM, custom engines, or zk‑friendly VMs) for deterministic, low‑latency matching.
What to evaluate. Order‑event latency, cancel/modify cost, determinism of matching, and any proof/verification of off‑chain matching.

3.2 Settlement & Consensus

Who provides the canonical ledger and finality.

Monolithic/app‑chain. Integrates BFT‑consensus at L1 for fast hard finality (sub‑second to seconds).
Modular/rollup. Inherits security and hard finality from a base L1 (e.g., Ethereum). Users often receive soft finality (sequencer acks in ms) first; hard finality arrives only when data/proofs are accepted on L1.
Withdrawal semantics. Distinguish settlement finality from withdrawal/bridge finality (optimistic/challenge windows vs ZK proof acceptance).
What to evaluate. Soft‑to‑hard finality window, reorg risk, bridge guarantees, and failure modes under L1 congestion.

3.3 Data Availability (DA)

How trade and state data are published so anyone can reconstruct and verify. DA often dominates rollup cost and governs exit guarantees.

Options. On‑L1 DA (Ethereum calldata/blobs) for maximal conservatism; modular DA (e.g., Celestia with DAS) to reduce marginal costs at scale; restaked DA committees (e.g., EigenDA) to pursue throughput/cost gains while leaning on ETH‑secured economics.
What to evaluate. Cost per byte/event, sampling/verification model, withholding risks, and how DA choice affects forced exits and light‑client verification.

3.4 Sequencing

Who orders transactions and under what guarantees.

Models. Centralized sequencers optimize for latency and iteration speed but introduce censorship/downtime/MEV risk. Emerging designs use rotating or auctioned decentralized sequencing or shared sequencing networks.
Safeguards. Robust systems expose forced inclusion and forced withdrawals using posted data (“escape hatches”) to bound operator power.
What to evaluate. Time‑to‑inclusion, censorship resistance, MEV policy/controls, liveness under faults, and roadmap to decentralize.

3.5 The DEX Trilemma: Performance, Decentralization, Composability

CLOB design navigates a three‑way tension:

Performance: low latency (order/ack/fill times), high throughput (OPS/TPS), and low marginal costs.
Decentralization: censorship resistance, absence of single‑control points, credible recovery paths.
Composability: seamless integration with broader DeFi (liquidity sharing, asset/bridge standards, programmatic access).

Monolithic designs integrate execution/consensus/DA to minimize latency and maximize throughput, often trading off cross‑ecosystem composability. Modular designs unbundle layers to inherit base‑layer security and liquidity, while accepting added complexity and typically longer hard‑finality paths. This framework sets the basis for the platform‑by‑platform comparisons that follow.

4. Architectural Camps

Next‑gen CLOB DEXs follow two designs. One makes the exchange a sovereign chain; the other assembles it as a modular stack that inherits security from a base L1.

4.1 Monolithic App‑Chains — Exchange‑as‑a‑chain

A dedicated L1 integrates execution, consensus, DA, and sequencing. Orders (txs or signed messages) are matched next to the state machine; a BFT‑style consensus commits the result with hard finality on block commit (typically sub‑second to a few seconds). DA is native—blocks propagate full state; there’s no external DA fee. Sequencing is endogenous (proposers/validators); MEV policy is enforced at protocol level. Proofs are optional; bridges define external trust.

Wins: tight match→commit loop, predictable tail latency, no external DA cost.

Struggles: weaker cross‑ecosystem composability (assets not natively on Ethereum); security and exits hinge on validator‑set quality and bridge design.

4.2 Modular Stacks — Exchange‑as‑a‑stack

Execution prioritizes speed (often an off‑chain order book with a fast sequencer) that returns millisecond soft acks. Safety comes from posting data to a DA layer and settling on a base L1 for hard finality. Proofs can be optimistic (fraud‑proofs; challenge windows) or ZK (validity proofs). DA choices include on‑L1 (Ethereum calldata/blobs) for maximum conservatism, modular DA (e.g., Celestia) for lower marginal cost, or restaked DA committees (e.g., EigenDA) to chase throughput/fees under ETH‑anchored economics. Sequencers are commonly centralized today; credible designs expose forced inclusion/withdrawals on L1 and roadmap toward decentralized/shared sequencing. Hard finality timing follows the base chain (minutes on Ethereum; ~1–2 s on Solana).

Wins: strong composability with base‑layer DeFi, credible L1 escape hatches, configurable DA economics, excellent soft‑latency UX.

Struggles: non‑zero soft→hard window (especially optimistic paths), DA as a dominant operating cost, operator‑risk until sequencing decentralizes.

4.3 Practical Takeaways

Monoliths minimize control‑plane hops and deliver latency determinism; choose them for liquidation‑sensitive derivatives and maker‑heavy flow. Modular stacks maximize ecosystem reach; choose them when Ethereum/Solana composability and L1‑anchored exits dominate. In the article sections that follow, we apply a uniform framework—Execution Model → VM → Settlement/Consensus → Proof System → DA Layer → Sequencer Model → Key Differentiator—and close each profile with “why it wins / where it struggles.”

5. Finality, Censorship, and Escape Hatches

5.1 A Tale of Two Finalities

Soft finality — instant, but reversible. On modular CLOBs, a fast engine/sequencer acknowledges places/cancels in milliseconds. This “soft” confirmation drives CEX‑like UX but is not consensus: a faulty or crashed sequencer can roll back recent acks.

Hard finality — delayed, but irreversible. A trade becomes economically/canonically final when recorded on the settlement L1. For Ethereum‑settled rollups, that means inclusion plus sufficient confirmations (economic finality typically on the order of minutes). For Solana‑settled rollups, L1 finality is ~1–2 s, materially shrinking the soft→hard gap. Monolithic app‑chains collapse the stages: a committed block is already hard finality (often sub‑second to a few seconds, project‑reported).

Settlement vs withdrawal. Hard finality of the trade is not the same as hard finality of a withdrawal. Optimistic systems add a challenge window before funds are withdrawable; ZK systems rely on validity proofs, typically shortening withdrawal timelines at the cost of proof overhead.

Risk window. The interval between soft and hard finality is the exposure: if the sequencer fails or withholds during this window, the system falls back to the last finalized L1 state and recent soft‑confirmed actions may be dropped.

5.2 Centralized Sequencers, Censorship Risk, and Escape Hatches

Most rollups start with a centralized sequencer to achieve millisecond latency, introducing a single point of censorship/downtime and MEV leverage. Two trust‑minimized mechanisms are therefore non‑negotiable:

Forced inclusion: users (or relayers) must be able to submit a transaction directly to the base chain for inclusion of a sequencer censor.
Forced withdrawals: users must be able to exit using posted data and on‑chain proofs, even if the sequencer is offline or adversarial.

These guarantees rely on data availability—the ability to reconstruct state from posted data—and the settlement layer’s finality. Roadmaps toward decentralized/shared sequencing (rotation, auctions, or third‑party networks) aim to reduce operator risk without sacrificing interactivity; until then, escape hatches are the effective backstop for self‑custody.

Operator checklist: size of the soft→hard window (p50/p99), base‑chain finality, DA posting and reconstruction guarantees, presence and usability of forced‑inclusion/withdrawal paths, and (for optimistic paths) challenge‑window implications for withdrawals.

6. Data Availability: Costs, Security, and Who Uses What

Why DA matters. In modular designs, DA is often the dominant operating cost and the root of exit guarantees. Your DA choice determines fee curve, censorship/withholding resilience, and how easily light clients can reconstruct state.

6.1 On‑L1 Data Availability (Ethereum / Solana)

What it is. Post transaction/state data directly to the settlement L1 (e.g., Ethereum calldata or EIP‑4844 blobs; Solana ledger entries for Solana‑settled stacks). This path is maximally conservative under the base layer’s assumptions: exits and verification inherit the L1’s economics and fault tolerance. The trade‑off is higher data cost and finite blockspace.

Who uses it?

Paradex → Ethereum L1 DA.
Lighter (on Arbitrum) → compressed data ultimately on Ethereum L1.
Bullet → Solana L1 DA (settlement and DA coincide).

When to choose. Prioritize straightforward exits and widely understood verification; accept L1 data pricing.

6.2 Modular DA Layers (Celestia with DAS)

What it is. A specialized DA chain publishes erasure‑coded blobs that light nodes verify via Data Availability Sampling (DAS). As light‑node count grows, the network can safely handle larger blobs at lower marginal cost per byte than posting everything to Ethereum.

Who uses it?

Hibachi → Celestia DA (posting encrypted trade/state data), with settlement on Ethereum.

When to choose. Optimize DA cost/throughput and unlock privacy knobs (e.g., encrypted blobs), while accepting an additional trust boundary (Celestia validators and network liveness).

6.3 Restaked DA Committees (EigenDA)

What it is. EigenDA supplies DA as a service from operators who restake ETH and attest to availability. The aim is high throughput and lower fees than on‑L1 posting, with economic security derived from ETH via restaking. Security rests on the committee’s attestations and slashing, not on base‑layer consensus over the data blob itself.

Who uses it?

GTE (on MegaETH) → EigenDA for DA, decoupling execution from Ethereum’s DA constraints.

When to choose. Push throughput/fee reductions while keeping ETH‑anchored economics; model operator‑set assumptions and monitoring carefully.

6.4 Monolithic chains and DA

Sovereign/app‑chain designs (e.g., Hyperliquid, dYdX chain) internalize DA: block propagation among validators carries the DA obligation. There’s no external DA bill, but exit/verification depends on the chain’s validator set and any bridge/light‑client you expose to other ecosystems.

6.5 What to evaluate

Evaluating DA backend primarily depends on four checks:

Economics: effective cost per event after compression and expected fee volatility across blobs/Celestia/EigenDA
Verification path: what a light client must do—L1 consensus, DAS, or restaked‑operator attestations—and how it behaves under withholding
Exit guarantees: whether posted data support forced inclusion and forced withdrawals end‑to‑end, and the gap between settlement and withdrawal finality
Operator/interop assumptions: committee/validator incentives, monitoring and slashing where applicable, and whether downstream integrations require Ethereum‑resident data or can consume Celestia/EigenDA artifacts.

7. Who Benefits: Retail / Pro / Institutional

Ultimately, technology is a means to an end: serving the needs of traders and liquidity providers. The innovations in architecture, performance, and security translate into distinct advantages for different user segments.

7.1 Retail

Retail optimizes for low cost, smooth UX, and credible self‑custody. Many next‑gen CLOBs sponsor gas or batch settlements so users mainly pay trading fees; combined with professional maker liquidity, this reduces slippage relative to legacy AMMs. Interfaces mirror CEX polish (mobile, one‑click, cancel‑on‑disconnect). The caveat is awareness of soft vs hard finality on modular stacks: actions feel instant (soft acks in ms) but only become irreversible at L1 settlement; good UX surfaces that window and provides escape‑hatch guidance. Monolithic venues compress the gap entirely by offering hard finality on commit, at the cost of leaving Ethereum’s composability unless bridged.

7.2 Professional (MMs, prop, HFT, systematic)

Pros care about deterministic latency, tail behavior under load, and execution integrity. Monolithic chains minimize control‑plane hops, so match→commit has no soft→hard gap to hedge. Modular stacks can match or beat soft latency, but teams must model the interim risk and withdrawal timelines. Fairness controls are decisive: application‑specific sequencing (e.g., Bullet) constrains reordering at intake; provable matching (e.g., Lighter) cryptographically enforces price‑time priority inside the book. Robust APIs and Ethereum‑aligned settlement/DA enable cross‑protocol strategies (e.g., hedging perps with on‑chain options) without CEX silo frictions.

7.3 Institutional (funds, treasuries, corporates)

Institutions add custody, compliance, and audit to performance requirements. Operationally, they expect segregated accounts, MPC/HSM key management, withdrawal allow‑lists, and attestable logs spanning order acknowledgment to L1 inclusion. Modular venues that settle and post DA on Ethereum integrate cleanly with custodians and chain‑analytics providers and produce auditor‑friendly, replayable records for NAV/P&L. Compliance demands include KYC/KYB gating where appropriate, sanctions screening on deposit/withdrawal paths, and exportable evidence for regulators. For information‑sensitive flow, privacy‑preserving publication (e.g., encrypted blobs on Celestia) reduces leakage while preserving L1‑anchored exits—useful for minimizing signaling in large orders, though not equivalent to full dark pools. Monolithic venues can meet these bars if they expose light‑client/bridge proofs, independent indexing, and enterprise custody integrations; in exchange, they deliver immediate, irreversible settlement that simplifies liquidation SLAs.

Rules of thumb.

Retail: choose modular for low fees and Ethereum‑native composability; monolithic for immediate finality within a single ecosystem.
Pros: pick monolithic for latency determinism; modular with strong fairness controls and clear finality windows for cross‑protocol strategies.
Institutions: modular with ETH‑aligned settlement/DA shortens diligence and custody onboarding; monolithic suits mandates that prioritize instant hard finality and can underwrite a sovereign validator/bridge model.

Conclusion

The competition to build the definitive on-chain trading venue has moved beyond simple AMMs into a sophisticated war of architectural philosophies. The monolithic and modular approaches each present a distinct set of trade-offs, forcing developers and users to make critical decisions about latency, finality, cost, and composability. Understanding this landscape, from the nuances of data availability to the guarantees of an escape hatch, is no longer optional for anyone serious about on-chain trading.

With this foundational framework in place, we are now equipped to dissect the contenders in the CLOB Wars. In Part 2 of this series, we will move from theory to practice, applying this lens to evaluate the leading next-generation CLOBs. We will explore the unique features, strategic bets, and cryptoeconomic models of individual platforms, assessing why they win and where they struggle in the race to become DeFi's endgame exchange.

‍

References

‍

Share this post