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 SPDZ-based malicious-secure MPC combined with collaborative zero-knowledge proofs (co-ZK) for performing secure numerical comparison and generating verifiable proofs between two parties without revealing private inputs.

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 deposited funds are recorded as private UTXO notes (Zcash-style), with note commitments appended to an on-chain Merkle tree, and a ZK Proof is submitted to prove fund ownership.

• Phase Two: Private Order Submission — Users create orders by consuming private UTXOs (via nullifiers) as collateral. Prices are publicly disclosed in plaintext, amounts are hidden via Poseidon commitments, and a ZK Proof proves that the consumed UTXOs fully cover the order value.

• 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 — Matched orders are immediately locked on-chain and enter the settlement process. The two parties run a SPDZ-based MPC protocol that jointly produces secret shares of both the comparison result and a collaborative ZK proof (co-ZK). Each party submits their shares on-chain, where the chain assembles the comparison result and the proof. The smaller-order party then sends the plaintext to the larger-order party to complete the difference calculation, UTXO creation, 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 funds are stored as private UTXO notes in a Zcash-style model. Each note is a tuple (addr, v, r), where addr is the owner’s address, v is the value, and r is a random blinding factor. The note commitment cm = Poseidon(addr, v, r) is appended to an on-chain append-only Merkle tree. This design ensures that even though the Merkle tree is public to all validators, no third party can determine the owner or value of any note.

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 corresponding note commitment has been correctly computed and inserted into the Merkle tree.

3.2 Algebraic Description

Suppose user Alice deposits amount d into the cross-chain bridge. A new private UTXO note note_new = (addr_Alice, d, r) is created, with commitment cm_new = Poseidon(addr_Alice, d, r). The following must hold:

π_deposit: {

  cm_new = Poseidon(addr_Alice, d, r)

  ∧  deposit_tx ∈ source_chain_tx_root

  ∧  sender(deposit_tx) = addr_Alice

}

The first constraint ensures the note commitment is correctly formed, 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. After verification, cm_new is appended to the on-chain Merkle tree.

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. An order is a special on-chain object with the following tuple structure:

Order = (oid, τ, d, p, cm_q, pk, f)

where oid is the unique order ID, τ ∈ {BUY, SELL} is the order direction, d is the trading pair identifier, p is the plaintext price, cm_q = Poseidon(q, r_q) is the commitment to the order quantity q, pk is the creator’s public key, and f is the plaintext fee.

To create an order, the user must consume one or more private UTXO notes (via publishing their nullifiers on-chain) whose total value covers p · q + f. This mechanism ensures full collateralization: the consumed notes serve as locked collateral for the order.

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

• Each consumed note exists in the on-chain Merkle tree (Merkle membership proof)

• Each nullifier is correctly derived from the corresponding note

• The total value of consumed notes ≥ p · q + f (full collateralization)

• Commitment format correctness: cm_q = Poseidon(q, r_q)

• Amount positivity: q > 0

4.2 Algebraic Description

Order = (oid, τ, d, p, cm_q, pk, f)

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

π_order: {

  ∃ q, r_q, {note_i, path_i, nf_i}  s.t.

  ∀i: MerkleVerify(root, cm_i, path_i) = true

  ∧  ∀i: nf_i = DeriveNullifier(note_i)

  ∧  Σ note_i.v ≥ p · q + f

  ∧  cm_q = Poseidon(q, r_q)

  ∧  q > 0

}

This proof ensures that users cannot place orders without sufficient collateral (the consumed UTXOs must fully cover the order value plus fee), 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. Upon acceptance, the nullifiers of the consumed notes are recorded on-chain, preventing double-spending.

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 four-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 Fee (Fee Priority): If multiple orders have the same price and are within the same block (i.e., same block height), they are sorted by the plaintext fee field f in descending order. Orders paying higher 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 order fee.

• Fourth Priority — Intra-Block Transaction Index (Index Priority): If orders share the same price, block height, and fee, they are ordered by their transaction index within the block in ascending order. This provides a deterministic tiebreaker to ensure a fully defined ordering.

The above priority rules can be formally expressed as:

Priority(order) = ( price, block_height↑, fee↓, tx_index↑ )

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), then by fee in descending order when block heights are also equal (higher fee is prioritized), and finally by intra-block transaction index in ascending order as a deterministic tiebreaker.

Strictly pairwise matching: Because order amounts are hidden, the matching engine cannot aggregate multiple orders. Each match pairs exactly one bid with one ask. After a match, both orders are immediately locked on-chain: they can no longer be canceled and are forced into the settlement process.

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. Additionally, matching is strictly pairwise (one bid, one ask) because the chain cannot aggregate multiple hidden-amount orders.

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 orders are immediately locked on-chain and enter the settlement process. 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 with collaborative ZK proofs (co-ZK): Commitment verification and numerical comparison are executed within the MPC protocol as a single atomic operation. Neither party needs to publicly reveal their commitment opening. The protocol internally computes the Poseidon hash using secret shares and compares it against the on-chain commitment. Furthermore, the MPC protocol jointly generates a collaborative zero-knowledge proof (co-ZK) π_cmp that attests to the correctness of the comparison — neither party alone can construct this proof, and neither party learns the other’s private input during the process.

Share output: The MPC protocol produces two types of secret shares:

• Comparison result shares: Alice receives share_b_A, Bob receives share_b_B, satisfying share_b_A + share_b_B ≡ b (mod p)
• Proof shares: Alice receives share_π_A, Bob receives share_π_B, which can be assembled on-chain into the complete proof π_cmp

Neither the comparison result nor the proof is directly revealed to either party. Each party submits both their comparison share and proof share to the chain, and the on-chain logic completes the assembly.

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:

• Assemble the comparison result: compute share_b_A + share_b_B mod p to obtain b
• Assemble the collaborative proof: combine share_π_A and share_π_B to reconstruct π_cmp
• Verify π_cmp on-chain to confirm the correctness of the comparison
• 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 and proof are publicly verified 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 cryptographically guaranteed through on-chain proof verification.

6.1.2 Timeout Freeze Mechanism

The protocol distinguishes two failure scenarios:

Case 1 — MPC Abort: If the MPC protocol itself aborts (e.g., due to detected cheating via IT-MAC, network failure, or either party going offline during computation), no penalty is imposed. Both orders are unlocked and returned to the order book for re-matching. This is because an abort may result from legitimate network issues rather than intentional misbehavior.

Case 2 — Withholding Shares: If the MPC completes successfully but one party fails to upload their shares on-chain 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

The penalty is a freeze, not a slash, because failure to submit may also result from network faults rather than malicious intent. 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:

• Her order is marked as destroyed on the order book (fully filled)

• A new private UTXO note is created and paid to Bob (the counterparty), representing the settled asset transfer of amt_A

• Alice provides a zero-knowledge proof π_A proving the consistency of the settlement (the UTXO amount matches the committed order quantity)

This result is confirmed by the on-chain share synthesis and proof verification (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:

• His original order is marked as destroyed on the order book

• A new order o_B’ is created with the updated commitment C_B’ (the residual order continues as an open order on the book)

• A new private UTXO note is created and paid to Alice (the counterparty), representing the settled asset transfer of amt_A

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

π_B: {

  (1)  amt_B' = amt_B - amt_A  ∧  amt_B' ≥ 0

  (2)  Poseidon(amt_A , r_A) = C_A

  (3)  The new UTXO amount is consistent with the fill quantity amt_A

}

Statement (1) proves that the residual order amount is the correct result of subtracting the smaller order amount from the old order amount, and that the residual is non-negative (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). Statement (3) ensures the new UTXO paid to the counterparty is consistent with the actual fill.

Equal quantities case: When amt_A = amt_B, both orders are fully filled and marked as destroyed. Two new private UTXO notes are created — one paid to each party — and no residual order remains.

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.

Adjudication: If Alice posts plaintext data that is incorrect (i.e., does not match her on-chain commitment), Bob can submit Alice’s claimed (amt_A, r_A) to the chain. The on-chain logic checks whether Poseidon(amt_A, r_A) = C_A. If the check fails, Alice’s order is frozen and Bob’s order is released for re-matching.

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