zkCEX: Eliminating On-chain and Off-chain Liquidity Isolation with ZK Trust Engine

Background Issue – Liquidity Isolation Between On-chain and Off-chain

In this article, ZEROBASE will reveal a critical structural problem in the Web3 ecosystem – liquidity isolation, particularly the liquidity segmentation between on-chain and off-chain. Here, "on-chain" primarily refers to Layer 2 networks (such as Starknet, Arbitrum, zkSync) and their ecological projects, rather than well-known, liquid infrastructure like public blockchains. "Off-chain" refers to centralized exchanges (CEX) such as Binance, Gate.io, Coinbase, etc. We will explore the issue of liquidity isolation in depth from the following two dimensions:

1. Limited Coverage of On-chain Token Types

The limited coverage of on-chain token types means that the variety of tokens available on a specific chain is relatively scarce, failing to meet users' broad demands for asset diversification.

For example, the number of token types on Starknet is far fewer than that on the off-chain centralized exchange Coinbase. As shown in the charts:

• Figure 1 – Token Types on the Starknet Network: Starknet currently supports only 15 tokens, including its native token STRK, mainstream assets like ETH and USDC.

• Figure 2 – Token Types on the Coinbase Exchange: Coinbase supports 18,169 tokens, covering a wide range of mainstream coins, long-tail assets, and more.

Figure 1 – Data Source: Dune

Figure 2 – Data Source: coinbase

This difference in liquidity breadth makes it difficult for users on Starknet to find certain emerging tokens or long-tail assets, while CEXs like Coinbase can offer a richer selection of assets.

2. Liquidity Distribution Inequality

Liquidity distribution inequality refers to the significant disparity in liquidity allocation of the same asset across different chains, protocols, or exchanges. For example, certain assets may exhibit high liquidity on specific chains or exchanges, while having extremely low or even zero liquidity on others.

Taking the STRK token as an example, its distribution across different DeFi protocols (DEX, lending, liquid staking, etc.) and CEXs is highly uneven. As shown in the charts:

• Figure 3 – Circulating Supply of STRK Token: The circulating supply of STRK is 3.1 billion tokens.

• Figure 4 – Distribution of STRK Token across DeFi Protocols: STRK is distributed across 30 DeFi protocols, predominantly concentrated on the Starknet chain with approximately 259.53 million tokens in liquidity. In other DeFi protocols, STRK’s liquidity is minimal, with only 5 protocols reaching the ten-million or million token liquidity level.

• Figure 5 – Distribution of STRK Token across DEXs and CEXs: Compared to DEXs, STRK’s liquidity is more concentrated in CEXs, particularly on Binance and Bybit. Among 129 DEX and CEX projects, these two CEXs alone account for over 25% of STRK’s circulating supply.

Figure 3 - Data Source：CoinMarketCap

Figure 4 – Data Source：DeFiLlama

Figure 5 – Data Source：CoinGecko

In scenarios where liquidity distribution is uneven, some tokens exhibit insufficient liquidity depth on L2, leading to significant price fluctuations in large transactions on the chain and increasing transaction uncertainty. Additionally, due to the limited market absorption capacity, large buy or sell orders are difficult to execute quickly. These issues not only amplify traders' position risks but also weaken market price stability and predictability, thereby reducing overall trading efficiency.

zkCEX – The Liquidity Bridge Between On-chain and Off-chain

To effectively address the above liquidity isolation issues, constructing a bridge for liquidity between on-chain and off-chain is particularly critical. This bridge, which we call zkCEX, is designed to channel the massive liquidity of CEXs into L2 networks and their ecological projects.

zkCEX builds this bridge by introducing Order Bot and Zero-Knowledge Proof (ZKP) technology. As a key role connecting on-chain and off-chain liquidity, Order Bot can map users' trading requests on L2 to CEXs, thus meeting their trading needs. Users may wonder: How can we trust Order Bot? Worry not. As a zero-knowledge proof network, ZEROBASE focuses on solving trust issues in Web3 and traditional industries. Through ZK technology, we effectively address the distrust of Order Bot, ensuring the transparency and credibility of its behavior.

What Are the Responsibilities of Order Bot?

Order Bot is an automated trading agent tasked with mapping users' trading requests on L2 to CEXs. It channels CEX liquidity into L2, ensuring that L2 users can enjoy more comprehensive asset support, deeper liquidity, and better trading prices. Specifically, the responsibilities of Order Bot are as follows:

1. Connecting On-chain and Off-chain Liquidity

It maps users' trading intentions on L2 to CEXs and introduces CEX liquidity into the L2 ecosystem, significantly enhancing on-chain liquidity depth and improving users' trading experience.

2. Covering Gas Costs

Users do not need to prepay Gas fees; instead, Order Bot assumes the transaction costs. Users only need to pay a small service fee to enjoy a Gas-free trading experience, greatly enhancing operational convenience.

3. Enabling Intent-Driven Trading

Users only need to place trading orders to express their trading intentions (e.g., "exchange ETH for USDT"). Order Bot will automatically monitor and complete off-chain liquidity integration and asset delivery, finally delivering the target assets seamlessly to users' addresses to achieve an intelligent trading loop from intent to result.

Resolving the Trust Issues of Order Bot with ZK Technology

Despite the significant advantages of Order Bot in enhancing liquidity and user experience, its role as an intermediary introduces trust concerns: Order Bot may tamper with transaction prices or quantities, thereby harming user interests. For example, it might deliberately select suboptimal prices to extract additional profits.

To address these issues, we introduce Zero-Knowledge Proof (ZKP) technology to verify the trading behavior of Order Bot, ensuring its credibility and transparency.

ZKP serves a dual purpose: not only does it verify whether Order Bot executes trades as instructed, but it also proves that the market prices do not deviate from preset thresholds. This prevents Order Bot from choosing inferior prices and safeguards users' trading interests.

How does zkCEX work?

To better introduce the working principle of zkCEX, we have built a liquidity bridge between Starknet and Binance, mapping market order spot trading requests on Starknet to Binance, thereby introducing Binance's liquidity into Starknet. It is assumed that Binance supports the deposit function for all major anchored tokens on Starknet (such as STRK, ETH, USDC, etc.).

Introduction to core components

1. Starknet Biz Contract

Users entrust funds to this contract, which is deployed on the Starknet chain. It is responsible for all core operations of interacting with users, including order placement, asset updates, and withdrawal.

2. Order Bot

It monitors the order function in Starknet Biz Contract, parses users' trading requests, injects the trading funds entrusted by users in Starknet Biz Contract into Binance, seeks the best prices on Binance, and completes transactions.

3. ZEROBASE Prover Network

As ZEROBASE's native zero-knowledge proof generation network, it generates zero-knowledge proofs for the trading behavior of Order Bot on Binance. The network can generate ZK proofs in just hundreds of milliseconds, and ensures decentralized fast consensus through its HUB ring wake-up mechanism, thus supporting large-scale commercial applications.

4. Starknet Verifier Contract

Deployed on the Starknet chain, the contract is responsible for verifying ZK proofs, that is, verifying whether the trading behavior of Order Bot conforms to the order requests of users on Starknet Biz Contract.

Business Process Description

1. Authorization and Order Placement

Users call the approve function in the ERC20 Contract to authorize the Starknet Biz Contract to manage a specified quantity of tokens. This grants the contract permission to transfer the tokens on the user’s behalf.

Users invoke the Starknet Biz Contract with core parameters:

• pair: Trading pair, representing the combination of two assets in a transaction. For example, ETH/USDT indicates that the user is trading between ETH and USDT. (In Binance's order placement API, this parameter is denoted as symbol.)

• side: Indicates the transaction type as either a sell or buy operation, assigned as sell or buy.

• amt: Represents the quantity of tokens the user intends to trade. (In Binance's order placement API, this parameter is referred to as quantity.)

After parameter checking (e.g., verifying that amt is less than or equal to the approved value), and upon successful validation, the Starknet Biz Contract invokes the transferFrom function of the ERC20 Contract to extract amt tokens. At this point, the user completes the preliminary order placement operation in the Starknet Biz Contract.

The Order Bot continuously monitors the Starknet network for transactions where orders are placed from the Starknet Biz Contract. Once an order request is captured, it matches buy and sell demands on the Binance platform while profiting by charging fees.

When mapping the user's order request in the Starknet Biz Contract to Binance for order placement, the Order Bot needs to follow the TRADE interface format of Binance, which requires the Order Bot to perform operations and set parameters not provided by the user: https://developers.binance.com/docs/zh-CN/binance-spot-api-docs/rest-api

2. Trading and ZK Proof Generation

The Order Bot places orders on Binance according to users' order requests and completes them based on Binance's liquidity and buy/sell demands. After the order is executed on Binance, the Order Bot withdraws the traded tokens to the Starknet Biz Contract, though users cannot withdraw them immediately and need to wait for transaction verification to finish.

The Order Bot generates Proof and public witnesses (pubWtns) for its transactions through the ZEROBASE Prover Network. The Prover obtains the order ID from the Order Bot, queries the order execution status from Binance, and completes proof generation, which takes only hundreds of milliseconds and is finished before user settlement, ensuring no impact on the trading experience.

The generated Proof is returned to the Starknet Biz Contract for subsequent verification.

3. Withdrawal and ZK Proof Verification

After the order is executed on Binance, the tokens returned to the user and their associated Proof are stored in the Starknet Biz Contract.

Before withdrawing, users need to conduct ZK verification of the Order Bot's transactions. The Proof is submitted to the Starknet Verifier Contract for validation. A successful verification confirms that the Order Bot's trading behavior is trustworthy.

Thereafter, the Starknet Biz Contract updates the user's asset status, and the user invokes the withdraw function in the Starknet Biz Contract to complete the token transfer operation.

ZK Beyond the Horizon

As a zero-knowledge proof generation network with significant advantages in speed, cost, security, and privacy, ZEROBASE's mission extends far beyond providing basic ZK proof generation services for diverse projects. We have meticulously built a comprehensive ecosystem that includes innovative products such as zkLogin, zkDarkPool, zkVote, zkCEX, zkPVP, as well as decryptable circuits and customized circuit services. Our goal is to create efficient and privacy-preserving solutions for both the Web3 space and traditional industries like cross-border healthcare.

zkCEX represents another innovative solution from us, and based on this, we further propose the following concepts:

By integrating Order Bot with Uniswap V4 Hooks, we can effectively manage liquidity fluctuations and trading slippage.

• Before a transaction, the Hook checks slippage. If it exceeds a set threshold, Order Bot can channel CEX liquidity into the Uniswap liquidity pool to optimize transaction execution. However, since we must verify Order Bot's trading behavior via ZK, this process slightly increases transaction time. Thus, this Hook gives users the choice between low slippage and fast transactions.

• After a transaction, the Hook monitors the token balance in the liquidity pool in real time to determine if the quantity of any token exceeds a preset threshold. Upon detecting an imbalance, the system can promptly trigger an adjustment mechanism through zkCEX to introduce liquidity from the CEX into the Uniswap pool, ensuring the pool's stability and trading efficiency.