Lately, two buzzwords are lighting up Crypto Twitter: CLOB and High-Performance L2s with ZK tech. Because DeFi is in a transition phase   from its experimental  V 1.0  to a serious, institution-ready V 2.0 era via CLOB.

But getting there requires breaking real barriers: achieving 40,000–100,000 TPS and <100ms blocktimes and logical executions ;  without compromising decentralization.

That’s no small ask for a maturing technology. After all, 40% of U.S. retail equity relies on Centralized Order Book (CLOB) models  that suffer from slow T+2 settlement, no real-time ownership transfer, and throughput without true finality.

What if DeFi could bring CLOBs on-chain and fix all those flaws? Wouldn’t that be a financial game-changer, maybe even a “Make Nasdaq Sweat Again” moment.

Through CLOB-specific L2s built on ZK tech, this will change. 

In this blog, we shall explore how these Clob Specific L2s  work and what problems they are going to solve to bring Wall Street performance on-chain and how ZkSync is already winning this race. 

These are not any specific type of a layer 2, in its stead, simple rollup tech but purpose built to cater to the Centralized Order Book Model demand. For that matter, they operate  offchain to perform custom executions not possible with AMM/ DEX now  like matching buyers, sellers, price, volume on a real time basis using  ZK proofs for near instant settlements and executions. In this way, they make way for even CLOB operations or Centralized Order Book Models highly prevalent on traditional exchanges like Binance and Coinbase to be replicated on top of a DEX. How is this achieved if you may ask? Or put simply, 

Through fragmenting every segment as a separate layer  and later on assembling them all together through ZK proof for validation in the following ways to meet the desired outcomes; 

(i) The Execution Layer 

There is a separate execution layer offchain where all the operations are executed. For example, traders are posting their orders with exact prices and the amount they need. 

(ii)The Matching Layer 

There’s a matching layer designated with the task to use the matching engine purpose built to follow a FIFO order. Or the first in first out model. Using this model, the orders are matched and it creates a trade history of the order book. 

(iii) The Data Layer 

The data layer is designated the task to store all the above mentioned data on a separate sector with a self destruct feature to match the speed and efficiency of a traditional clob based model. 

(iv) The Settlement Layer 

Once all these transactions are injected into the system, arranged accordingly,  matched and executed, the offchain engine creates a ZK-Proof of the same and pushes the same which validates:

• Correct Matching 

• Order Book Integrity 

• Balance transitions ( No extra or deprived liquidity)

To put that flow in  nutshell, this is how the Clob specific L2 on Zksync  would work;

• Traders are broadcasting the  orders →

• The orders are getting aggregated off-chain →

• Blobs are created to validate for the execution →

• Off-chain Matching Engine: High performance CLOB matches orders instantly →

• ZK  Proof generation triggered after each batch. This off chain  engine creates a ZK proof confirming correct matches, order book accuracy, and proper balances to be posted on the settlement layer →

• On-chain verification follows: Ethereum checks the proof in one transaction, settles balances without trust, and blobs keep all data open for anyone to verify for a short period until destroyed. 

When this is done, the Clob specific L2s will ensure users are getting; 

• Trades executed at their own preferred prices

• They can access volume 

• Sort orders based on price

• Simplified UX

Clob Specific L2s are needed  because you cannot let a single concept define the future of a sector. For example, at the moment, the DeFi  has been majorly driven by a few use-cases  like swaps, flash loans, arbitrages, lending and  borrowing due to the technological limitations of the general purpose L2s.  But like it was said in the very beginning of this blog that 40% of U.S. wall street is defined by CLOB and almost the global financial market based on Traffic operates on top of the Clob or Central Limit Order Book model where buyers and sellers are submitting limit orders.   For DeFi to dominate or become the next gen financial model, it must be ready to leap  from  DeFi 1.0 → DeFi 2.0 by mirroring the CLOB model onchain. 

But in order to do that, the existing systems must be innovated, engineered, remodelled  to host new use cases extensively in use in TradFi like equity trading, derivatives, ETF arbitrage and more  . Clob Specific L2s  can help do that because they can make room for DeFi for institutional-grade market makers, fully on-Chain spot exchanges CEX-grade UX, derivatives and options markets,  prediction markets & event derivatives protocols to get  hosted  Onchain  by matching the performance of TradFi level CLOB execution but at an onchain level through; 

If DeFi has to introduce ultra scalable use cases like perps, prediction markets , institutional-grade market makers, fully on-Chain spot exchanges CEX-grade UX, it is important to get single slot or block finality which no general purpose L2 can guarantee because they are dependent on the L1s for settlement. But when you are going for a custom based Clob Specific L2s, they can easily match <200 ms blocktime. In addition to this, there’s also deterministic execution to help eliminate front running on these L2s. 

Clob Specific L2s are also provided with an order book infrastructure through an on-chain priority based system. Due to this, it is possible to cancel and post only  orders which are necessary when you are hosting such use-cases which might be demanding a logical flow instead of a regular on chain operations to follow. For example, if a trader wants to cancel an order and subsequently a new order is placed. The L2s should be purpose built to  logically understand the flow and counter actively react. Which means, despite a new order getting placed first, the L2 should be responsive enough to prioritize the cancellation first and then proceed with the orders. 

As it is implied that for meeting super high speed, you will have to proceed with either a centralized or a semi centralized sequencer. A Clob based L2 introduces an escape hatch in the process because if there’s sequencer censorship in action, where a user’s transaction is getting skewed in the form of either completely getting banned, delayed or skipped, the user has an escape hatch window to bypass the same and instantly withdraw funds to prevent any further damage. 

ZkSync is almost abstracting the operations on top of the purpose built or Clob Specific Layer 2s because at present on Nasdaq, the order matching speed latency stands at ~10–40 microseconds (µs). Through the sub second and single slot finality, ZKSync is trying to bring that to ~50–200 microseconds. Due to this, there will be instant matching of the orders due to such low latency levels. 

To host almost $1 T onchain through CLOB, your chains should be purpose built and scalable. To ensure that, ZKsync moves the operations offchain for unlimited throughput because you are not sharing the network with noisy neighbors. But while doing that, you also don’t want to compromise security for the same. For that purpose, Zk proofs will be playing a key role to inherit an ETH equivalence security for all Clob Specific L2s launched on top of ZKsync. 

The operations will be sovereign despite using layer 1 for providing security because the ZK proofs will provide all the updates of the latest happening on alternate layers to scale the ecosystem beyond. 

There has to be privacy in the operations when you are trying to onboard institutions to take the front seat and operate on top of the Clob model. Because , if institutions are coming onchain to overcome their barriers, they cannot compromise on privacy in order to achieve that. 

ZKsync has been front running to help solve key problems to launch a CLOB based interface for different L2s. For example, the Gravity Exchange was not able to quickly match orders, or put an order level control built at protocol levels for high frequency trading. Through ZKsync, Gravity was able to introduce custom based logic for DeFi innovation and even meet faster block time. Like Gravity,  Atomic Cloak wanted privacy preserving swaps to eliminate MEV/ front runs, ZkSync allowed the users to withdraw ETH and other ERC 20 tokens anonymously from the Clob based Layer 2 rollups.  This is just the tip of the iceberg because for building  Clob Specific L2s on Zksync, the stack has helped multiple players from Koi to Project Guardian to others in launching their Clob specific Layer 2s for operations. If you want to build your own Clob specific layer 2, ZKsync could be a smart move ahead and Zeeve can help you. 

Zeeve can help you launch your Clob Specific L2 on ZkSync with a faster and economical approach where you do not have to be burdened down by setting up all the prover and other mechanisms. Zeeve will be there to help you with all of that while you are busy innovating with the product that you want to introduce. With the help of Zeeve, you can expedite the launch, infrastructure management and even third party integration from scratch. So, if you do not want to miss the CLOB based solutions trend and expedite the process to launch your very own Clob Specific L2, set up a call with our experts and let us take things forward