OCLOB: oblivious continuous limit order book

A continuous, non-batched limit order book where the operator does not see side, price, quantity or the participant until arrival order is fixed and matching is done. The public book is total quantity per price level. Fills settle as pre-authorised zkPI instructions into DeFMI with no re-signing after the match.

source: oclob/README.md, docs/ARCHITECTURE.md, docs/THREAT_MODEL.md, docs/STATUS.md, docs/RELATED_WORK.md

What it prevents

In an ordinary decentralized CLOB an order is visible to validators, sequencers and mempool watchers before it matches. Whoever sees it can insert a better order ahead of it or delay only the unfavourable ones. OCLOB fixes one thing: reading a pending order's content and then placing one's own order ahead of it. It does not prevent ordinary prediction from the public book, inference from post-fill book deltas, traffic-timing observation, collusion of three or more MPC nodes, or halting by network interference.

The order of operations

1. A maker reserves maximum inventory or cash before resting on the book; a taker pre-authorises, at submission, a reservation and any fill inside its limits.
2. The order is secret-shared at the participant; only a commitment is published.
3. Five of seven nodes sign the arrival number.
4. Seven nodes run price-time priority matching in MPC without changing the arrival number.
5. A transition proof binds the fills to the public book update.
6. A threshold zkPI is built and cash and securities settle simultaneously in DeFMI.
7. Only after DeFMI's authoritative receipt does the screen say "settled".

flowchart LR
    CORP["participant module
signing, DeKYX, reservation"]
    QUEUE["encrypted durable queue
keeps order while halted"]
    ORDER["arrival committee
5 of 7"]
    MPC["secret matching
MP-SPDZ, 7 processes"]
    PROOF["transition proof
arrival + book + fills"]
    ZKPI["threshold zkPI
only the fill range"]
    DEFMI["DeFMI
cash and securities together"]
    BOOK["public book
totals per price level"]
    CORP --> QUEUE --> ORDER --> MPC --> PROOF --> ZKPI --> DEFMI
    MPC --> BOOK
    DEFMI -->|"authoritative receipt"| CORP

Four states, deliberately apart

• Participant secret state: the full order, signing keys, the DeKYX credential, reservation openings.
• MPC secret state: each node's share of the order and of the resting book. One node alone cannot read a value.
• Public state: market id, arrival numbers, order commitments, per-level totals, fills, verification evidence, DeFMI root digests.
• Settlement authority: the pre-signed order and the DeKYX presentation, as a fixed-length ciphertext, delivered only to the settlement side.

In the distributed path the participant builds a verifiable 3-of-7 Pedersen split, encrypts one share per node under that node's key, and delivers over mutual TLS with fixed-length messages, so message size does not vary with the order. Each node returns a signed storage receipt over the order digest and its persisted state generation. The public summary is signed with a per-order disposable key, so the coordinator receives neither the order nor the participant's long-term key.

Arrival order without content

The statement five nodes sign contains only (market id, arrival number, order commitment, previous certificate digest, expiry). Each node persists its vote before signing and will not sign a different order under the same number in the same window. The MPC request carries the certificate body, not just its digest, and every node re-verifies signature count, subject and chain continuity against the fixed seven public keys before running. Two conflicting 5-of-7 certificates cannot exist because any two five-sets share an honest node. This is not a claim about which packet was first in the world: asynchronous networks have no total arrival order, and the design separates observed order from the provable fixing rule.

Matching and the book

Bids from highest, asks from lowest, and within a level by arrival number. The MPC evaluates a fixed batch of eight slots and opens only: whether each slot filled, fill price and quantity, and the arriving order's publishable remainder. It does not open the participant, the DeKYX nullifier, keys or reservation openings. An order that could fill more than eight slots at once is rejected at admission rather than silently truncated. The public book is (side, price tick, total resting quantity); it does not publish counts. A level with one participant leaks that participant's size through deltas, and that leakage is measured separately from the anonymity claim.

Pre-authorised settlement

A participant signs at submission that any fill inside the following may settle automatically: no worse than the limit, within quantity and reservation caps, within expiry, on the named market, asset and DeFMI, under the published price-time rule. So no re-signing after the match, and no probing a counterparty by refusing to sign after seeing the result. Implementation is two-phase: a resting GTC maker order, once the MPC says "no fill, rests", gets a threshold zkPI for its secret maximum and a reservation root pair, and joins the matchable set only after Avalanche finality. An arriving taker that fills has its reservation, all fills and the release of the unused remainder applied as one DeFMI compare-and-swap; if the L1 rejects, the secret book, entity caps, balances and DeKYX one-time state are all as before.

Eligibility and entity caps

Participation is a DeKYX anonymous presentation under the qualification namespace org.zkfmi.oclob.legal-entity-participant, with a scope-specific nullifier so one legal entity's concurrent orders share one reservation cap across the book. DeCCP and DeFMI hold the external configuration of that cap.

What was accepted, and where

The integrated acceptance runs on one Linux host under one administrator (no builds on the development Mac): participant-side split, direct delivery to seven MPC containers, maker reservation, taker reservation plus multi-fill DvP on the five-validator non-EVM DeFMI L1, root agreement across all validators, rejection of a replayed transition, and recovery of one validator after restart, all on the same order digest. The React Flow demo was driven at 1440×1000 and 390×844 with zero horizontal overflow and zero console errors.

artifacts: oclob_distributed_avalanche_acceptance.json, oclob_distributed_e2e.json, oclob_rough_e2e.json

Against prior work

"A DEX that matches secret orders in MPC" is not new. Rialto, P2DEX and Renegade are clear predecessors, and TEE-based (Tesseract), commit-then-reveal, batch and distributed-public-CLOB designs exist. OCLOB claims no cryptographic component. The candidate difference is one state machine that combines: continuous rather than batch processing; variable quantity, partial and multiple fills, GTC, IOC, cancel and expiry in secret state; arrival order fixed 5-of-7 before content is opened and bound to time priority; a continuously published per-level aggregate book; and anonymous legal-entity eligibility, entity-wide reservations, threshold zkPI and atomic DvP with no post-match signature. P2DEX's UC security and misbehaving-server compensation are ahead of OCLOB and listed as open work. TEEs are deliberately not in the trust boundary.

From the technical deck to implementation

The 37-topic cryptography catalogue maps purpose, equations, actors and limitations. Follow the settlement lifecycle for state transitions and optimistic assurance for the two demos and their native settlement boundary.