Privacy-Preserving Cross-Chain Order Book Protocol

Technical White Paper — Protocol Flow Details

Version 1.0 | 2026

1 Overview

Invisibook is a privacy-preserving cross-chain order book protocol designed for decentralized trading scenarios. It addresses a series of problems arising from the transparency of trade amounts in current DeFi order book models, including front-running, liquidity manipulation, other MEV attacks, and trading strategy leakage.

The core design philosophy of Invisibook is: prices are public, amounts are private. The on-chain order book exposes only price information for the matching engine to perform pairing, while the specific order amounts are stored on-chain as Poseidon hash commitments (Poseidon is tentatively chosen; other hash functions may be considered later — the key selection criterion is which hash achieves the best combined performance in MPC circuits and ZK proofs). No third party can learn the true size of any order. When two orders are successfully matched, the buyer and seller complete settlement through an off-chain peer-to-peer privacy settlement protocol, during which both parties’ order amounts remain confidential to outsiders at all times.

The protocol’s security is built upon three major cryptographic primitives: the Poseidon hash function for generating efficient arithmetic-friendly commitments, zero-knowledge proofs (ZK Proofs) for verifying various constraints without revealing private information, and malicious-secure secret-sharing MPC (based on SPDZ) for performing secure numerical comparisons between two parties.

The protocol is divided into four phases:

• Phase One: Cross-Chain Deposit — Users deposit assets from external chains (such as Ethereum, Solana, and other L1/L2 networks) via the corresponding cross-chain bridge. On the Invisibook chain, the account balance is recorded in ciphertext form (UTXO format), and a ZK Proof is submitted to prove fund ownership.

• Phase Two: Private Order Submission — Users create orders with prices publicly disclosed in plaintext and amounts hidden via Poseidon commitments, accompanied by a ZK Proof of sufficient balance.

• Phase Three: On-Chain Transparent Matching — The matching engine executes a price-priority matching algorithm based on plaintext prices, pairing buyers and sellers.

• Phase Four: Off-Chain Privacy Settlement — The matched parties compute secret shares of the comparison result via SPDZ malicious-secure secret-sharing MPC. Each party submits their share on-chain, and the on-chain synthesis determines the comparison result. The smaller-order party then sends the plaintext to the larger-order party to complete the difference calculation and state update.

Figure 1: Invisibook Protocol Overall Flow and System Architecture

2 Notation and Basic Definitions

To maintain consistency in subsequent descriptions, this section defines the core symbols used in the protocol.

The Poseidon commitment is computed as follows:

C = Poseidon( amt , r )

where , denotes concatenation. Poseidon is a hash function highly optimized for ZK circuits, with arithmetic operations over finite fields far more efficient than SHA-256 or Keccak-256, making it widely used in ZKP systems. The blinding factor r ensures that identical order amounts do not produce identical commitment values, thereby preventing on-chain observers from inferring order information through commitment collisions.

3 Phase One: Cross-Chain Deposit and Ownership Proof

3.1 Flow Description

The user first initiates a cross-chain transfer transaction on the external source chain (Source Chain), depositing native assets or tokens into the cross-chain bridge deployed by Invisibook on that chain. After the bridge locks the user’s assets, the deposit information is synchronized to the Invisibook chain via cross-chain message passing mechanisms (such as state root anchoring, relayer networks, or light client verification). The source chain can be any supported L1 or L2 network, such as Ethereum, Solana, Arbitrum, etc.

On the Invisibook chain, user account balances are always stored in ciphertext form. Specifically, the on-chain state records not the user’s actual balance value but a cryptographically processed ciphertext representation. This design ensures that even though on-chain data is public to all validators, no third party can directly read the user’s true balance.

After completing the deposit, the user must submit a zero-knowledge proof π_deposit on the Invisibook chain, proving that they are indeed the initiator and legitimate holder of the deposit transaction on the source chain, and that the on-chain ciphertext balance has been correctly updated.

3.2 Algebraic Description

Suppose user Alice deposits amount d into the cross-chain bridge, with her old ciphertext balance on the Invisibook chain being bal_old and new ciphertext balance being bal_new. The following must hold:

π_deposit: {

bal_new = Encrypt(Decrypt(bal_old) + d)

∧ deposit_tx ∈ source_chain_tx_root

∧ sender(deposit_tx) = addr_Alice

}

The first constraint ensures the correctness of the balance update, the second ensures the deposit transaction was indeed confirmed by the source chain blockchain, and the third ensures the binding between the transaction initiator and the Invisibook account.

4 Phase Two: Private Order Submission

4.1 Flow Description

When a user wishes to place an order on the Invisibook order book, they need to construct a private order. The order consists of two parts:

• Plaintext price (price): The unit price information of the order is publicly submitted to the chain in plaintext for the matching engine to use. This is the foundation for price discovery and matching in the order book.

• Amount commitment (C): The actual trading quantity of the order is submitted to the chain in the form of a Poseidon commitment. Any on-chain observer can only see an irreversible hash value and cannot recover the true order amount.

Simultaneously, the user must generate and submit a zero-knowledge proof π_order that satisfies the following constraints:

• Commitment format correctness: C = Poseidon(amt , r)

• Balance sufficiency: amt × price ≤ Decrypt(bal_user)

• Amount positivity: amt > 0

4.2 Algebraic Description

Order = { price, C, side, π_order }

where side ∈ {BUY, SELL} indicates the order direction. The complete ZK Proof statement is as follows:

π_order: {

∃ amt, r s.t.

C = Poseidon(amt , r)

∧ amt > 0

∧ amt × price ≤ Decrypt(bal_user)

}

This proof ensures that users cannot place fraudulent orders exceeding their balance, nor submit illegal zero-amount or negative-amount orders. Since the proof is verified on-chain, any order that fails to satisfy the above constraints will be rejected.

4.3 Security Analysis

By hiding amounts within Poseidon commitments, Invisibook achieves order amount privacy. The on-chain matching engine, validators, and other traders can only see the price and direction of an order, and cannot determine its specific quantity. This design effectively defends against the following attack vectors:

• Front-running: Attackers cannot front-run by observing large orders.

• Liquidity Manipulation: When attackers see large market orders, they may preemptively remove low-priced limit orders and re-place them at higher prices, forcing victims to execute at worse prices. Since amounts are invisible, attackers cannot judge order size, and thus cannot determine whether manipulation would be profitable.

• Strategy Inference: Market makers or competitors cannot infer users’ trading strategies and position information from order quantities.

5 Phase Three: On-Chain Order Matching

5.1 Matching Mechanism

The matching engine on the Invisibook chain operates on the core principle of Price Priority. Since all order prices are publicly disclosed in plaintext, the matching engine can execute standard order matching logic normally.

Specifically, the matching engine maintains a standard two-sided order book:

• Bid Book: Sorted by price from high to low.

• Ask Book: Sorted by price from low to high.

When a new buy order price ≥ the current best ask price (or vice versa), the matching engine marks these two orders as matched and triggers the subsequent off-chain settlement process.

5.2 Matching Priority Rules

When multiple orders have prices within the executable range, the matching engine sorts them according to the following three-level priority to determine the matching order:

• First Priority — Best Price (Price Priority): Among buy orders, the highest bid is matched first; among sell orders, the lowest ask is matched first. This is the fundamental principle of all order books, ensuring the market’s price discovery function operates normally.

• Second Priority — Earliest Block Height (Block Height Priority): When multiple orders have the same price, the block height at which the order was included serves as the time-ordering criterion. Orders in lower-numbered blocks (i.e., earlier on-chain) enjoy higher matching priority. This rule ensures first-come-first-served fairness, preventing latecomers from displacing earlier participants at the same price.

• Third Priority — Highest Gas Fee (Gas Fee Priority): If multiple orders have the same price and are within the same block (i.e., same block height), they are sorted by gas fee paid in descending order. Orders paying higher gas fees are matched first. This rule provides a market-based ordering mechanism within blocks — when users wish to gain higher execution priority at the same price level, they can express this desire by increasing their gas fee.

The above priority rules can be formally expressed as:

Priority(order) = ( price, block_height↑, gas_fee↓ )

That is: first sort by price (descending for buy orders, ascending for sell orders), then by block height in ascending order when prices are equal (earlier is prioritized), and then by gas fee in descending order when block heights are also equal (higher fee is prioritized).

5.3 Important Design Trade-off

Since order amounts are in ciphertext form, the matching engine cannot know during the matching phase whether the true quantities of two matched orders are equal. Therefore, Invisibook’s matching result is only a “price match”, not a “full execution match” in the traditional sense. The actual quantity comparison and difference processing must be completed during the off-chain settlement in Phase Four.

This design represents the most fundamental difference between Invisibook and traditional order book matching engines: traditional engines can complete precise quantity matching and partial fill processing during matching, whereas Invisibook defers quantity-related computation to the off-chain privacy settlement phase.

6 Phase Four: Off-Chain Privacy Settlement

Phase Four is the most complex and critical step in the Invisibook protocol. After the matching engine pairs two orders, both trading parties must first click to confirm the match result. Then the order holders (hereafter referred to as Alice and Bob) must complete settlement through an off-chain peer-to-peer privacy protocol.

Figure 2: Phase Four — Detailed Off-Chain Privacy Settlement Flow

6.1 Secure Amount Comparison: Malicious-Secure Secret-Sharing MPC (SPDZ)

The first step of settlement is to determine which party has the smaller order amount. However, since both parties’ order amounts are private, neither party can directly send their plaintext amount to the other (doing so would leak privacy during the comparison phase).

Invisibook employs a malicious-secure MPC protocol based on SPDZ to complete commitment verification and numerical comparison without revealing either party’s input.

SPDZ (“Speedz”) is a malicious-secure multi-party computation framework based on additive secret sharing and information-theoretic MAC (IT-MAC). In Invisibook’s settlement scenario, Alice and Bob each hold secret inputs (order amount amt and blinding factor r), and both parties run the SPDZ protocol to execute the following logic:

1. Commitment verification: Compute Poseidon(amt_A, r_A) under secret sharing and verify it equals the on-chain commitment C_A; similarly verify Poseidon(amt_B, r_B) == C_B.
2. Numerical comparison: Compute the comparison result b = (amt_A ≤ amt_B) under secret sharing.
3. IT-MAC malicious security guarantee: SPDZ’s IT-MAC mechanism ensures that if either party attempts to tamper with their input or intermediate computation, it will be detected by the other party, and the protocol will abort.

Integrated design of commitment verification and comparison: Commitment verification is executed within the MPC protocol itself — neither party needs to publicly reveal their commitment opening before comparison. The protocol internally computes the Poseidon hash using secret shares and compares it against the on-chain commitment, merging commitment verification and numerical comparison into a single atomic operation, preventing any intermediate information leakage.

Share output: The comparison result b is not directly revealed to either party, but output as additive secret shares:

• Alice receives share_A (a random value)
• Bob receives share_B
• Satisfying share_A + share_B ≡ b (mod p)

Each party submits their share to the chain, and the on-chain logic completes the synthesis.

6.1.1 On-Chain Share Synthesis

After MPC completion, both parties must submit their respective shares on-chain within the prescribed block deadline (10 block times). The on-chain logic executes the following operations:

• Compute share_A + share_B mod p to obtain the comparison result b
• b = 1 indicates amt_A ≤ amt_B (Alice is the smaller-order party); b = 0 indicates amt_A > amt_B (Bob is the smaller-order party)
• After the comparison result is publicly confirmed on-chain, the subsequent settlement process is triggered

On-chain synthesis ensures that the finality of the comparison result does not depend on any single party, but is guaranteed through on-chain verification.

6.1.2 Timeout Freeze Mechanism

If one party fails to upload their share within the deadline (10 block times):

• The delaying party’s order is frozen for 72 hours
• The party that already uploaded has their order released and can re-enter matching

This mechanism ensures both parties are incentivized to promptly complete on-chain share submission, guaranteeing the liveness of the settlement process.

6.2 Smaller-Order Party Settlement (Alice as Example)

Assume the comparison result is amt_A <= amt_B, meaning Alice holds the smaller order. Alice must then perform the following operations:

6.2.1 Peer-to-Peer Plaintext Transmission

Alice sends her plaintext order amount amt_A and the corresponding 256-bit random blinding factor r_A to Bob through secure peer-to-peer communication. Bob can then locally verify:

Poseidon(amt_A , r_A) == C_A

where C_A is the order commitment Alice previously published on-chain. If verification passes, Bob can be confident that the plaintext data Alice sent is consistent with the on-chain commitment, with no deception.

6.2.2 On-Chain State Update

Alice submits the following updates to the chain:

• Mark her order status as “fully filled”

• Update her ciphertext account balance (deducting the filled amt_A portion, crediting the corresponding bought/sold assets)

This result is confirmed by the on-chain share synthesis (see 6.1.1).

6.3 Larger-Order Party Settlement (Bob as Example)

After Bob receives amt_A and r_A from Alice, he first locally verifies the commitment consistency. Upon successful verification, Bob locally computes the new remaining order quantity:

amt_B’ = amt_B - amt_A

Bob then selects a new random blinding factor r_B’ and computes the new order commitment:

C_B’ = Poseidon(amt_B’ , r_B')

Bob submits the following updates to the chain:

• Update his order commitment from C_B to C_B’ (the remaining order continues as an open order)

• Update his ciphertext account balance (crediting the amt_A portion settled in this round)

• Attach a zero-knowledge proof π_B that simultaneously proves the following two statements:

  π_B: {

  (1) amt_B’ = amt_B - amt_A

  (2) Poseidon(amt_A , r_A) = C_A

  }

Statement (1) proves that the new order amount is the correct result of subtracting the smaller order amount from the old order amount (ensuring Bob did not tamper with the calculation). Statement (2) proves that the amt_A used by Bob is indeed consistent with Alice’s previously committed order ciphertext C_A on-chain (preventing Bob from fabricating the smaller order quantity to gain illegitimate benefits).

6.4 Challenge

After on-chain share synthesis is complete and the comparison result has been publicly confirmed, the smaller-order party must send their plaintext amount amt and blinding factor r to the larger-order party to complete settlement. If the smaller-order party (Alice as example) refuses to send, the following challenge process is triggered:

If Alice has not sent the plaintext after more than 5 block times, Bob can initiate a forced request on-chain, attaching his public key Pub_B, to compel Alice to encrypt her amt_A and r_A with Pub_B and submit Pub_B(amt_A, r_A) on-chain. After Alice sees the forced request, she must send Pub_B(amt_A, r_A) to the chain within 10 block times; otherwise, Alice’s order will be immediately frozen for 72 hours, and Bob’s order can re-enter matching with other encrypted orders.

After Bob sees Pub_B(amt_A, r_A) appear on-chain, he downloads it locally, decrypts it, and proceeds with verification and settlement following the steps in 6.2/6.3.

7 Proof Obligations Summary by Phase

The following table summarizes the zero-knowledge proofs involved in each phase of the protocol and the core statements they prove:

8 Security Properties Summary

The Invisibook protocol provides the following security guarantees at different levels:

• ← Previous Post