Background

CLOB-based DEXs are not new. In fact, the very first attempts at creating decentralized exchanges mostly tried using order books. Some of these date as far back as 2012. Platforms like the XRP Ledger's native DEX enabled users to trade assets via 'offers' that essentially acted as limit orders. However, broader functionality, such as market orders, was limited. Other notable attempts included Counterparty, which let users trade tokens through a meta-asset protocol built on top of Bitcoin, and BitShares, which built a DEX as a core component of its blockchain. Ethereum also hosted several order book projects early in its history, with the likes of EtherDelta, Oasis DEX, IDEX, 0x, and others building order book DEXs with a mix of on and off chain components throughout 2016 and 2017.

These early CLOB projects struggled to attract much activity and liquidity, onchain trading volumes were essentially negligible up until 2018 and 2019 with the rise of AMMs. CLOB DEXs turned out not to be a good fit for early blockchain infrastructure. Some of their major issues included:

• High transaction costs: Trading in an order book exchange, particularly as a liquidity provider, requires frequent interactions given the need to continually post and cancel orders to update quotes in accordance with market conditions. Since these actions tend to require separate transactions in fully onchain CLOB DEXs, transaction fees can quickly add up and make market making uneconomical, particularly in low throughput blockchains where blockspace is limited and fees are high.

  
  

• MEV: Given the block proposer’s monopoly on transaction ordering, profitable trades are liable to being front-run by block builders/proposers. On the liquidity provider side, stale orders are likely to get picked off by block builders before cancel orders are processed. This latter problem is made worse by slow block times as offchain prices can diverge between two blocks of transactions, creating stale quotes that liquidity providers can’t update, which block builders can then exploit for profit. 
  
  

• Liquidity fragmentation: To avoid the issues above with fully onchain orderbooks, some early CLOBs like EtherDelta and 0x explored hybrid models with offchain orderbooks and onchain settlement. However, these ran into liquidity fragmentation issues whereby relayers would run separate orderbooks with little incentive to share order flow.

Trust and regulation: Given the use of centralized, offchain components in some hybrid CLOB models, users still had to trust the exchange when it came to fairly sequencing and matching orders. Such centralized components also exposed these projects to regulatory risk, a risk that became very real in 2018 when the SEC charged the founder of EtherDelta with running an unregistered national securities exchange.

The issues above prevented early CLOB DEXs from gaining much adoption. DEX adoption instead happened through AMMs. Volumes in decentralized trading venues started taking off in 2020 with the advent of DeFi summer. By Q3 of 2020, AMMs like Uniswap and Curve represented over 80% of DEX volume, with Uniswap itself doing around 65% of DEX volume in September 2020 surpassing Coinbase’s volume that month. 

AMM DEXs quickly overtook CLOB ones by being a far better fit for blockchain infrastructure at the time. The main benefits that led to AMM dominance included:

• Continuous onchain liquidity: Since AMMs quote prices algorithmically from their pooled reserves, liquidity can be provided passively without requiring frequent order posting and cancellation. Providing liquidity via AMMs is thus more computationally efficient, a key benefit in a constrained environment like a blockchain. Trading with an AMM is also more reliable for takers, since the pool always acts as a counterparty – a significant improvement over unreliable matching and settlement in early onchain CLOBs.
  
  

• Composability: As a fully onchain DeFi primitive, AMMs can easily be composed with other DeFi apps like lending markets and yield aggregators, resulting in a virtuous cycle of composable applications providing more utility, therefore attracting more users and liquidity, improving DeFi application utility even further.
  
  

• Liquidity mining incentives & easy liquidity provision: Given the ease of passive liquidity provision into AMM pools, protocols were able to aggregate large amounts of liquidity from users beyond the specialized traders that usually provide liquidity in order book exchanges. AMMs quickly leveraged this to become the most liquid venues for onchain trading.
  
  

• Permissionless Listing: Anyone could easily create and seed an AMM pool for a new asset and offer incentives for liquidity provision. This meant new and long tail assets that people wanted to trade were usually available in AMMs before being listed in CLOB DEXs or CEXs. 

AMMs achieved close-to-complete onchain dominance thanks to these features. Since trading on AMMs took off in 2020, DEXs have consistently captured greater market share from CEXs, largely on the back of AMM protocols.

Despite their benefits and the key role they’ve played in making onchain trading a practical reality, AMMs do have drawbacks that mean they may not be the ideal choice for all onchain markets. 

One major drawback of constant function AMMs like Uniswap v2 relates to their relatively high slippage for large trades. Because Uniswap v2-style AMMs deploy liquidity across the entire price curve, liquidity at any specific price is shallow, resulting in significant price impact on large trades. For LPs, on the flipside, deploying their liquidity across all prices means their return on capital is lower than it could be, since most of their liquidity is inactive at any point in time.

These issues were largely addressed with the arrival of concentrated liquidity AMMs (CLMMs) with Uniswap v3, which allow liquidity providers to select specific price ranges where their liquidity is active. This leads to better capital efficiency and return on capital for LPs since they can strategically choose where to allocate their liquidity to earn fees, and it also leads to better slippage dynamics for traders with less market impact for large trades as liquidity tends to concentrate near market price.

Despite improvements on these fronts, AMMs continue having drawbacks in certain areas compared to CLOBs. The main drawbacks include:

• Loss-Versus-Rebalancing (LVR): LVR is the cost AMM LPs incur from adverse selection as arbitrageurs pick off stale AMM prices when these diverge from the external market price. LVR is an inherent feature of traditional AMM designs, which count on arbitrageurs to update the AMM price and bring it in line with the market price. The incentive for arbitrageurs to update the pool price, however, comes at the cost of LPs, even in the presence of fees. More sophisticated recent designs address LVR by batching and auctioning off the right to arbitrage a pool, with auction proceeds being redistributed back to LPs. These mechanisms however, tend to add complexity, can increase latency, and may break composability. While adverse selection can also happen in CLOBs, liquidity providers have greater control over order placement, cancellation, and the prices they quote, allowing them to update their orders to prevent them from becoming stale and manage their risk by, for example, widening spreads.

• Impermanent Loss (IL): Providing liquidity into an AMM usually involves providing amounts of the two tokens into the pool. Impermanent loss captures the shortfall LPs face as their positions in the AMM pool rebalance between the two tokens, compared to the value their portfolio would have had if they had just held the two tokens at the original ratio. A loss tends to occur here because when the market prices of the two assets shift, arbitrageurs sell the underperforming asset into the pool to buy the outperforming asset, so the pool rebalances liquidity providers toward the underperforming asset such that their portfolio ends up being worth less than if they had just held the original quantities. This loss is called ‘impermament’ because it can technically disappear if prices revert back. On CLOBs, there’s no strict rule that forces liquidity providers to rebalance between the two assets in a market like on AMMs, so IL doesn’t apply to CLOB makers.
  
  

• Oracle Risk: Oracle risk is primarily a drawback for AMM-based perps DEXs. Unlike spot AMM DEXs, perps AMM protocols tend to heavily rely on oracles to quote the execution price for trades and determine funding payments. If this oracle price lags, or is manipulated, the pool can be arbitraged, or in an extreme case exploited, at the expense of liquidity providers.

These factors make it so liquidity provision into AMMs is frequently unprofitable in any but the most traded pools with the most organic flow. This has led to a situation where liquidity providers tend to avoid AMM pools unless heavily incentivized, which imposes high costs on projects launching tokens as they need to reward liquidity provision with token airdrops for retail LPs onchain, or strike offchain agreements with professional liquidity providers.

Despite the leap forward in onchain trading that AMMs ushered in, most of crypto’s trading volume still occurs in centralized exchanges where liquidity remains stronger for most assets and derivatives. This is largely thanks to the presence of sophisticated liquidity providers. CEX CLOBs allow these liquidity providers to service the market by giving them granular control over their liquidity provision through performant APIs for order placement and cancellation, rich order types, fee tiers, cross-margin, and a variety of services and facilities that enable liquidity providers to operate in a highly capital efficient manner. DEXs can compete to onboard this deep liquidity to the degree that they can replicate a similar trading experience. Although this has been practically impossible for most of crypto history given infrastructure constraints, things are rapidly changing with the advent of DEX CLOBs that are quickly attracting volume and activity.

1. Why CLOBs Now? The Infrastructure Revolution

The previous section highlighted a crucial paradox: while AMMs successfully bootstrapped onchain trading, their inherent inefficiencies meant professional market makers and the deepest pools of liquidity largely remained on centralized exchanges, which offered the superior performance of the CLOB model. 

This reality begs the central question of this report: if the CLOB is the undisputed, battle-tested standard for efficient markets, why did it fail to gain traction in DeFi's early years, and why is it suddenly dominant now?

The answer is not a matter of market fit, the demand was always there, but one of long-standing technical feasibility. For years, a fundamental infrastructure gap created an unbridgeable chasm between the high-frequency demands of a CLOB and the capabilities of existing blockchains. 

This chasm, defined by severe limitations in throughput, latency, and cost, forced DeFi's evolution down a path of architectural compromises and ultimately gave rise to the AMM. This section dissects the technological revolution that is finally closing that gap.

The Infrastructure Gap: Why First and Second Generation Blockchains Failed CLOBs

The core requirements of a CLOB, fast, low-cost order placement and cancellation, sub-second latency, and complex matching logic, are fundamentally at odds with the design principles of early blockchains.

First-generation blockchains like Bitcoin, while revolutionary for peer-to-peer value transfer, were purpose-built for security and predictability, not high-frequency applications. With a sustained rate of merely 3-7 transactions per second, bottlenecked by a 1MB block size and 10-minute block times, its capacity is orders of magnitude below that of traditional payment networks like Visa (~1,700 TPS) or Mastercard (~5,000 TPS). Beyond raw throughput, its non-Turing complete, stateless scripting language makes implementing the stateful, iterative logic of an order book a technical impossibility.

Ethereum represented a quantum leap with the introduction of the EVM and thereby smart contracts, yet it too was fundamentally unsuited for CLOBs. With a capacity of just 12-30 TPS, its sequential transaction processing model, where every state change must be executed in a single thread, is devastating for a CLOB. A market maker seeking to update 50 quotes would need to submit 50 separate transactions, processed one by one. By the time the last transaction was confirmed 12 seconds later, market conditions would have rendered the quotes completely obsolete.

This architectural bottleneck was compounded by two crippling (economic and security) realities:

1. Prohibitive Gas Costs: Operating a CLOB requires a massive volume of state-changing operations (placements, cancellations, matches). On Ethereum, where a single complex transaction could peak at over $196 during the 2021 NFT boom, the cost for a market maker to maintain a competitive presence would have been astronomical during these times. Even today, implementing an onchain  CLOB on Ethereum remains impossible due to the limited block space, the gas limits per block, and ultimately the gas fees that this leads to amid demand (a.k.a. competition around block inclusion).

   
   

2. Maximum Extractable Value (MEV): The transparent mempool and sequential processing of the EVM created a predatory environment. MEV operators, using strategies like sandwich attacks, have systematically extracted billions from users, imposing a hidden tax on every trade. For liquidity providers on a CLOB, this would manifest as constant front-running, making profitable market making untenable. The economic impact of this predatory environment is staggering. Based on Flashbots data, daily MEV revenue on Ethereum stabilized around $300,000 in 2024, with sandwich attacks alone accounting for over $289 million in extracted value. The impact is notorious as MEV bots like "jaredfromsubway" have extracted over $1 million in a single week by sandwiching memecoin traders in the past. This constant, extractive pressure makes providing liquidity on any transparent, sequentially processing L1 an often fundamentally unprofitable endeavor for all but the most sophisticated players.

Finally, the most insurmountable barrier has always been latency. State-of-the-art high-frequency trading (HFT) firms in traditional finance measure their "tick-to-trade" latency in the 750 to 800 nanosecond range. In stark contrast, even a centralized crypto exchange like Binance operates with a 5-25 millisecond latency, while Ethereum’s 12-second block time represents a literal eternity. Even today's fastest blockchains, like Solana or Aptos, still require around half a second (400,000,000 - 500,000,000 nanoseconds) for finality. This isn't just a difference in degree, it's a difference in kind. This immense latency chasm made professional-grade on-chain trading impossible, forcing DeFi’s first wave to be dominated by slower, less efficient, but infrastructure-compatible models like the AMM that could tolerate such delays.

The dYdX Experiment: A Journey from Compromise to Sovereignty

However, efforts to bring CLOBs onchain in a functional manner continued over the years. No project better illustrates this journey from compromise to viability than dYdX. Recognizing the insurmountable barriers of Ethereum L1, they pioneered an evolutionary path that the entire industry has watched closely, and that in many ways pioneered today’s CLOB implementation approaches in Web3.

dYdX Phase 1: The StarkEx Hybrid Architecture

In April 2021, dYdX launched its perpetuals platform on StarkWare's StarkEx, a L2 scalability engine built on Ethereum. This "hybrid" architecture was a masterclass in pragmatic engineering, moving the computationally intensive components offchain while anchoring security to Ethereum (an approach that later became central to Ethereum’s rollup-centric roadmap and the broader modular thesis).

• Offchain Performance: The order book and matching engine were handled by a centralized StarkEx Service operated by dYdX Trading Inc., comprising a Gateway, Batcher, and Ambassador. This service managed the state of orders, executed transactions, and batched them for onchain settlement, achieving processing speeds of thousands of TPS and eliminating gas costs for traders entirely.

  
  

  

  
  

• Onchain Security: Batches of trades were proven valid using STARKs generated by the Shared Prover (SHARP) service and written in the Cairo language. These proofs were verified by smart contracts on Ethereum, ensuring user funds remained non-custodial and the final state was secured by L1 consensus. The system maintained two critical Merkle trees onchain: a Balances Tree for user positions and collateral, and an Orders Tree to prevent replays.

The model was an undeniable success, processing over $1 Trillion in cumulative volume. However, it exposed a fundamental tension. As the StarkEx documentation acknowledges, "the operator is the only entity that can propose blocks." This meant dYdX Inc. retained control over transaction sequencing and order matching. The system's liveness and censorship resistance were dependent on this single, trusted operator. For a protocol aiming for full decentralization, this was a temporary solution.

dYdX Phase 2: The Pivot to a Sovereign Appchain

This architectural compromise led dYdX to a critical realization, articulated in their v4 announcement: "the decentralization of a system is equal to that of its least decentralized component." They concluded that no existing L1 or L2 could handle the throughput for a truly decentralized order book, which, by their measure, processes about 10 trades per second but requires handling 1,000 order placements and cancellations per second, a 100x greater demand on the system. After exploring all options, they catalyzed a pivot to a sovereign, application-specific blockchain built using the Cosmos SDK, stating it offered the "full customizability over how the blockchain itself works". This represented a fundamental shift: trading the security anchored on Ethereum for complete control over the entire protocol stack.

The core innovation of that new setup was its unique order book architecture. As detailed in their docs, each validator runs an in-memory order book that is gossiped between nodes but is never committed to onchain consensus. Only the matched trades are committed to the blockchain each block. This design quite elegantly circumvented throughput limitations by handling high-frequency, ephemeral order data via an offchain P2P network, while still committing the economically significant state changes onchain in a decentralized manner.

By building its own L1, dYdX gained:

• Full Stack Control: The ability to customize every aspect of the chain, from consensus to custom logic for short-term (in-memory) vs. long-term (onchain) orders and sophisticated margin systems.

  
  

• Elimination of Trading Gas Fees: Traders pay fees on executed trades, creating a CEX-like UX and a sustainable economic model for the chain.

  
  

• Maximized Decentralization: Removing the centralized sequencer and centralized data availability committee enables the entire protocol to be run by a distributed network of validators.

New Architectural Complexities and Dependencies

As we just discussed in the previous section, the initial L2 appchain approach, while powerful, introduced a new set of trade-offs and external dependencies that are critical to understanding the current landscape. While sovereignty provides control, the path chosen, whether it’s a modular L2 or a fully sovereign L1, fundamentally alters the trust assumptions, engineering complexity, and value capture dynamics of the system.

Modular systems like StarkEx, and the modern L2 appchains that followed, offer a dramatically faster, cheaper, and less complex path to market. However, this ease of implementation comes at the cost of creating a "modular patchwork" with potentially heavy dependencies on external infrastructure layers. These dependencies dilute the trust assumptions of the system:

• Centralized Sequencers: Many L2 appchains launch with a centralized sequencer to guarantee performance, introducing a single point of failure, a liveness risk, and a vector for censorship or MEV extraction.

  
  

• External DA Layers: Reliance on third-party data availability layers like Celestia or EigenDA shifts security guarantees away from the settlement layer's full validator set to the economic security of the DA provider.

  
  

• Oracle Dependencies: The system becomes reliant on external oracles for price feeds, which can be subject to manipulation or latency issues, a stark contrast to a fully integrated system like Hyperliquid, which embeds its oracle logic directly into the L1 consensus (or rather validator clients).

From a pure design perspective, a fully integrated, app-specific L1 where the order book, sequencing, and core primitives are enshrined in the validator logic is architecturally superior. It minimizes external dependencies, provides maximum control over the execution environment, and ensures value (from MEV and fees) is captured within the protocol rather than leaking to external infrastructure providers.

However, this superiority comes at a monumental cost. Building a performant, Hyperliquid-style L1 from scratch is an incredibly difficult, expensive (see how much funds chains like Monad, Solana or Sui raised to bring their L1s to market), and time-consuming engineering endeavor. The dYdX Chain (even though not entirely built from scratch given usage of Cosmos SDK) serves as a good case study for this challenge. As an early mover, their ambition to build a sovereign appchain was visionary, and their success validated the model. 

Yet, they did not achieve a level of dominance like Hyperliquid did more recently, in part because of the immense difficulty of building such a system, but also due to the inherent challenges of the sovereign model. By becoming a siloed "island", they faced significant friction in attracting users and liquidity, lacking a native, trustless bridge to a major user/liquidity hub like Ethereum. 

This illustrates the core dilemma: the architecturally superior monolithic path is brutally difficult and risks isolation, while the easier modular path introduces a web of dependencies and potentially diluted trust. These complexities are precisely what set the stage for Hyperliquid's purpose-built, and ultimately more successful, design.

Hyperliquid: The Breakthrough in Unified, High-Performance Architecture

While dYdX created the blueprint for a sovereign L1 CLOB appchain, Hyperliquid stands out as the breakthrough implementation that has achieved CEX-level performance on a fully onchain CLOB implemented as a proprietary L1 built entirely from first principles.

Hyperliquid does not adopt a general-purpose framework. It employs a custom consensus protocol, HyperBFT (inspired by HotStuff), and a networking stack purpose-built for exchange operations. This specialized, vertically integrated design yields dramatic performance gains:

• Throughput & Latency: Hyperliquid currently processes up to 200,000 orders per second with a median end-to-end latency of 0.2 seconds (at 70ms block times). This is not a theoretical maximum but a live, mainnet reality that has already settled over trillions in volume.

  
  

• Unified Architecture: The state is split into two seamlessly interoperable components secured by the same consensus protocol: HyperCore, which handles the onchain order books and clearinghouse, and the HyperEVM, a general-purpose smart contract environment built around it. This unified state allows for unparalleled composability, or more specifically: smart contracts can interact directly and synchronously with the CLOB's state without bridging or delays. For more information on Hyperliquid’s unique dual architecture, also make sure to check our report here.

The key distinction from the early dYdX StarkEx model (or other modular rollup-based network designs as we’ll explore later on in this report) is Hyperliquid's complete onchain decentralization. Unlike the dYdX Cosmos chain, which separates the offchain orderbook gossip from onchain trade settlement, Hyperliquid's consensus and execution are semantically aware of order book operations. This means the core logic of the blockchain understands the difference between transaction types. Within a single proposed block, actions are intelligently sorted: cancellations are processed first, followed by GTC/IOC orders. This deterministic ordering eliminates common race conditions and ensures a fairer, more predictable matching process compared to a general-purpose chain where transactions are processed more agnostically based on arrival time or fees. This architecture proves that the infrastructure has finally caught up to the demands of professional trading, delivering sub-second latency and massive throughput without sacrificing the core tenets of decentralization. The success of these approaches has validated the appchain thesis and ignited an infrastructural arms race, with builders now racing down two distinct but converging paths to finally bring professional trading fully onchain.

The New Infrastructure Landscape: Two Paths to Performance

As already hinted at before, the journey from Ethereum's intractable limitations to the CEX-grade performance of modern appchains like Hyperliquid marks a true paradigm shift. The core problem has evolved from "is an onchain CLOB possible?" to "what is the optimal architecture to build one?" This explosion of innovation has resulted in a landscape now bifurcated into two distinct, competing philosophies for achieving the holy grail of a fully onchain, high-performance CLOB.

The first path is the modular approach, disaggregating the blockchain stack to allow developers to assemble bespoke, high-performance rollups using best-in-class components for data availability, settlement, and execution. 

The second is the rise of next-generation monolithic and universally programmable, high-performance chains, pushing the boundaries of what's possible with integrated, hyper-optimized L1s purpose-built for the demands of trading.

Path 1: The Rise of Modular Appchains - Assembling the Stack

The modular appchain approach enables teams to construct custom L2 appchains by selecting specialized infra components for each layer of the stack. This dramatically lowers the barriers of entry, reducing deployment time from years to months and operating costs significantly compared to building a sovereign L1 from scratch. By disaggregating the traditional monolithic blockchain into discrete, optimizable layers (execution, data availability, settlement, and consensus) teams can focus on execution quality and user experience rather than reinventing fundamental infrastructure that already exists.

Technical Enabler 1: Data Availability (DA) - The Foundation of Modular Scaling

At its core, DA ensures that all transaction data necessary to reconstruct a blockchain's state is publicly accessible and verifiable. For rollups, this is non-negotiable. Without guaranteed data availability, a malicious operator could freeze user funds by withholding data. The DA "trilemma" forces teams to balance security, throughput, and cost, with different solutions offering unique trade-offs. Let’s have a look at the options in the market:

• Ethereum - The Gold Standard of Security: Ethereum remains the highest-assurance DA layer, backed by over $150 billion in staked ETH. Its ~12-second block times and strong economic finality provide institutional-grade guarantees. The EIP-4844 upgrade in March 2024 introduced "blobs", a separate, temporary storage market that reduced DA costs for rollups by 10-100x. It remains the premium option for many apps (incl. some CLOB appchain L2s like Paradex or Lighter) where security is paramount.

  
  

• Celestia - The Pioneer of the Modular Thesis: As the first dedicated DA blockchain that made it to market, Celestia offers a compelling balance of performance and cost. It currently supports 8MB blocks every 12 seconds, with upcoming upgrades promising 27 MB/s (with a testnet currently live at 128MB blocks, equalling 21.3 MB/s in data throughput) and a long-term roadmap to 1GB blocks. Its key innovation is Data Availability Sampling (DAS), allowing light clients to verify data by sampling small chunks, enabling the network to scale securely as more clients join. At approximately $0.07 per MB (a 55x cost reduction vs. Ethereum), it has become the preferred layer for cost-sensitive CLOB appchains like Bullet and Hibachi.
  
  

• EigenDA - Ethereum-Anchored Hyperscale: EigenDA leverages Ethereum's security through restaking, and achieved a launchday throughput of ~15MB/s (over 100x Ethereum's capacity) with sub-second latency. EigenDA V2 however, is already able to process 100 MB/s already with its Data Availability Committee (DAC) architecture enabling horizontal scaling but introduces trust assumptions on the committee operators. MegaETH (the first real-time EVM rollup on Ethereum) chose EigenDA for its extreme throughput, which is absolutely essential for making its real-time L2 architecture possible.
  
  

• Avail - The Validity-First Architecture: Avail uses a Nominated Proof of Stake (NPoS) consensus and KZG polynomial commitments to provide succinct proofs of data availability, achieving ~40-second finality. Its architecture prioritizes verifiable finality and cross-ecosystem interoperability, making it attractive for CLOBs that need to bridge assets across multiple ecosystems.

  
  

• Emerging Players: The DA landscape continues to evolve. Emerging projects like Hyve DA and 0G (ZeroGravity) are targeting the niche of trading-optimized DA (or in 0G’s case AI-optimized DA) with speculative targets of 1 GB/s and integrated long-term storage, respectively.

Technical Enabler 2: Zero-Knowledge (ZK) Proving - Cryptographic Truth at Scale

For CLOBs, ZK proofs are a transformative technology. They enable offchain execution at massive scale with verifiable correctness, provide mathematical guarantees against operator manipulation, and unlock privacy-preserving trading. Driven by algorithmic breakthroughs and hardware acceleration, proving costs have fallen rapidly, finally making ZK-secured CLOBs economically viable. The ZK landscape keeps growing as well:

Succinct (SP1) - The High-Performance Developer Platform: Succinct’s SP1 is a state-of-the-art, RISC-V-based zkVM that allows developers to generate proofs from standard Rust code without having to learn specialized languages first. It uses a high-performance STARK prover and wraps the output in a compact, cheap-to-verify Groth16 SNARK. This hybrid system can prove a batch of 1,000 complex perpetual trades in under 10 seconds, with comparably cheap onchain verification. Its low latency and developer-friendly approach have made it the choice for performance-focused CLOBs like Bullet and Hibachi (among other app-specific L2 designs).

Boundless - The "Uber for ZK Compute": Powering the entire RiscZero product suite, Boundless provides a universal marketplace where proof requests are fulfilled by a decentralized network of provers. Its "Proof of Verifiable Work" (PoVW) model rewards provers based on actual computation, creating a competitive market. With thousands of provers live, it offers elastic, on-demand capacity, making it ideal for CLOBs with variable, high-volume proving needs.

Competitive Dynamics - Succinct vs. Boundless: While both Succinct and Boundless are building high-performance zkVMs based on the RISC-V framework, they represent two distinct philosophies. Boundless operates as a fully open, permissionless marketplace (a.k.a. the "Uber for ZK compute") where any prover can participate. Its Proof of Verifiable Work (PoVW) model ensures provers are rewarded based on the actual compute (proving cycles) performed, fostering a competitive environment for cost and efficiency. This open network model is ideal for general-purpose verifiable compute and applications requiring elastic capacity. Succinct, in contrast, functions more like a high-performance "API for ZK proofs." Its hosted prover network uses an offchain auctioneer to assign a single, optimized prover to each job, prioritizing minimal latency for time-sensitive applications. This makes Succinct particularly well-suited for CLOB appchains, where consistent, low-latency proof generation is a core requirement (however performance gap between the two is narrow). While not exactly the same, the competition is often direct, with both platforms for example building rival ZK-powered frameworks for Optimistic rollups (OP Succinct vs. RiscZero's Kailua) and DA bridges (e.g. for Celestia), driving innovation across the entire ZK landscape.

• Starknet Provers - Battle-Tested at Scale: The Starknet stack is among the most mature ZK systems in production, having secured over $1 trillion in volume across applications like the original dYdX L2 or Immutable’s gaming/NFT chain. Its SHARP (Shared Prover) system recursively aggregates proofs from many applications, amortizing costs across the ecosystem. Paradex is an example of a CLOB appchain (L2) that leverages the full Starknet stack, benefiting from the battle-tested security and efficiency of the Cairo language and STARK proofs.

• The Verification Bottleneck and Specialized Solutions: While proof generation has become exponentially faster, the final step, a.k.a. onchain verification, remains a significant economic chokepoint. Verifying a single proof on Ethereum can cost anywhere from 200,000 to over 2 million gas ($20-$60 during congestion), often rendering high-frequency applications economically unviable. This has led to the rise of specialized verification layers that unbundle this function from monolithic L1s. zkVerify is a prime example here, operating as a dedicated L1 built on the Substrate framework exclusively for ZK proof verification. Instead of costly onchain computation, rollups simply submit proofs to zkVerify's network. The protocol uses "heterogeneous aggregation" meaning that all verified proofs in a given period are hashed into a Merkle tree, and the resulting Merkle root is published as a compact attestation to the target settlement layer (e.g., Ethereum). An application can then prove its state transition with an inexpensive Merkle proof of inclusion against this root, reducing verification costs by over 90%. This architecture not only solves the cost issue but also accelerates innovation, as new proof systems can be added as modules ("pallets") without requiring a hard fork of the settlement layer. Another example of specialized verification infrastructure is the EigeCloud-based AlignedLayer.

Technical Enabler 3: Settlement Layers - The Security Foundation

Settlement is the final source of truth in a modular system, or in other words: the layer where transactions achieve irreversible finality and proofs are verified. By separating execution from settlement, rollups can leverage the security of established L1s without inheriting their performance limitations. The choice of settlement layer determines core properties like economic security, finality time, and bridge risk.

• Ethereum - The Default Settlement Layer: With over $54 billion in TVL secured across dozens of L2s in all forms and colors, Ethereum is the dominant settlement layer. Its massive economic security, battle-tested consensus, and robust social contract make it the premier choice for high-value applications. For optimistic rollups, settlement involves a 7-day challenge period where anyone can submit a fault proof to slash a malicious sequencer. ZK rollups achieve faster finality by posting validity proofs that mathematically guarantee correctness, making the state transition final as soon as the proof is verified onchain.

  
  

• Solana - High-Performance Settlement: Solana is an increasingly established alternative for rollups (also called network extensions in Solana ecosystem) prioritizing performance. Its 400ms block times and sub-$0.001 transaction costs enable more frequent and cheaper settlement. However, this comes at the cost of lower economic security and a less battle-tested consensus environment compared to Ethereum.

  
  

• Bitcoin - The Emerging Settlement Option: Leveraging Bitcoin's unparalleled security and brand recognition is a growing trend. However, Bitcoin's limited programmability creates significant engineering challenges. Without native smart contracts, rollups must use novel constructions like BitVM (which enables optimistic computation verification on Bitcoin) or rely on federated bridges for asset transfers, introducing different trust assumptions. For these users, the engineering complexity is a worthwhile trade-off for leveraging the most secure and recognized asset in the world as a foundation for settlement.

Technical Enabler 4: Rollup Frameworks - The Assembly Layer

Rollup frameworks are the SDKs that assemble settlement, DA and ZK components into a cohesive L2, allowing teams to customize the execution environment and sequencer to fit the specific needs of a CLOB.

• Sovereign SDK - Built for High-Performance (Trading): The Sovereign SDK is specifically designed for high-performance use cases like trading. It grants developers complete control over the sequencer, enabling custom ordering policies like pure FIFO for fairness or "maker priority" for MEV protection, as implemented by Bullet. This results in ultra-low sub-10ms "soft confirmations," a CEX-grade user experience.

• Starknet Stack - ZK-Native and User-Centric: The SN Stack is a complete, vertically integrated framework for building ZK-secured applications using the Cairo language, a Rust-inspired VM optimized for STARK provability. This battle-tested stack, which powers Starknet mainnet itself, includes a rich tooling ecosystem for appchain development. Madara is an open-source framework for building customizable appchains, while Katana provides a high-performance local sequencer for testing demanding applications. For CLOBs like Paradex, the stack's native support for Account Abstraction is another key advantage, enabling CEX-like features such as gasless transactions, social logins, and session keys that are critical for broader retail adoption.

• Arbitrum Orbit - Arbitrum-Centric Liquidity Network: Arbitrum Orbit allows teams to launch customizable L3s that settle to Arbitrum One, tapping into its $4 billion in TVL. The Stylus upgrade, which introduces a Wasm-based VM that allows for Rust/C++ execution, could be a good fit for CLOBs needing to optimize performance-critical matching logic while remaining connected to the deep liquidity of a mature EVM ecosystem. For CLOBs, this comes with a strategic trade-off though: sacrificing some sovereignty to gain immediate access to one of the deepest liquidity pools in DeFi, solving the cold start problem that plagues many new exchanges.

  
  

• Optimism Stack (OP Stack) - Basis of the Superchain Vision: The OP Stack is the most adopted L2 stack in the Ethereum ecosystem, supporting all kinds of apps and multiple “plain vanilla” EVM chains, and has an underlying focus on creating a network of interoperable L2s (the "Superchain") as its endgame vision. For CLOB appchains, this offers the potential for native cross-chain composability and access to shared sequencing experiments, enabling novel market structures and potentially improved capital efficiency across ecosystems.

Technical Enabler 5: Oracles - The Data Layer

For a CLOB to function, it needs more than just a matching engine, it needs a source of truth on asset pricing. Oracles provide this truth, acting as the secure bridge between the onchain world of smart contracts and the offchain universe of real-time market data. This data is non-negotiable for critical functions like calculating funding rates for perpetual futures, marking assets to market for margin calculations, and triggering liquidations. While a fully integrated L1 like Hyperliquid can embed its oracle logic directly into its validator set, most modular appchains and apps built within general-purpose chains rely on external oracle networks. The performance of a CLOB is therefore inextricably linked to the speed, reliability, and security of its chosen oracle, making the oracle layer a critical battleground for innovation.

Chainlink

Chainlink is the undisputed market incumbent and is widely regarded as the institutional standard for decentralized data and secure offchain services. Its platform extends far beyond simple price data, providing a comprehensive suite of tools built on a foundation of hyper-reliability and crypto-economic security. For CLOBs, Chainlink offers a multi-layered value proposition that balances battle-tested security with new, high-performance solutions.

Its flagship Data Feeds product operates on a "push" model, where a decentralized network of high-quality, security-reviewed node operators sources data from premium aggregators. This data is aggregated and pushed onchain at predetermined intervals (e.g., price deviation or time). This architecture, secured by multiple layers of decentralization and backed by a staking system with slashing, prioritizes reliability and manipulation resistance, making it the bedrock for core functions like collateral valuation and settlement across DeFi.

Recognizing the need for lower latency in applications like derivatives trading, Chainlink introduced Data Streams. This product line operates on a high-frequency "pull" model, designed specifically for CLOBs and other latency-sensitive venues. With Data Streams, applications can pull cryptographically signed, low-latency price updates offchain at sub-second frequencies and post them onchain at their discretion. This gives protocols granular control over their data flow, allowing them to achieve CEX-level performance for their matching engines while retaining Chainlink's proven security guarantees.

Beyond data delivery, Chainlink's platform provides critical infrastructure that CLOBs increasingly rely on. Its Cross-Chain Interoperability Protocol (CCIP) has become an industry standard for secure cross-chain asset transfers and messaging, enabling CLOBs to operate across a multi-chain landscape without fragmenting liquidity. Furthermore, its Proof of Reserve (PoR) service provides automated, onchain verification of the reserves backing stablecoins and wrapped assets, a critical function for maintaining trust and stability in the markets a CLOB supports. This integrated suite solidifies Chainlink's position not just as an oracle, but as a foundational Web3 services platform.

Pyth Lazer

Pyth Lazer is a specialized oracle service engineered to eliminate the latency gaps inherent in traditional oracle designs, which can be exploited for arbitrage and create inefficiencies for time-sensitive protocols. It operates as a high-performance, permissioned solution tailored for applications where speed is the absolute priority, such as onchain CLOBs competing directly with centralized exchanges. While the core Pyth Network prioritizes decentralized security with 400ms updates from its appchain, Lazer adopts a pragmatic architectural trade-off to deliver CEX-grade performance.

The service provides highly customizable and granular data streams, with update frequencies as low as 1 millisecond, alongside options for 50ms and 200ms channels. This allows protocols to precisely tune their data consumption to their specific architectural needs, for example, using 1ms updates for the core matching engine while leveraging throttled streams for front-end displays to optimize performance. Beyond raw price data, Pyth Lazer provides a richer suite of market data, including real-time bid-ask spreads and market depth, equipping onchain venues with the high-fidelity information required for sophisticated risk management and liquidity strategies. This focus on performance has gained significant traction, with adoption from leading institutions like Coinbase International Exchange and support from top-tier trading firms like Wintermute, validating its utility for professional trading environments.

Canary Protocol

Canary positions itself as an oracle built for the institutional demands of the RWA era and high-frequency trading, directly challenging the perceived trade-off between speed and security. It achieves this by combining ultra-low latency performance with hardware-level cryptographic guarantees, aiming to provide what it terms "cryptographic certainty" at Wall Street speeds.

At the core of its architecture is Canary Nest, a system that runs oracle processes inside Trusted Execution Environments (TEEs) like Intel SGX and AWS Nitro. This design ensures that only approved, verified code can be executed, isolating the process from the underlying operating system and node operator. The integrity of every price feed is cryptographically attested by the hardware manufacturers themselves (e.g., Intel, AMD, AWS) and further secured with mechanisms like SSL pinning to prevent man-in-the-middle attacks. This model is complemented by adaptive guardrails that adjust to market volatility and multi-node quorum validation, designed to prevent fat-finger errors or the propagation of faulty API data.

While its foundation is in verifiable security, Canary now directly competes on performance. It delivers up to 1ms price feed updates for institutional-grade sources like Binance on high-performance chains like Rise Chain, placing it in the same elite latency class as the fastest solutions on the market. This combination of speed and hardware-enforced trust has led to significant adoption, with Canary already securing billions in assets for leading protocols such as EtherFi and Eigenlayer. For CLOBs, Canary offers a compelling value proposition: the ability to access real-time price data without relying solely on crypto-economic incentives, but on verifiable, hardware-attested truth.

eOracle Network

eOracle (EO) approaches the oracle problem from a modular and permissionless first principle, functioning not as a monolithic data provider but as a foundational platform for building custom oracle solutions. Its core thesis is that a one-size-fits-all oracle cannot adequately serve the diverse and specialized data needs of a maturing DeFi ecosystem. Built on EigenLayer, eOracle unbundles the oracle stack into a universal security layer, powered by ETH restakers, and a flexible data layer where any developer can deploy a bespoke Oracle Validated Service (OVS).

An OVS builder has full control over their oracle’s design, defining the specific data sources, aggregation logic, update frequency, and the economic conditions for rewarding and slashing node operators. The EO platform provides the underlying infrastructure for enforcement, using its network of staked operators to execute the custom logic and the "EO Chain" as a permanent, transparent ledger for all oracle activity. This architecture enables a competitive marketplace for specialized data. For a CLOB, this means moving beyond simple price feeds to create, for example, an OVS for real-time volatility surface data, an OVS for pricing exotic derivatives with custom offchain models, or a specialized oracle for verifying the collateral eligibility of tokenized real-world assets. By handling the complex security and coordination problems, eOracle empowers protocols to build or commission the exact data solutions they need, fostering permissionless innovation in onchain data provisioning.

SEDA Protocol

SEDA Protocol operates as a modular data layer built on a purpose-built L1 blockchain, designed to function as a programmable and chain-agnostic substrate for all data types. Its architecture is bifurcated to serve distinct market needs: SEDA Core offers a fully permissionless and decentralized framework where developers can deploy custom “Oracle Programs” to define bespoke data aggregation, proprietary sources, and complex onchain computations. This model prioritizes trust-minimization and flexibility. 

For performance-critical applications, SEDA provides SEDA Fast, a specialized, low-latency endpoint engineered for CLOBs and perpetuals exchanges, targeting sub-100 millisecond data delivery. This dual offering allows protocols to choose between uncompromising decentralization and CEX-level speed. SEDA’s focus on the CLOB ecosystem is further evidenced by its active role in shaping market standards, such as its collaboration on the HIP-3.1 oracle amendment for Hyperliquid. This proposal advocates for greater oracle flexibility for market deployers, including configurable price update caps and enforced multi-signature controls for data publishers. This framework positions SEDA as a versatile solution, providing both a trust-minimized, programmable base layer for complex DeFi and a high-performance data rail for institutional-grade trading.

Tying It All Together: The Modular Appchain Thesis Realized

The modular thesis is a step-function change that aims to solve the blockchain trilemma that has historically constrained growth across various DeFi verticals. Teams can now combine Ethereum-grade security for settlement, hyperscale throughput via specialized DA layers, sub-millisecond execution with custom rollup frameworks, specialized oracles for high-performance price feeds, and verifiable execution correctness through ZK proofs, without having to build it all from scratch.

The result is a 3,000x improvement in performance (from 15 to 50,000+ TPS) and a massive reduction in cost (down to <$0.001 per trade). More importantly, this democratizes access to institutional-grade infrastructure. A small team can now assemble a CLOB that would have required hundreds of millions in capital to be developed just a few years ago. As we enter the next market cycle, the necessary components are all production-ready, setting the stage for an explosion of innovation, and forcing a direct confrontation with the increasingly powerful monolithic chains vying for the same prize.

Path 2: Monolithic Performance - The Rise of Real-Time Blockchains

In direct competition with the modular appchain thesis we just explored, is the renaissance of monolithic chains and universally programmable network designs. This approach is not a regression to the performance-constrained L1s of the past, but a radical re-architecting of the integrated blockchain. The core philosophy is that by tightly coupling and co-optimizing all components of the stack (consensus, execution, and data storage), it is possible to achieve breakthrough performance, lower latency, and a more streamlined developer experience. These next-generation L1s and L2s are purpose-built for high-frequency/real-time applications, directly challenging the notion that disaggregation is the only path to scale.

The monolithic renaissance is driven by a simple observation: every abstraction layer introduces overhead, every external piece of infra adds third-party dependencies, and any centralized component dilutes trust assumptions. Monolithic chains eliminate these boundaries, creating a unified system where consensus, execution, and state management are co-designed for maximum efficiency. The result is performance that approaches, and in some cases even exceeds, centralized systems while maintaining decentralization.

Architectural Pillar 1: Parallel Execution Engines - Breaking the Sequential Bottleneck

First-, and second generation blockchains (as we’ve discussed previously in the context of the EVM and the limitations of Ethereum’s execution environment) process transactions sequentially because they assume every transaction could potentially conflict with every other. This conservative approach ensures consistency but creates a massive scaling bottleneck. Consider Ethereum processing a block: even if it contains 1,000 independent token transfers that don't interact, they must still be executed one by one. Modern servers have dozens or even hundreds of CPU cores sitting idle while traditional blockchains use just one.

Parallel execution shatters this limitation by identifying which transactions can safely run simultaneously. The challenge lies in determining transaction independence without creating inconsistencies, leading to different architectural approaches. Let’s have a look at the state of the market today:

• The Solana Virtual Machine (SVM): Pioneering Parallelism Solana's Sealevel runtime was the first to implement parallel execution at a global scale. Its key insight was requiring transactions to declare upfront which accounts they will read from and write to. This "access list" allows the scheduler to build a dependency graph and identify non-overlapping transactions that can execute concurrently. This allows Solana to sustain multiple thousands of TPS in production, with theoretical capacity exceeding 65,000 TPS. The upcoming Firedancer validator client, a complete rewrite in C++, has demonstrated over 1 million TPS in controlled environments through aggressive hardware optimizations like zero-copy networking and CPU cache optimization. Firedancer is expected to go live on mainnet in 2026, potentially making Solana the first blockchain to sustainably process millions of transactions per second. Solana's parallelism has enabled a thriving ecosystem of first-generation onchain CLOBs (partially hybrid models though given currently still persistent limitations of the L1 execution environment).

  
  

• The MoveVM Chains - Deterministic Parallelism & Enhanced Security: Born from Meta's Diem project, the Move language was designed for parallel execution of financial transactions. Its revolutionary "resource" model treats digital assets as linear types that cannot be copied or accidentally destroyed. This mathematical guarantee eliminates entire classes of bugs like re-entrancy attacks and allows the runtime to make stronger assumptions about transaction independence. If two transactions touch different resources, they are guaranteed to be independent.

1. Aptos - Industrial-Scale Parallelism: Aptos implements its Block-STM (Software Transactional Memory) engine, which optimistically executes all transactions in parallel and then efficiently re-executes only the small subset that had conflicts. This has enabled staggering performance, processing 326 million transactions in a single day with sustained throughput over 20,000 TPS. Aptos achieves this through innovations like collaborative scheduling, delta writes (only writing state changes), and parallel Merkle tree updates. This provides the ideal foundation for fully onchain CLOBs like Decibel, which leverages Aptos's speed for atomic liquidations of hundreds of positions in a single block.

   
   

2. Sui - Object-Centric Parallelism:Sui takes a radically different approach with its object-centric architecture, where everything is an object with a unique ID. If two transactions touch completely different objects, they can execute in parallel with mathematical certainty, no optimistic re-execution needed. This model enables DeepBook, a native, shared order book built into the L1. By providing a single, composable liquidity pool that has processed over 450,000 orders per day, DeepBook solves liquidity fragmentation at the protocol level, allowing multiple DEXs like Turbos Finance and Cetus to share the same underlying liquidity.

• Next-Generation Parallel EVM L1s: Bringing Performance to the masses recognizing the EVM's vast network effects, a new generation of chains is retrofitting parallelization onto EVM compatibility.

1. Monad - The Superscalar EVM: Monad implements techniques from modern CPU design, such as speculative execution where transactions are run in parallel and the correct state outcome is committed once dependencies are resolved. Its custom MonadDB supports concurrent state access with asynchronous I/O, allowing it to achieve 10,000 TPS. This architecture enables innovative CLOBs like Kuru, which blends AMM curves with order book liquidity for spot trading, and Perpl, a perpetual futures DEX that can calculate risk for thousands of positions in parallel.
   
   

2. Sei - The DeFi-Optimized Chain: Sei's current "Twin-Turbo" architecture introduced high-speed execution for EVM transactions, achieving hundreds of TPS in production. Its upcoming "Sei Giga" upgrade (that introduces the novel multi-proposer Autobahn consensus mechanism) targets even higher performance, providing the foundation for institutional-grade CLOBs like Monaco (more info on both Sei and Monaco later in chapter 4).

• MegaETH & Rise Chain - Real-Time EVM L2s: While not actually monolithic chains, these modular, but universally programmable rollups take extreme approaches to EVM performance, literally scaling it to its hardware limits. MegaETH holds its entire state in memory (100GB+ RAM), eliminating disk I/O to achieve 100,000 TPS with 1-10ms latency. Rise Chain uses a "pipeline" architecture and "shredded execution" to process batches of transactions independently, targeting 100,000 TPS with sub-5ms soft confirmations.

Architectural Pillar 2: Innovative Consensus for Low Latency

For CLOBs, low-latency finality is as critical as throughput. While traditional blockchain consensus requires multiple rounds of communication between validators, professional trading demands sub-second finality, a literal 1000x improvement that requires fundamental architectural changes. The theoretical minimum latency is bounded by the speed of light, for globally distributed validators, a single round trip takes at least 100-200ms. Achieving sub-second finality therefore requires next-generation monolithic chains to redesign consensus by either minimizing communication rounds or restricting validator geography.

• Pipelining and Asynchronous Execution: The key breakthrough enabling low-latency consensus is separating transaction ordering from execution.

1. MonadBFT: Achieves finality in a single 1-second block through aggressive pipelining. Validators speculatively execute transactions while simultaneously participating in consensus on their ordering. This separation allows consensus and execution to happen in parallel.

   
   

2. Sei's Autobahn BFT: Sei’s novel consensus (part of Giga upgrade) implements a multi-proposer model where multiple validators can propose blocks simultaneously, eliminating leader bottlenecks and achieving optimistic finality in ~35ms, with full finality reached in 400ms.

• DAG-Based Consensus and Fast Paths: Directed Acyclic Graph (DAG) systems allow parallel block production. Sui's Mysticeti consensus uses this to create a dual-path architecture. Simple transfers of owned objects bypass full consensus and achieve finality in ~200ms on the "fast path." Complex transactions involving shared objects, like order matching, take the ~400ms "consensus path." This dual model is perfect for CLOBs, offering near-instant finality for simple operations like deposits and withdrawals.

• Optimized BFT Variants and Novel Topologies

1. Solana's Tower BFT: Works with Proof-of-History (PoH), a cryptographic clock that timestamps transactions before consensus, dramatically reducing communication overhead and enabling 400ms block times. The upcoming Alpenglow upgrade targets 100-150ms finality.

   
   

2. Fogo: Takes a novel approach with Multi-Local Consensus, physically clustering validators in major financial data centers with activity shifting along trading hours (a.k.a. “follow the sun” model). This minimizes network latency where it matters the most, enabling 5ms local consensus and sub-200ms global consensus, optimizing for co-located, high-frequency trading.

Architectural Pillar 3: Optimized State and Storage

The Storage Bottleneck

Even with parallel execution and low-latency consensus, the storage layer can become a critical bottleneck. Traditional databases weren't designed for blockchain's unique access patterns: millions of random reads/writes per second with cryptographic verification of every change. Next-generation chains implement custom storage solutions optimized for their specific architectures.

• In-Memory State - Eliminating I/O Completely: MegaETH takes the radical approach of keeping its entire state in RAM. This eliminates disk I/O, reducing state access time from microseconds (for SSDs) to nanoseconds. SSDs typically have access times around 100 microseconds, while RAM access is approximately 10-70 nanoseconds, representing roughly a 1,000-10,000x improvement. The economics are increasingly viable as RAM prices fall. This "real-time architecture" allows its order matching engine to achieve performance identical to centralized exchanges, demonstrating 100,000 order updates per second.

  
  

• Custom Databases with Asynchronous I/O: MonadDB is a custom database built for parallel state access. It uses optimistic state reads, version control for speculative executions, and asynchronous writes. While Monad achieves 10,000 transactions per second, specific benchmarks for state operations per second have not been publicly verified. RiseDB on the other hand is a custom-built database designed as part of the RISE stack for improved speed and efficiency. It replaces Ethereum's Merkle Patricia Trie with a more efficient versioned Merkle tree structure to speed up state updates and access.

  
  

• Data Model Optimizations: The structure of state storage is as important as its speed. Sui's object model localizes state, allowing independent objects (like different orders) to be updated in parallel without conflicts. Aptos uses an in-memory, lock-free sparse Merkle tree implementation tailored specifically for caching and parallelization. This works with Block-STM to facilitate high-performance parallel state updates, enabling CLOBs like Decibel to process updates to multiple order books simultaneously during high volatility. For CLOBs, these storage optimizations directly translate to the ability to handle a higher volume of discrete state changes (order placements, cancellations, and fills) per second without the storage layer becoming a bottleneck.

Tying the Monolithic Thesis Together: Integration as a Performance Feature

The monolithic (or at least universally programmable) approach argues that true CEX-level performance can only be achieved through the tight, vertical integration of all layers and/or composable high-performance execution environments. By co-designing the consensus, execution, and storage layers, these chains achieve optimizations impossible in most contemporary “modular appchain” systems.

The Power of Co-Design

When every layer is designed together, powerful optimizations become possible:

• Hardware-Software Co-Design: Firedancer on Solana implements custom network drivers that bypass the operating system's kernel, reducing network latency by multiple orders of magnitude. This is only possible because Firedancer controls the entire stack.

  
  

• Consensus-Execution Integration: Monad's speculative execution during consensus would be impossible if consensus and execution were separate systems.

  
  

• Storage-Aware Execution: MegaETH's in-memory architecture influences its entire design, from transaction scheduling to state commitment schemes.

Developer Experience and Composability

General-purpose chains often also offer a simpler developer experience with a single SDK, a unified security model, and predictable performance without cross-layer coordination. Crucially, they offer atomic composability, where all applications on the same chain can interact synchronously in a single transaction. For CLOBs, this means faster development and easier integration with the broader DeFi ecosystem (which can be powerful in terms of ecosystem, liquidity and user bootstrapping). The performance ceiling of monolithic chains (approaching 1 million TPS with sub-100ms finality) offers a compelling vision: decentralized trading that's not just as good as centralized alternatives, but better.

2. Landscape Overview

The infrastructure revolution detailed in chapter 3 has not happened in a vacuum. It has catalyzed a Cambrian explosion of development, with dozens of teams racing to build the future of onchain trading. The theoretical debates between modular and monolithic architectures are now playing out in a live, competitive market. This section provides a deep dive into the current landscape, segmenting the key players by their chosen architectural philosophy and highlighting the specific CLOBs emerging within each ecosystem.

The Appchain Landscape: Specialization and Sovereignty

The appchain thesis follows the notion that for high-performance applications like CLOBs, a dedicated, sovereign, or semi-sovereign environment is necessary to guarantee execution quality and capture value. This has led to two distinct development paths: fully sovereign L1 appchains that control their own consensus, and modular L2 appchains that inherit security from a base layer while customizing execution.

• L1 Appchains: As established in Section 3, dYdX Chain (Cosmos SDK) and Hyperliquid (custom L1) are the pioneers and current benchmarks for the sovereign appchain model. dYdX validated the thesis that a custom chain was necessary for decentralization and performance, but its 1-second finality and reliance on IBC bridging have seen it lose ground to more performant designs. Hyperliquid demonstrated that a vertically integrated, purpose-built L1 could achieve CEX-level performance, dominating the market with almost $300 billion in 30-day volume and commanding 48.8% of all perp DEX open interest. Its custom HyperBFT consensus, sub-second finality, and gasless trading model created a powerful liquidity moat that remains the target for all aspiring competitors.

  
  

• L2 Appchains: The maturation of the modular stack we discussed in section 3 has enabled a new wave of L2 appchains that offer a faster and more capital-efficient path to market. These projects leverage shared security from established L1s while deploying custom execution environments to achieve specific performance, privacy, or UX goals.

1. Paradex - The Zero-Fee SuperExchange for the Internet Economy: Paradex represents a conscious departure from the legacy architecture of onchain exchanges, redesigning market structure from first principles to prioritize fairness and privacy. Built as a ZK rollup on the Starknet Stack, it leverages the battle-tested CairoVM and quantum-resistant STARK proofs to provide mathematical integrity. Its architecture enables a clean "Church and State" separation: Ethereum acts as the immutable judiciary for final settlement, while the Paradex appchain is the agile executive branch, free to innovate on its execution environment. Its profound innovation is its solution to the "cancel-priority" problem that gives HFTs a structural advantage. Its Retail Price Improvement (RPI) system (see visual below) creates a protected trading environment exclusively for UI traders by hiding RPI liquidity from the API, intelligently segmenting them from algorithmic flow. This allows market makers to quote tighter spreads for retail, enabling a sustainable Payment for Order Flow (PFOF) model that funds a zero-fee experience for retail traders. For institutional size, Paradex integrates a Request for Quote (RFQ) system, enabling larger orders to be processed seamlessly. The platform is a full-stack onchain prime brokerage, featuring a Universal Portfolio Margin engine that calculates risk across a unified portfolio in real-time, a computationally intensive task made feasible by Cairo. This is complemented by novel instruments like Perpetual Options, a multi-stream revenue model combining PFOF with vault performance fees and yield on deposits, and a multi-layered privacy stack with a no-mempool design and plans for ZK-encrypted accounts. Learn more in our deep dive here.

2. Bullet - The Network Extension That Turns Solana Into an Onchain Nasdaq: Bullet is a "network extension" for Solana, designed to provide a specialized, high-performance trading environment while remaining deeply integrated with the Solana ecosystem. It is a pioneering implementation of the Sovereign SDK, combining a modular architecture with ZK cryptography. Its stack is a synthesis of cutting-edge components: Bullet Core, a native Rust runtime for execution; Solana for settlement; Celestia for data availability; and Succinct's SP1 zkVM for verifiable proofs. This architecture is purpose-built for HFT-grade performance, with a centralized sequencer processing transactions in a streaming model to deliver ~1ms soft confirmations, a 400x improvement over Solana's native block time. Crucially, it implements application-specific sequencing, prioritizing maker orders and cancellations to protect liquidity providers from adverse selection. By providing dedicated blockspace, Bullet offers traders immunity from Solana's network-wide congestion. The product suite includes perpetuals, spot, and a money market governed by a multi-layered risk engine that includes an insurance fund and an Auto-Deleveraging (ADL) system as final backstops. Competitively, Bullet positions itself not as an isolated "island" like a sovereign L1, but as a high-performance metropolis deeply connected to the Solana "continent," inheriting its security and tapping into its multi-billion dollar TVL from day one. Learn more in our deep dive here.

3. Hibachi: Hibachi is a trading-optimized ZK-rollup designed as a “provable exchange,” prioritizing both speed and user privacy. Built with an offchain matching engine for sub-second execution, Hibachi leverages Succinct’s SP1 prover to generate zero-knowledge proofs that verify the fairness of its offchain operations. Unlike rollups that expose all transaction data publicly, Hibachi introduces a privacy-preserving model where encrypted trading data (balances, fills, order book states) is posted as encrypted blobs to Celestia’s data availability layer. This prevents counterparties from scraping positions while still ensuring verifiability through ZK proofs. Hibachi’s Wynn Upgrade also introduced a crucial censorship-resistance mechanism: a validator-based decryption scheme. In a "doomsday" scenario where the operator becomes malicious or goes offline, validators holding the decryption keys can unlock user data, allowing for forced withdrawals and permissionless state verification. This mechanism elegantly balances censorship resistance with confidentiality, a rare trade-off in the CLOB landscape, making it a blueprint for an "endgame exchange" that is as fast as offchain venues but as auditable and trust-minimized as DeFi itself.

   
   

4. Lighter: A ZK rollup purpose-built as a perpetual futures exchange, aiming to combine the transparency of onchain trading with the speed and fairness of centralized venues. Unlike general-purpose zkVM rollups, Lighter is designed specifically for perpetuals, with a verifiable matching engine and liquidation system hardwired into its custom ZK circuits. The design emphasizes provable fairness: order matching follows strict price-time priority, enforced by zk-SNARK proofs, ensuring that no sequencer can reorder or censor orders. At the market structure level, Lighter introduces a full suite of professional order types and safeguards like fat-finger checks. Its liquidation engine enforces a multi-tier margin system, and its fair price marking system blends oracle data with CEX and internal book prices to make liquidations more robust. If the sequencer stalls, users can exit via an emergency "Desert Mode" that relies on Ethereum-available data. Its go-to-market strategy directly targets Hyperliquid, differentiating with ZK-verified execution and a zero-fee model for retail, which has allowed it to process $195B in 30d volume in the past month.

   
   

5. Atlas: Developed by Ellipsis Labs (the team behind Solana's first onchain CLOB Phoenix), Atlas is a L2 blockchain purpose-built for "verifiable finance," settling to Ethereum but built on a custom, hyper-efficient implementation of the Solana Virtual Machine (SVM). Drawing from their experience scaling Phoenix to tens of billions in volume, the team designed Atlas with an opinionated architecture explicitly for trading. Its sequencer is engineered to prioritize risk-sensitive operations like market maker cancellations and liquidations, ensuring that stale orders are not unfairly picked off and that bad debt doesn't accumulate during volatility. This sequencing model directly supports tighter spreads and more efficient markets. Atlas also introduces rpcX, a redesigned server-side data parsing system that delivers structured, ready-to-use order book data, reducing latency for developers and trading systems. Finally, Atlas eliminates Solana’s reliance on Address Lookup Tables by expanding transaction size limits from ~1.2 KB to 12 KB, allowing complex, multi-asset operations like portfolio rebalances to be executed atomically.

   
   

6. Aevo: An L2 rollup built on the OP Stack, Aevo focuses on options and perpetuals trading. It uses an offchain order book with onchain settlement on Ethereum. Its architecture is designed for high-performance derivatives trading, offering a CEX-like experience while inheriting the security of Ethereum.

   
   

7. Apex: A ZK rollup built on the Starknet stack (more specifically using StarkEx), Apex provides a permissionless and non-custodial perpetual futures exchange. It focuses on delivering high-speed execution with low fees, leveraging the scalability of ZK proofs to offer a competitive trading environment.

   
   

8. EdgeX: Built on StarkWare's StarkEx, achieving a processing capacity of 200,000 orders per second with sub-10 millisecond matching latency. Its architecture follows a modular layered design with STARK-powered settlement anchored on Ethereum, and an upcoming V2 version that will transform EdgeX into a full financial settlement chain supporting diverse financial products beyond perpetuals.

   
   

9. Reya Network: Reya is a unique L2 designed as a liquidity and trading-optimized blockchain. Instead of a single DEX, Reya functions as a foundational layer with a shared liquidity pool that multiple trading front-ends can build upon, aiming to solve liquidity fragmentation at the network level.

The Standalone Primitive Landscape

Distinct from the appchain strategy of building a bespoke blockchain, another critical area of innovation focuses on developing standalone infrastructure primitives. These are not end-user trading venues, but rather foundational, embeddable engines designed to solve specific, systemic challenges that have historically hindered on-chain CLOBs. Instead of creating a new environment, these primitives provide portable solutions to core problems such as prohibitive gas costs on general-purpose chains and liquidity fragmentation across a multi-chain landscape. This section examines the key players building this essential middle layer of the CLOB stack.

• Clober: Clober is not just an onchain order book DEX, but a foundational infrastructure primitive designed to solve the core gas-inefficiency of running CLOBs on the EVM. At its core, Clober introduces LOBSTER (Limit Order Book with Segment Tree for Efficient oRder-matching). This engine addresses the two key bottlenecks of onchain order books: (1) expensive settlement when matching a single taker order against potentially thousands of small maker orders, and (2) inefficiently scanning across empty price ticks. LOBSTER solves these with a combination of claim ranges (makers claim fills in a separate transaction, avoiding costly loops during matching), segment trees (for efficient range queries over active orders), and the Octopus Heap (a custom data structure that only tracks active price levels). These optimizations cut maker and taker gas costs to near-AMM levels. This positions Clober as an embeddable engine that other DeFi protocols, from perpetual DEXs to lending markets, can integrate, mirroring how Uniswap’s AMM became a base layer for liquidity.

  
  

• Orderly: Permissionless liquidity infrastructure primitive that solves the fundamental fragmentation problem of multi-chain DeFi. At its core, Orderly introduces an omnichain shared orderbook architecture that unifies liquidity across all supported chains into a single, aggregated order book. This engine addresses the two critical bottlenecks of cross-chain trading: (1) fragmented liquidity pools that force traders to bridge assets and split orders across multiple venues, and (2) the complexity of maintaining separate orderbooks on each chain with inconsistent depth and pricing. Orderly solves these through a three-layer architecture: the Asset Layer (vaults on each chain holding user funds locally), the Settlement Layer (an OP Stack L2 that serves as the unified ledger for all trades), and the Engine Layer (a high-performance offchain matching engine delivering sub-second latency). LayerZero powers the cross-chain messaging between layers, enabling users to trade from any chain without bridging while accessing the combined liquidity of all chains. This positions Orderly as embeddable infrastructure that any DeFi application, from perpetual DEXs to spot aggregators to in-game swaps, can integrate, creating a shared liquidity backbone that rivals CEX performance while maintaining full self-custody.

These standalone primitives encapsulate a powerful trend towards unbundling core market functions from specific front-ends, creating shared infrastructure layers that any application can build upon. The logical endpoint of this approach is a unified liquidity backend that serves an entire ecosystem. Monaco represents another powerful implementation of this shared infrastructure philosophy, providing a unified, high-performance liquidity layer with no proprietary frontend and a permissionless revenue-sharing model for builders via its PitPass system. 

However, unlike the chain-agnostic primitives discussed here, Monaco is not a portable solution. Instead, it is a purpose-built trading layer designed to be natively integrated within and leverage the unique performance capabilities of a specific monolithic blockchain, a.k.a. Sei (which we will cover in the next chapter). This tight coupling between application-layer infrastructure and a hyper-optimized L1 serves as an ideal transition into our next section, which examines the rise of these powerful, universally programmable chains.

The Monolithic Landscape: Universally Programmable Performance

While appchains focus on specialization, the defenders of the monolithic approach argues that a sufficiently powerful, general-purpose blockchain can serve as the ideal foundation for all applications, including CLOBs. This has led to a fierce innovation cycle among high-performance L1s and L2s, spawning a Cambrian explosion of onchain trading venues.

• The Solana Ecosystem: As the first L1 to implement parallel execution at scale, Solana remains a dominant force, with over $12B in TVL. Its 400ms block times provide a strong foundation, but the very success that attracts users also creates its biggest challenge for professional trading. During periods of high volatility, the network's shared blockspace becomes congested, and its priority fee market becomes unpredictable. This is untenable for market makers who must reliably update thousands of quotes per minute and risk getting "sniped" if their cancellations don't land. It’s worth noting though that in the historic liquidation event on Friday October 10th, Solana demonstrated remarkable resilience, while Ethereum suffered serious congestion and skyrocketing gas fees, putting a significant burden on L2 execution as well. Yet, the Solana L1’s architectural limitations have capped the growth of onchain CLOBs and remain the primary problem that network extensions like Bullet (covered in the previous appchain section) are designed to solve. However, there is a bunch of perp DEX players building on Solana L1:

1. Drift V2: A leading Solana perpetuals DEX with $11 billion in 30d volume, Drift employs a hybrid "Liquidity Trifecta" model, combining a virtual AMM, a decentralized CLOB (DLOB), and "Just-In-Time" (JIT) auctions to ensure deep liquidity.

   
   

2. Phoenix: The first truly onchain CLOB on Solana, Phoenix maintains the entire order book onchain with atomic settlement. It uses a novel "seat" system where market makers reserve dedicated lanes for order updates, preventing congestion during volatile periods..

   
   

3. OpenBook V2: The successor to Serum, OpenBook V2 uses "event queues" that buffer and batch order updates to optimize for Solana's parallel scheduler, enabling sustained throughput of 1,000+ orders per second.

   
   

4. Pacifica: A newly launched hybrid CLOB on Solana that uses an offchain matching engine for performance while settling onchain. While currently building on Solana, the team has expressed ambitions to eventually launch its own sovereign L1.

   
   

5. Bulk: A recently announced project that has raised a seed round to build a new high-performance CLOB on Solana, indicating continued developer conviction in the ecosystem.

• Fogo - The Specialized SVM L1: Fogo is a high-performance L1 built on the SVM, founded by TradFi veterans from Citadel and Jump Trading. It takes a pragmatic approach of "minimum viable decentralization, maximum viable performance." Its architecture is built on three pillars: enshrining Firedancer as its canonical client for peak performance; Multi-Local Consensus, where validators are physically clustered in financial hubs to "follow the sun" and minimize latency; and a curated validator set to enforce high performance and curb MEV. Building on this specialized infrastructure is Ambient Finance, which introduces a dual-sided frequent batch auction (dsFBA) model. Instead of continuous matching, orders are accumulated each block and cleared simultaneously at a single oracle-determined price, shifting competition from speed to price and mitigating latency arbitrage.

• The Sei Ecosystem - A Trading-First EVM: Sei was designed from the ground up as a trading-optimized L1, combining parallel execution with native order matching at the protocol level (a vision Monaco now is about to complete). Its upcoming "Sei Giga" upgrade and Autobahn BFT consensus mechanism are set to push performance even further, creating a fertile ground for institutional-grade trading applications.

1. Monaco - Bringing Wall Street Onchain: Incubated by Sei Labs, Monaco is not just another DEX but a "Wall Street-Grade" trading layer designed to power a new ecosystem of onchain trading applications. Its architecture is a synthesis of microsecond performance and decentralized security, realizing the original vision of Sei as a blockchain purpose-built for trading. At its core is a high-performance, offchain matching engine built in Rust that achieves 5-25 microsecond (µs) cancel/replace execution, a latency comparable to Nasdaq. For users, this translates to a median execution speed of under one millisecond (p50) with 99% of all trades executing within a tight 10-20 millisecond window (p99), even during peak volatility. This represents a 1000x improvement over the median latency of current onchain CLOBs like Hyperliquid. This performance does not compromise on decentralization where it matters most: asset security and settlement. After an order is matched offchain, the Merkle root of the new state is committed and verified onchain by Sei's decentralized validator set, with final trade settlement occurring on the Sei EVM L1 in under 400ms. This hybrid model pragmatically centralizes the component where speed is the absolute priority (matching) while keeping balances and finality transparently on a trustless public ledger. Critically, Monaco has no frontend of its own. It serves purely as shared liquidity infrastructure, seeded from day one with tier 1 and tier 2 market makers. This solves the cold-start problem for new applications and creates a level playing field. This ethos is codified in PitPass, Monaco’s novel revenue-sharing model. A PitPass is a unique onchain identifier that allows any builder to programmatically earn a share of the trading fees generated by their users' order flow, creating a transparent and permissionless alternative to opaque PFOF deals. This positions Monaco as the foundational trading layer for a diverse ecosystem, with projects like Montecarlo, Symphony, Mach One or Citrex, already building on top of it. Learn more in our deep dive here.

• The MoveVM Ecosystems - Aptos & Sui: These chains leverage Move's revolutionary approach to smart contract security, where digital assets are first-class linear resources protected by the type system itself, combined with module-based access control, bytecode verification, and the elimination of dynamic dispatch, creating a fundamentally safer execution environment with parallel processing capabilities that prevents common vulnerabilities like reentrancy, double-spending, and unauthorized asset manipulation at the language level rather than through runtime checks.

1. Aptos Ecosystem: With its Block-STM engine enabling parallel execution and over 20,000 TPS, Aptos provides a robust environment for fully onchain CLOBs. Decibel is the most prominent example, building an onchain trading engine to unify spot and perpetuals, leveraging Aptos's speed for computationally intensive tasks like atomic liquidations across hundreds of positions in a single block. Kana Labs is another player, developing a CLOB-based DEX aiming to leverage the L1's high performance and sub-second finality.

2. Sui Ecosystem: The high-performance trading ecosystem on Sui is coalescing around DeepBook, a native shared order book built into the L1 protocol itself. By providing a single, composable liquidity pool that has processed over 450,000 orders per day, DeepBook solves liquidity fragmentation. Bluefin, a leading perpetuals DEX on Sui with >$2.8 billion in 30d volume, has recently launched Bluefin Pro, a fully onchain CLOB that leverages Sui's Mysticeti consensus for sub-millisecond matching and privacy features from Sui's Nautilus infrastructure, all while plugging into DeepBook's shared liquidity.

The Parallel EVM Frontier - Monad, MegaETH, and Rise: This new generation of chains is re-architecting the EVM itself to support parallel execution and real-time performance.

• Monad Ecosystem: As a high-performance, parallelized EVM-compatible L1 targeting 10,000 TPS with ~800ms finality, Monad is positioned as an environment where CLOBs can run fully onchain without performance compromises and experiment with deeper structural innovations. A recent research piece from the team lays out a vision for primitives that go beyond replicating CEX functionality, such as the "Omnibook" (a unified liquidity layer) and the "Parallelized Liquidity Orderbook" (PLOB), which are only feasible in a high-throughput, parallel environment.

1. Kuru is the flagship example, a fully onchain spot CLOB making a strategic bet on Monad's raw performance with a "decentralization is the whole point" philosophy. Its key innovation is its unique vaults system, which adapts AMM-like mechanics for the order book. Vaults split a pricing curve (e.g., x*y=k) into thousands of small resting limit orders, allowing anyone to provide passive liquidity without being a professional market maker. This design could potentially be further enhanced by integrating gas-optimizing primitives like Clober's LOBSTER engine, should it deploy on Monad.

   
   

2. Other projects in the ecosystem include the professional-grade perpetuals DEX Perpl, and newcomers Monday Trade.

• MegaETH Ecosystem: As an L2 targeting 100,000 TPS and sub-100ms latency with its radical in-memory state architecture, MegaETH is attracting projects focused on real-time execution, and full ecosystem composability (the ability for multiple complex applications to interact atomically within a single block).

1. Valhalla is a next-generation perpetual and spot exchange designed to marry app-specific sequencing with this composability. Unlike isolated appchains, Valhalla’s architecture runs a parallelized sequencer co-located with MegaETH’s, allowing it to achieve CEX-grade latency while retaining synchronous composability with other MegaETH applications. This enables atomic strategies impossible elsewhere, such as funding rate arbitrage without inventory risk or using idle perpetual liquidity as collateral in a lending protocol mid-block. This hybrid design is a direct answer to the limitations of siloed appchain architectures.

   
   

2. Avon is reimagining money markets by applying CLOB mechanics to lending and borrowing. It replaces static liquidity pools with an intent-based order book where borrowers and lenders post limit orders for credit, enabling real-time price discovery for interest rates. This computationally intensive model is only viable in a real-time environment like MegaETH (which is where Avon is building).

   
   

3. Other ecosystem projects include World Capital Markets (WCM), which is building a DeFi suite with universal margin accounts.

• Rise Chain Ecosystem: A "Gigagas" L2 targeting sub-5ms latency with its "shredded execution" model, Rise Chain is home to NitroDEX and Boom, both building fully onchain CLOB DEXs to leverage the platform's extreme performance and based sequencing model for inherited L1 decentralization.

  
  

• Other Notable Ecosystems:

1. Aster: Operating on the BNB Chain, Aster has seen rapid growth, reportedly processing billions of dollars in daily volume. However, while Aster self-reports a life-time volume of >$2.5T, the exchange was recently removed from DeFiLlama due to the submission of false data, which makes a fact-based assessment of adoption metrics difficult at this time. Like Pacifica, the team has noted long-term ambitions to launch its own L1, more specifically a sidechain to Binance’s BNBChain.

   
   

2. Fuel: Introducing a new paradigm with its UTXO-based FuelVM, Fuel is developing its own native CLOB in-house to showcase the unique capabilities of its highly parallel architecture.

Application-Controlled Execution: The Battle for Market Microstructure

Beyond the architectural choice between modular and monolithic stacks lies a more granular but equally critical battle: the control over market microstructure. The industry is rapidly moving beyond the paradigm of general-purpose, fee-driven transaction ordering towards Application-Controlled Execution (ACE), also known as “Application-Specific Sequencing (ASS)”, a model that gives applications granular control over how their transactions are ordered and settled. This represents a powerful tool to mitigate Maximal Extractable Value (MEV), enhance capital efficiency, and engineer fairer market dynamics. For CLOBs, mastering ACE is the key to solving fundamental structural problems and achieving true CEX-level sophistication.

At its core, ACE grants an application control over the "write-lock" for its own state. This allows CLOBs to implement opinionated ordering rules that are impossible in a shared sequencing environment. The most critical of these is priority cancellation. On a general-purpose chain, a market maker's attempt to cancel a stale quote during a price swing competes in a gas auction with arbitrage bots trying to snipe that very quote. More often than not, the bot wins. ACE allows a CLOB to enforce a rule that all cancellation requests in a batch are processed before any new taker orders. This simple guarantee fundamentally de-risks market making, enabling tighter spreads and deeper liquidity.

Implementations of this thesis are already live and define the competitive landscape, evolving from single-protocol control to permissionless, ecosystem-wide marketplaces.

1. Enshrined L1 & Appchain Sequencing

The most direct form of ACE is when a protocol controls its entire stack.

• Hyperliquid (Sovereign L1): As a sovereign L1, Hyperliquid enshrines its sequencing rules directly into its consensus. Its "semantically aware" block building sorts transactions to prioritize cancellations, a model that has proven to reduce toxic HFT flow and maintain deeper liquidity during volatility.

  
  

• Bullet (Modular Appchain): As a modular rollup, Bullet uses its control over its dedicated, centralized sequencer to implement similar maker-prioritizing rules, protecting its LPs from getting picked off due to Solana L1 congestion.

  
  

• Jupnet (Custom SVM Appchain): Jupnet is implementing its own form of Application-Specific Sequencing through a dual approach involving a permissioned leadership quorum and prioritized "Batch Transactions." While consensus remains open, the ability to build blocks is restricted to a group of leaders selected based on performance. More critically, Jupnet introduces gasless, sequentially executed "Batch Transactions" submitted by a sequencer. These batches are guaranteed top-of-block priority and cannot be reordered by the leader. This mechanism is designed to protect market makers by ensuring that essential actions, like canceling stale orders or updating oracles, are processed first, mitigating MEV and preventing losses from network congestion.

2. Permissionless Sequencing Marketplaces (The Solana ACE Roadmap)

The next evolution moves from sovereign control to open, permissionless systems. Solana's community-authored ACE roadmap exemplifies this, aiming to optimize the network's market microstructure. The core components include:

• Jito's Block Assembly Marketplace (BAM): This is the key enabling technology, decentralizing Jito's own block engine into a marketplace for custom sequencing. BAM comprises a network of nodes running in Trusted Execution Environments (TEEs), keeping transaction flow private until execution to mitigate front-running. Applications can use "Plugins" to deploy bespoke sequencing logic (e.g., taker speed bumps, quote protection) permissionlessly. This creates an open market for blockspace where developers can ship tailored order flow logic and even create new revenue streams.

  
  

• Supporting Infrastructure: This vision is supported by network-level upgrades like the DoubleZero fiber network to reduce physical latency and the upcoming Alpenglow consensus engine for ~150ms finality, demonstrating a full-stack commitment to optimizing the trading environment.

3. Order Flow Auctions and Batching

A different approach to ACE focuses not on continuous reordering but on batching transactions to neutralize latency advantages.

• Generalized Order Flow Auctions (FastLane): Protocols like FastLane are building generalized abstraction layers that allow any application to run its own order flow auction. This lets applications redirect MEV back to their users or treasuries, turning a predatory force into a sustainable revenue stream.

  
  

• Batch Auctions (Ambient Finance): As seen in the Fogo ecosystem, Ambient Finance uses a dual-sided frequent batch auction (dsFBA) model. By clearing all orders in a block at a single price, it shifts the basis of competition from speed to price, mitigating front-running and other latency arbitrage games.

While powerful, ACE (or ASS) introduces its own trade-offs, primarily around composability and trust. A centralized sequencer reintroduces a single point of trust, a challenge that solutions like Jito's decentralized TEE-based BAM are explicitly designed to solve. As this infrastructure continues to mature and amid the further development of shared sequencing networks like Espresso, ACE is poised to become the standard for on-chain trading, finally delivering on the promise of truly fair and efficient decentralized markets.

3. Challenges & Future Directions

As the many projects we’ve covered above attest to, the CLOB landscape has come a long way since the early EtherDelta and BitShares days. The space has innovated quickly in the span of a few years to deliver CLOB DEXs that offer high throughput, low latency, and extensive suites of features that make them increasingly competitive with CEXs. This improvement is increasingly reflected in rising trading volumes and usage, which are quickly gaining on CEXs. 

And yet, several challenges remain that the CLOB DEX space will need to navigate as it makes its way towards broader mainstream adoption. These include:

Privacy

An oft-cited feature of blockchains is their transparency. Most blockchains fully expose transaction data for all nodes and observers to see. This transparency undergirds verifiability for most blockchains, as they rely on re-execution of transactions by all nodes to verify that all state updates have been performed correctly.

While blockchain transparency has often been hailed as a virtue that enables verifiability and auditability, it’s also in many ways a significant drawback. Specifically in the context of CLOB trading, transparency means trader positions and actions are fully public. This can create several problems for traders. By exposing all of their trading activity, traders that have developed profitable strategies risk having those strategies copied by others, accelerating alpha decay. Public positions also reveal where traders have placed stop orders, so transparency facilitates ‘stop hunting’ whereby other traders may seek to push market prices in the proximity of large stop orders in order to trigger them and benefit from the liquidity or market movements these stops create. Similarly, CLOB exchanges running on transparent infrastructure may also expose account margin data and liquidation prices. These liquidation prices can similarly be hunted to trigger profitable price movements, so traders on transparent exchanges may face higher risk of liquidation on low margin than they would on a private exchange.

Given these issues, most traders, and particularly institutional traders, prefer stronger privacy guarantees than those offered in fully transparent exchanges. There are some arguments for why transparency can actually be a good thing for CLOB DEX trading, for example by allowing market makers to discriminate between toxic and non-toxic flow. On balance, however, privacy is likely to be considered a feature rather than a bug for traders.

Most CLOB DEXs today are transparent, and therefore suffer from the issues above. The majority of high-performance blockchains today achieve verifiability through re-execution, which requires their data to be transparent for all nodes to process. Even CLOB DEXs operating on rollups are for the most part transparent, since they have to post all of their data to L1 in order to inherit the latter’s full security guarantees.

Practical blockchain privacy for complex applications like CLOBs is still a work in progress. TEE solutions are performant today, but introduce additional trust assumptions. Cryptographic solutions like client-side ZK-proofs with private state, Fully Homomorphic Encryption, or Secure Multi-Party Computation are still nascent and cannot yet support the levels of performance needed. While fully fledged solutions develop, projects may need to implement hybrid measures to guarantee some level of privacy. For more on the privacy aspects, also check out our article here and for a deep dive on programmable privacy in general, check here.

Tradeoff between centralization & decentralization

Since the very early EtherDelta days, CLOB DEXs have explored hybrid models using centralized and decentralized components in a quest to achieve the right balance between trustlessness and performance. Finding that balance remains a key consideration for CLOB DEXs today, and different projects are exploring different points of the centralization to decentralization spectrum.

While full decentralization provides the strongest censorship and security guarantees, the practical reality is highly decentralized blockchains like Bitcoin and Ethereum cannot support performance CLOB DEXs fully onchain due to limitations in throughput and latency. Projects have thus inevitably had to take the more nuanced path of understanding where decentralization is needed, versus where it isn’t fully required. For instance, users may be ok with trading off full censorship resistance guarantees in execution in exchange for higher performance, but they may be unwilling to accept any added risks to fund safety than what they get in a fully decentralized ledger.

Hyperliquid and Lighter provide interesting case studies for how different projects are approaching this question. Hyperliquid runs its own L1 with around 24 active validators currently. While this is more centralized and doesn’t offer as strong censorship resistance and verifiability guarantees as, say, Ethereum, users can still be more confident in the correct execution of the exchange’s rules given the participation of multiple different entities with a stake and interest in the system functioning correctly. In exchange for accepting more centralization, users gain access to a still-decentralized platform that approaches the CEX trading experience. Lighter takes a different approach. It uses a (currently) centralized sequencer, but through the use of zk proofs it provides guarantees to users regarding the integrity of the DEX’s matching engine and the safety of user funds. The team is also working on an escape hatch system. Once this is in place, users will be able to force transactions and exit through the L1 if needed, thus inheriting Ethereum-level safety for their funds. Thus, while they won’t have censorship resistance at Lighter’s native speed, they’ll ultimately benefit from Ethereum’s censorship resistance and security.

Finding the right balance between centralization and decentralization will be key for CLOB DEX’s going forward, as it’ll be crucial for winning user trust. Where CLOB DEX’s choose to locate themselves in the spectrum will also determine how regulators view them. After all, if they can’t enforce trust through code and cryptography, legal systems may justifiably have to play a role.

MEV

MEV has forever vexed the DEX space and continues to be an unsolved problem today. While many CLOB DEXs today suffer from fewer MEV problems than their AMM counterparts on Ethereum or Solana, too often it is simply because a centralized sequencer or set of validators is trusted not to exploit their privilege in determining transaction ordering. While reputation can be a strong motivator that users may feel ok relying on in the short term, the whole point of crypto was to leverage economic incentives and cryptography to undergird trust. 

MEV is likely to be impossible to fully eliminate, but CLOB projects are taking different steps to mitigate it. Lighter, for instance, enforces provable price-time priority using its custom ZK circuits. They claim this approach reduces MEV potential to “millisecond-level effects”. Other approaches include building multiple concurrent proposer architectures with a fair ordering rule, which Solana is exploring. There are also non-deterministic approaches like social or shared-security protocol slashing. DYDX for instance passed a governance proposal to implement a mechanism whereby validators can be slashed through a governance vote if they engage in MEV activity. One could imagine similar mechanisms also being implemented through shared security layers like Eigenlayer or Symbiotic.

Ultimately, solving MEV at the sequencer layer may simply move MEV-style activity to the networking and transaction transmission layer. In TradFi, latency races on CLOB exchanges account for a substantial fraction of overall trading activity. Such behavior arises from unavoidable properties of CLOB market structure. Frequent batch auctions have long been proposed as a potential solution, but they have not had much uptake in traditional finance. Projects like Ambient Finance are experimenting with Dual Flow Batch Auctions as their execution mechanism, so it will be interesting to watch how these perform once implemented.

Risk Management & Insurance

This report is coming out shortly after October 10, 2025, when crypto markets experienced the most extreme liquidation event in perpetual futures markets to date, with around $19b in total liquidations. CLOB perp DEXs were the subject of scrutiny in the aftermath of the event given the large quantity of public liquidations that happened on them, and the fact that many traders ended up having their positions forcibly closed by DEX Auto-Deleveraging (ADL), a mechanism perps exchanges use as a last resort measure to maintain exchange solvency in the event of extreme market volatility and trader bankruptcy. 

While these mechanisms are disclosed, exchanges could potentially implement further protections to mitigate the impact of events like October 10’s crash. Potential solutions may include dedicated insurance funds that serve as a backstop liquidator for positions that liquidity vaults can’t take, or circuit breakers that switch the exchange from continuous matching to an auction mechanism when prices deviate past specific thresholds and books thin out. These mechanisms introduce their own problems and may be difficult to integrate into permissionless DeFi, but the benefits in the form of better trader protection could be a differentiator.

Conclusion

Onchain or fully verifiable CLOBs are no longer an emerging trend, they are ushering in a new paradigm. The significant market share recently captured by CLOB exchanges, now commanding over $633 billion in monthly volume, marks a permanent and fundamental shift in DeFi's market structure. As this report has detailed, this ascent was not driven by a change in market demand, but by a revolution in underlying infrastructure that has finally obliterated the performance gap that once necessitated the architectural compromise of the AMM. This is the single most significant maturation of decentralized financial markets to date.

Our analysis has shown this infrastructure revolution is now playing out as an arms race between two distinct and competing philosophies. The modular paradigm, championed by rollup frameworks like the Sovereign SDK and the Starknet Stack, enables a Cambrian explosion of specialization, allowing teams to rapidly assemble high-performance L2 appchains from pre-built infra components. This path, however, is countered by the monolithic renaissance, where next-generation L1s like Sei, Monad, chains leveraging the SVM (Solana and Fogo) or MoveVM (Aptos and Sui), as well as universally programmable real-time L2s (like MegaETH or Rise), argue that true CEX-level performance and seamless atomic composability can only be achieved through the tight, vertical integration of the entire stack or at least a unified execution layer. The market is now the live proving ground for these two theses, with both paths yielding technologically sophisticated venues that are converging on a new standard of onchain excellence.

With the foundational challenges of throughput and latency solved, the competitive battleground has irrevocably moved up the stack. The next generation of leading CLOBs will not be defined by raw transactions per second, but by their ability to engineer fairer, more capital-efficient, and more resilient trading environments. One key frontier of innovation in this context is Application-Controlled Execution (ACE), where control over market microstructure allows protocols to mitigate MEV, fundamentally de-risk market making, and build provably fair systems from first principles.

However, the path forward is not without its trials. The challenges of institutional-grade privacy, the pragmatic trade-offs between centralization and decentralization, and the need for more sophisticated risk management are no longer theoretical concerns. The severe liquidation event of October 10, 2025, was a live fire drill for the entire onchain ecosystem. It serves as a stark reminder that as onchain markets grow in scale and complexity, so too do the systemic risks. The protocols that successfully address these challenges, offering verifiable privacy without compromising performance and building robust safety modules that protect users during extreme volatility, will establish a strong competitive moat.

Ultimately, the era of debating the viability of onchain CLOBs is unequivocally over. The technology is production-ready, and its performance is converging with, and in key aspects like transparency and self-custody, surpassing that of centralized incumbents. For builders and institutional participants alike, the question has evolved from if professional-grade trading can exist onchain to which architectural models and platforms will define the future. The foundational layers have been laid. The capital is watching. The race to build the defining financial markets of the next decade has truly begun.

——————————————————————————————————————————————————

The content provided in this article is for educational and informational purposes only and should not be construed as financial, investment, or trading advice. Digital assets are highly volatile and involve substantial risk. Past performance is not indicative of future results. Always conduct your own research and consult with qualified financial advisors before making any investment decisions. A1 Research is not responsible for any losses incurred based on the information provided in this article. This campaign contains sponsored content. A1 Research and its affiliates may hold positions in the projects and protocols mentioned in this article.

GSR Disclosures

This material is provided by GSR (the “Firm”) solely for informational purposes. It is not intended to be advice or a recommendation to buy, sell or hold any investment mentioned. Investors should form their own views in relation to any proposed investment.It is intended only for sophisticated, institutional investors and does not constitute an offer or commitment, a solicitation of an offer or commitment, or any advice or recommendation, to enter into or conclude any transaction (whether on the terms shown or otherwise), or to provide investment services in any state or country where such an offer or solicitation or provision would be illegal. The Firm is not and does not act as an advisor or fiduciary in providing this material.This material is not an independent research report, and has not been prepared in accordance with any legal requirements by any regulator (including the FCA, FINRA or CFTC) designed to promote the independence of investment research. This material is not independent of the Firm’s proprietary interests, which may conflict with the interests of any counterparty of the Firm. The Firm may trade investments discussed in this material for its own account, may trade contrary to the views expressed in this material, and may have positions in other related instruments. The Firm is not subject to any prohibition on dealing ahead of the dissemination of this material.Information contained herein is based on sources considered to be reliable, but is not guaranteed to be accurate or complete. Any opinions or estimates expressed herein reflect a judgment made by the author(s) as of the date of publication, and are subject to change without notice. The Firm does not plan to update this information.Trading and investing in digital assets involves significant risks including price volatility and illiquidity and may not be suitable for all investors. The Firm is not liable whatsoever for any direct or consequential loss arising from the use of this material.Copyright of this material belongs to GSR. Neither this material nor any copy thereof may be taken, reproduced or redistributed, directly or indirectly, without prior written permission of GSR.Please see here for additional Regulatory Legal Notices relevant to US, UK and Singapore.