L2 privacy decentralized order book based on CKB L1

English CKB Development & Technical Discussion
1

Introduction: Why a Decentralized Privacy Order Book Is Needed

Order book trading is the most mature and scalable form of trading in modern financial systems, serving as the core mechanism for price discovery and liquidity formation. However, in a digitized, on-chain, and high-frequency environment, order books expose a long-ignored structural contradiction: trading systems cannot simultaneously achieve censorship resistance, privacy protection, and verifiable execution.

Decentralized Order Books: Censorship-Resistant and Verifiable, but Lacking Privacy

Decentralized trading systems eliminate reliance on centralized intermediaries by deploying order submission, sequencing, and matching rules on public protocols, giving them inherent censorship resistance. As long as users can interact with the network, their orders cannot be arbitrarily rejected, frozen, or selectively delayed by any single entity.

More importantly, on-chain trading is not only censorship-resistant but also verifiable. Matching rules, execution order, and settlement outcomes are public to all participants, allowing anyone to independently verify post-trade whether execution followed the established rules. This verifiability is unattainable in traditional exchanges and represents one of the core institutional advantages of decentralized trading.

However, virtually all existing decentralized order books achieve this at the cost of fully transparent order data. Order prices, quantities, and timestamps are broadcast in real time to all observers, turning trading behavior into a continuously parsable and exploitable signal source. This transparency is not neutral—it triggers a series of systemic risks at the market microstructure level.

Systemic Risks Caused by Transparent Order Books

In a fully transparent order book, order quantities directly reveal a trader’s capital scale, execution urgency, and remaining trading intent. This structurally disadvantages genuine trading demand and induces the following typical behaviors:

  • Preemptive Amplification of Price Impact
    Once the market identifies potential large or persistent orders, liquidity providers adjust quote structures in advance—raising ask prices or lowering bid prices—to front-run the expected impact. As a result, slippage is amplified before execution even occurs, forcing genuine traders to bear systematically higher execution costs.

  • Toxic Order Hunting and Adverse Selection
    Participants with information advantages can detect passive or informationally disadvantaged order flow through changes in order book depth and treat it as “toxic flow.” By front-running, taking opposite positions, or short-term hedging, they transfer risk to genuine demand-side participants while structurally capturing the profits. This behavior is rational in transparent environments and erodes long-term willingness to provide genuine liquidity.

  • Liquidity Withdrawal and Depth Failure
    Once trading intent is identified, other liquidity can collectively withdraw in extremely short timeframes, causing apparent depth to fail at critical moments. Liquidity that appears abundant in calm market conditions evaporates rapidly when real execution demand emerges, creating endogenous instability.

These risks are further amplified in on-chain environments. Global permissionless real-time observability, block ordering rights, and MEV mechanisms make such behaviors not only feasible but also institutionalizable and automatable. Without privacy protection, decentralization can paradoxically become even more disadvantageous to genuine traders than traditional centralized exchanges.

Centralized Privacy Trading: Privacy Built on Trust and Censorship

Centralized exchanges provide partial privacy protection through internal matching and private execution, but this privacy is asymmetric and revocable. Orders remain fully transparent to the exchange itself, its infrastructure operators, and potential partners.

This means:

  • The exchange constitutes a natural censorship point, capable of freezing, rejecting, or selectively serving users;
  • Privacy trading relies on trust in a single entity and cannot be independently verified externally;
  • Privacy is not a protocol-guaranteed right, but a privilege granted by the platform.

Under this structure, traders must compromise between execution safety and institutional trustworthiness.

Drawbacks of Existing Decentralized Order Books

  1. Censorship Risk
    The vast majority of order books still rely on off-chain matching, which creates enormous space and convenience for MEV and other forms of censorship. Moreover, because order information is far more completely public and transparent than in traditional exchanges, it gives many market makers and attackers opportunities for reverse positioning, front-running, or “rat trading.”

  2. Fake Privacy
    Many projects claiming to offer privacy decentralized order books do not provide true privacy. They rely on trust assumptions—typical examples include centralized matchmakers or TEEs—which require trusting Intel hardware or the project team’s centralized servers not to misbehave or go offline. In contrast, Invisibook solves this purely through cryptography, with no trust assumptions.

Decentralized Privacy Order Book: Resolving the Structural Contradiction

This project is proposed precisely to address the long-standing structural contradiction outlined above. We believe a truly sound trading system must simultaneously satisfy:

  • Decentralized execution to eliminate censorship points;
  • Native privacy protection to prevent systemic exploitation of trading intent;
  • Verifiable matching and settlement rules to ensure market fairness.

A decentralized privacy order book is not a mere incremental improvement on existing trading models—it is a fundamental institutional rebalancing of transparency, privacy, and verifiability. Its goal is not to hide the market itself, but to prevent transparency from being weaponized against genuine traders.

invisibook — Privacy Decentralized Order Book

Overall Flow

  1. Users hold a certain amount of cryptocurrency on this chain, recorded in ciphertext form.

  2. Users submit ciphertext orders on-chain and provide ZK proofs:

    • Only the order quantity is encrypted (as a commitment); the price is plaintext.
    • The ZK proof demonstrates sufficient balance and fees to place the order.

  3. On-chain matching occurs based on order prices according to the following rules:

    • Block height serves as the time-sorting basis; price matching prioritizes orders from lower block numbers.
    • For orders in the same block with identical prices, matching prioritizes from highest to lowest gas fee.
    • Matching follows limit ↔ limit and market ↔ limit price rules.

  4. Upon successful matching, the orders are locked on-chain, and both parties sign the matching result. Orders cannot be canceled and must await settlement.

  5. Users view the on-chain matching result, then perform peer-to-peer off-chain settlement with the matched counterparty using MPC, generating a ZK proof.
    MPC settlement works as follows:

    • Uses maliciously secure MPC for off-chain P2P trading, where neither party learns the other’s specific data during the process.
    • Provides ZK proof that: the plaintext of the order quantity commitment equals the input value computed by MPC.
      The ZK proof demonstrates:
    • Buyer receipt / seller debit amount = settlement amount of the order.
    • Remaining order quantity = old order quantity − settled quantity.

  6. Upload the ZK proof to the chain for verification. Upon passing, update the corresponding order and balance states (both in ciphertext form).

Anti-MEV Protocol
When limit orders are uploaded on-chain, prices are plaintext, creating MEV attack risks. To resist censorship, we adopt the MEVless protocol from EIP-8099 (see: EIPs/EIPS/eip-8099.md at master · ethereum/EIPs · GitHub ).

Consensus Protocol: Proof of Buying
The system runs as a Layer 2 AppChain on CKB, so its consensus builds on CKB’s security:

  1. Admission consensus: Any CKB holder can participate in mining.

  2. Block production consensus: Miners pay a certain amount of CKB via the CKB Lightning Network to a designated address, then locally compute a random value using VDF and publish it. Each node computes VDF_output × CKB_payment_amount, and the highest value wins block production rights. VDF input is the previous block’s blockHash.

  3. Finality consensus: Among all forks, select the chain with the highest cumulative (VDF_output × CKB_payment_amount) sum as the main chain.

  4. Exit consensus: Simply stop paying or stop VDF computation to exit.

For details, see: Proof of Buying, a Layer 2 consensus designed specifically for Layer 1 — #25 by Lawliet_Chan ( Proof of Buying，一种专为Layer1设计的Layer2共识 ).

Team members:
XinRan Chen

github: https://github.com/Lawliet-Chan

  • The author of EIP-8099

  • The contributor of PSE zkevm-circuits

  • ex Scroll core engineer

  • ex Reddio Tech leader

Steven Gu

github：https://github.com/silathdiir

  • core contributor of PSE zkevm-circuits

  • ex Scroll zk engineer

  • ex Brevis zk engineer

Tianyi Liu

Harold

github: https://github.com/HaroldGin931

  • zk engineer

  • ex Huawei engineer

  • ex Plancker contributor

GitHub Org: invisibook-lab · GitHub
Blog: https://invisibook-lab.github.io/

8 Likes