What is Invisibook
Introduction
invisibook是一个去中心化隐私订单薄L2 appchain，其使用proof of buying共识协议并建立在CKB L1上，通过 MPC + zk 的方式实现 链上撮合、链下结算、链上验证。 在invisibook中， 交易标的和报价是公开的，但是在链上的订单数量是密文形式的，大众以及对手盘只可以进行交易，却无法探知对方的持仓数量（即便是使用AI和量化交易算法也无法探知） 以此来保护交易者的隐私 防止被价格冲击、反向布局、内幕交易以及各类MEV蚕食掉大额利润。
Flow
-
用户在invisibook链上持有一定数额的加密货币，并且以密文形式记录
-
用户提交密文订单到链上，并提供zk proof：
-
只加密订单的数量（数量是一个 commitment），报价是明文的
-
zk proof证明自己有足够的 余额 和 手续费 发起该笔订单
-
-
链上根据订单报价按照如下标准进行撮合：
-
区块高度作为时间排序依据，优先在区块号低的订单里面进行价格匹配
-
若同在一个区块且报价相同，则根据 gas-fee 对订单进行由高到低撮合
-
根据 限价单↔限价单 与 市价单↔定价单 之间的报价单价匹配
-
-
撮合成功之后，链上对这些订单进行锁定，并且让交易双方对该撮合结果进行签名。不许被撤回，只能等待结算。
-
用户端查看链上撮合结果并在链下与匹配订单的用户用MPC进行点对点结算，并生成zk proof，
MPC结算方式如下：
-
以恶意安全模型的MPC进行链下点对点交易，交易过程中双方无法知道对方的具体数据
-
提供zk证明：订单数量的commitment的明文数据 = MPC计算的输入值
zk证明以下几点：
-
买方入账 / 卖方出账 金额 = 订单结算金额
-
订单剩余数量 = 旧订单数量 - 结算订单数量
-
-
将zk proof上传到链上进行验证，验证通过则修改对应的订单和余额状态（都是密文形式）
更多技术细节参考： Invisibook, 隐私去中心化订单薄 | Invisibook
GitHub Org: https://github.com/invisibook-lab
Blog: https://invisibook-lab.github.io/
Why Invisibook
传统交易所的局限性
传统中心化交易所（如股票交易所或加密货币平台）依赖公开订单薄（Order Book）机制，所有买卖订单的细节，包括价格、数量和方向，都对市场参与者可见。这种透明度本意是为了促进公平竞争和价格发现，但实际上却成为攻击者和操纵者的温床，导致真实交易者蒙受巨大损失。
首先，大单交易往往遭受价格冲击（Price Impact）。当机构投资者提交一个大规模买入或卖出订单时，订单薄的公开性会立即引发市场反应。例如，一个大额买入订单会推动价格上涨，导致后续执行价格高于预期，从而增加交易成本。反之，大额卖出则可能引发恐慌性抛售，压低价格。研究显示，在高流动性市场中，即使是中等规模的订单，也可能导致0.5%至2%的价格偏差，这对资金量庞大的机构而言，意味着数百万美元的损失。
其次，订单透明性容易引发反向布局。高频交易者（HFT）或内部人士可以通过监控订单薄，提前介入交易。例如，当一个大单出现时，攻击者可以抢先买入并在价格上涨后卖出，攫取利润。还有类似于“老鼠仓”（Front-Running by Insiders），即交易员利用未公开信息为自己谋利。在加密货币市场，这种问题尤为突出，因为区块链的公开性放大了订单薄的可见度，导致真实交易者经常被“围猎”。
此外，订单数量的透明还便于攻击者“做局”。操纵者可以通过虚假订单（Spoofing）制造假象，诱导市场走向特定方向。例如，提交大量虚假卖单以压低价格，然后在低位买入真实资产。监管机构如美国证券交易委员会（SEC）多次报告此类事件，但由于订单薄的公开性，这种攻击难以根除。总体而言，这些局限性导致真实交易者丢失大量利润，市场效率低下，并加剧了不平等——小投资者难以与机构抗衡。
现有去中心化订单薄的弊病
- 审查风险
绝大多数订单薄又是链下撮合，这给了MEV和其他审查方式极大的空间和便利。并且因为订单信息比传统交易所更加的完全公开透明，这便给了很多做市商和攻击者 反向布局和开老鼠仓等 机会。
- 假隐私
很多号称隐私去中心化订单薄的项目，都不是真隐私，他们都是一些信任假设的存在的，典型的如中心化撮合器 以及 TEE，要么需要信任英特尔硬件，或者必须信任项目方的中心化服务器不作恶、不宕机。 而Invisibook是用纯密码学的方式解决，没有任何信任假设。
Why us
我们基本都是 曾经是头部 L2 zkrollup 团队scroll的 zk engineer、 blockchain infra engineer， 还有 cryptography PHD，对密码学和公链方面的研究和开发都具备十足的经验， invisibook的重难点就是隐私与公链两个方面，与我们的经验和技术栈十分契合。
团队成员：
XinRan Chen
github: https://github.com/Lawliet-Chan
-
EIP-8099 作者
-
PSE zkevm-circuits 贡献者
-
前Scroll区块链工程师
-
前Reddio技术负责人
Steven Gu
github：https://github.com/silathdiir
-
PSE zkevm-circuits 的核心贡献者之一
-
前scroll zk工程师
-
前 Brevis zk工程师
Tianyi Liu
-
UIUC PhD (2026 秋季毕业)
-
Ceno 的作者 (https://github.com/scroll-tech/ceno)
-
ZK 研究员
-
google scholar https://scholar.google.com/citations?user=UcADtHwAAAAJ (Tianyi’s participation will be limited to high-level advisory input and will be subject to applicable immigration and work authorization requirements.)
Harold
github: https://github.com/HaroldGin931
-
zk 开发者
-
前Huawei工程师
-
前Plancker贡献者
Why Nervos
invisibook所用的L2共识协议为 proof of buying，其必须在有编程能力的 POW公链上实现（在POS公链的L2使用 proof of buying会威胁到 POS母链的共识安全，L2项目方会变成POS L1的攻击者，但是在POW上不存在这个问题），并且由于L2的出块间隔 天然比L1短，所以闪电网络技术 fiber 便是这个场景下必备的手段。
同时， proof of Buying可以帮助CKB增加价值捕获途径， invisibook L2如果稳步进入上升期，将会在经济模型层面同步托举CKB的价格，反则也不会对CKB产生负面影响。
proof of buying细节： Proof of Buying，一种专为Layer1设计的Layer2共识
Why now
- AI的兴起：随着LLM的兴起，传统的量化交易的算法将面临更快更精准的被破解，在交易所中的大额交易订单将无所遁形。暗池的规则又不明确，审查风险极大。
- web3的衰败：天下苦IXO久矣。由于web3的中心化交易所机构近十年来对行业斩草除根式的收割。导致无数可能产生创新的项目方需不停为了流动性而上贡大交易所，交易所又可以利用自身的交易信息优势不断收割项目方和交易者。使得行业陷入短周期传销游戏的死亡循环，真正有价值的项目被短择的金融游戏掩埋，行业永远无法推陈出新。交易所机制需要迎来改革。
Execute Plan
phase 1： 4个月（从资金发放开始计算）
申请金额 32000 美金 （按发行时 CKB 等值计算）
- 计算方式：开发费用， 4个开发者 x 4个月 x 2000 美金
- 发放方式：希望审批通过之后先发放 20% 作为启动金，随后每个月交付阶段性成果，交付验证完成后发放20%，4个月结束之后发放完毕。
- CKB地址： 审批通过之后公布
第1个月：
- 完成 invisibook L2 链上订单薄功能：撮合、挂单、吃单等（不包含杠杆功能）
- 完成Invisibook 订单薄前端开发
第2个月：
- 完成恶意安全模型下的MPC下客户端之间的订单结算功能
- 完成订单结算正确性的zk定制电路开发
第3个月：
- 完成invisibook L2 的proof of Buying共识协议，挂载在CKB L1上
- 完成矿工参与共识相关的前端开发
第4个月：
- 完成与主流公链 ETH, CKB的跨链转账和资产隐私声明
What is Invisibook
Introduction
Invisibook is a decentralized privacy-preserving order book L2 AppChain built on top of Nervos CKB Layer 1 with Proof of Buying consensus. It achieves on-chain matching, off-chain settlement, and on-chain verification through a combination of MPC (Multi-Party Computation) and ZK (Zero-Knowledge Proofs).
In Invisibook, the trading pair and price quotes are fully public, but order quantities on-chain are stored in encrypted (ciphertext) form. The public and counterparties can only execute trades — they cannot discover the actual position sizes of others (even advanced AI models or quantitative trading algorithms cannot infer them). This design protects traders’ privacy and prevents large orders from suffering price impact, front-running, insider trading, and various forms of MEV that erode substantial profits.
Flow
-
Users hold a certain amount of cryptocurrency on the Invisibook chain, recorded in encrypted (ciphertext) form.
-
Users submit encrypted orders to the chain along with a ZK proof:
- Only the order quantity is encrypted (as a commitment); the price is in plaintext.
- The ZK proof demonstrates that the user has sufficient balance and gas fees to place the order.
-
On-chain matching is performed based on the quoted prices using the following rules:
- Block height serves as the time priority — orders in lower block numbers are matched first.
- If orders are in the same block and have the same price, they are prioritized from highest to lowest gas fee.
- Matching occurs between limit ↔ limit orders and market ↔ limit orders based on quoted prices.
-
Once matching succeeds, the involved orders are locked on-chain. Both parties must sign the match result. Locked orders cannot be canceled and must wait for settlement.
-
The client views the on-chain match result, then performs peer-to-peer off-chain settlement with the matched counterparty using MPC, and generates a ZK proof.
MPC settlement process:- Uses a malicious-secure MPC protocol for off-chain P2P trading — neither party learns the other’s exact data during computation.
- Produces a ZK proof showing: the plaintext value of the order quantity commitment = the input value used in the MPC computation.
The ZK proof verifies: - Buyer received / Seller sent amount = settled order amount
- Remaining order quantity = original order quantity − settled quantity
-
The ZK proof is uploaded to the chain for verification. Upon successful verification, the corresponding order and balance states are updated (both remain in encrypted form).
More technical details:
Invisibook – Privacy-Preserving Decentralized Order Book | Invisibook
GitHub Org: invisibook-lab · GitHub
Blog: https://invisibook-lab.github.io/
Why Invisibook
Limitations of Traditional Exchanges
Traditional centralized exchanges (stock exchanges or crypto platforms) rely on a fully transparent order book where every bid/ask detail — price, quantity, and side — is visible to all participants. While this transparency is intended to foster fair competition and price discovery, it has become a breeding ground for attackers and manipulators, causing significant losses to genuine traders.
- Price Impact: When institutional investors place large buy or sell orders, the public visibility immediately triggers market reactions. A large buy order drives prices up, resulting in worse average execution prices; a large sell can trigger panic selling and depress prices. Studies show that even medium-sized orders in high-liquidity markets can cause 0.5%–2% price deviation — translating to millions of dollars in hidden costs for large funds.
- Front-running / Reverse Positioning: High-frequency traders (HFT) or insiders monitor the order book and jump ahead. For example, they buy before a large buy order hits, then sell at a higher price. In crypto, blockchain transparency amplifies this problem, turning traders into easy prey.
- Spoofing / Order Book Manipulation: Manipulators place large fake orders to create false impressions, luring the market in one direction before executing real trades at favorable levels. Regulators like the U.S. SEC have repeatedly documented such behavior, yet the open nature of order books makes it nearly impossible to eliminate.
Overall, these issues cause genuine traders to lose massive profits, reduce market efficiency, and deepen inequality — retail participants stand little chance against sophisticated players.
Problems with Existing Decentralized Order Books
-
Censorship & MEV Risk
Most decentralized order books still rely on off-chain matching engines, creating huge opportunities for MEV extraction and censorship. At the same time, order information is often even more fully transparent than in centralized exchanges, giving market makers and attackers ample room for front-running and insider-style exploitation. -
Fake Privacy
Many projects that claim to offer “privacy-preserving decentralized order books” do not provide real privacy. They depend on trust assumptions — centralized matchers, TEEs (Trusted Execution Environments), etc. — requiring users to trust Intel hardware or the project team’s servers not to misbehave or go offline. Invisibook solves this purely with cryptography, with zero trust assumptions.
Why Us
Our core team consists of former zk engineers and blockchain infrastructure engineers from Scroll (a leading zkRollup L2), together with cryptography PhDs. We have deep experience in both cryptography and public blockchain development. The core challenges of Invisibook — strong privacy + public chain integration — align perfectly with our expertise and technical stack.
Team:
XinRan Chen
github: https://github.com/Lawliet-Chan
-
The author of EIP-8099
-
The contributor of PSE zkevm-circuits
-
ex Scroll blockchain 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
-
UIUC PhD (expected to graduate in 2026 fall)
-
the author of Ceno theory (https://github.com/scroll-tech/ceno)
-
ZK Researcher
-
google scholar https://scholar.google.com/citations?user=UcADtHwAAAAJ (Tianyi’s participation will be limited to high-level advisory input and will be subject to applicable immigration and work authorization requirements.)
Harold
github: https://github.com/HaroldGin931
-
zk engineer
-
ex Huawei engineer
-
ex Plancker contributor
Why Nervos (CKB)
Invisibook uses a Proof of Buying consensus protocol for its L2. This mechanism requires a programmable Proof-of-Work (PoW) base layer (using Proof of Buying on a PoS L2 would threaten the security of the PoS L1 consensus; the L2 could become an attacker against its own base layer — this risk does not exist on PoW). Additionally, because L2 block times are naturally shorter than L1, lightning-network-style techniques (such as Nervos Fiber) are essential in this architecture.
Moreover, Proof of Buying creates a new value-capture pathway for CKB. If Invisibook L2 grows steadily, it will economically support and lift CKB’s price in a synchronized way. If it underperforms, it will not negatively impact CKB.
(Details: Proof of Buying — A Layer-2 Consensus Mechanism Designed Specifically for Layer-1 Chains)
Why Now
-
Rise of AI: With the explosion of large language models (LLMs), traditional quantitative trading strategies will be cracked faster and more accurately than ever. Large orders on public exchanges will have nowhere to hide. Meanwhile, dark pool rules remain opaque and carry extremely high censorship risk.
-
Web3 Stagnation: The ecosystem has suffered for too long under centralized exchanges (CEXs). Over the past decade, CEXs have systematically harvested the industry through liquidity monopolies and information advantages. Promising innovative projects are forced to pay tribute to large exchanges for liquidity, while exchanges exploit their data edge to continuously extract value from both projects and traders. This has trapped the industry in short-cycle Ponzi-like death spirals. Truly valuable projects are buried under short-term financial games, and genuine innovation is stifled. The exchange mechanism urgently needs fundamental reform.
Execution Plan
Phase 1: 4 months (calculated from the date funds are disbursed)
Requested amount: USD 32,000 (equivalent value in CKB at the time of disbursement)
- Calculation: Development cost = 4 developers × 4 months × USD 2,000/month
- Disbursement schedule: Upon approval, 20% released as initial funding. Thereafter, 20% released each month after verifiable milestone delivery. Full amount disbursed after 4 months.
- CKB address: Announced after approval
Month 1
- Complete core on-chain order book functionality on Invisibook L2: matching, placing orders, taking orders (leverage features excluded at this stage)
- Complete Invisibook order book frontend development
Month 2
- Implement order settlement functionality between clients under malicious-secure MPC
- Develop custom ZK circuits to prove correctness of order settlement
Month 3
- Implement Proof of Buying consensus protocol for Invisibook L2 and integrate it with CKB L1
- Develop frontend components related to miner participation in consensus
Month 4
- Complete cross-chain transfer functionality and privacy declaration for assets with major public chains (ETH, CKB)