ZK-verifiable matching for private CLOBs, with Hibachi as example
Post318 words
ZK proofs let an operator match orders off-chain at low latency while proving rule-following. Hibachi posts encrypted state to Celestia and proves its CLOB with SP1, keeping positions private yet verifiable.
Key claims
Proof can enforce price-crossing, priority rules and correct balance updates
Hibachi uses SP1 and Celestia DA
ZK-verifiable matching is a way to run a fast, private orderbook while still giving users a cryptographic guarantee that the matching engine followed the rules.
The problem it solves is simple: a CLOB needs an operator (or a small set of operators) to match orders quickly, but that operator can also cheat (reorder, skip, or selectively fill).
ZK changes the trust model: the operator can stay fast, but canโt finalize an update unless they prove it was computed correctly.
๐๐ผ๐ ๐ถ๐ ๐๐ผ๐ฟ๐ธ๐ (๐ฐ๐ผ๐ป๐ฐ๐ฒ๐ฝ๐๐๐ฎ๐น๐น๐)
โค Orders are collected and matched off-chain (so you can get low-latency execution).
โค Instead of publishing the full order flow, the system publishes:
- ๐ข ๐ค๐ฐ๐ฎ๐ฎ๐ช๐ต๐ฎ๐ฆ๐ฏ๐ต ๐ต๐ฐ ๐ต๐ฉ๐ฆ ๐ฃ๐ข๐ต๐ค๐ฉ / ๐ด๐ต๐ข๐ต๐ฆ ๐ต๐ณ๐ข๐ฏ๐ด๐ช๐ต๐ช๐ฐ๐ฏ (๐ฐ๐ง๐ต๐ฆ๐ฏ ๐ข ๐ด๐ต๐ข๐ต๐ฆ ๐ณ๐ฐ๐ฐ๐ต)
- ๐ข ๐ป๐ฌ-๐ฑ๐ณ๐ฐ๐ฐ๐ง ๐ต๐ฉ๐ข๐ต ๐ต๐ฉ๐ฆ ๐ฎ๐ข๐ต๐ค๐ฉ๐ช๐ฏ๐จ + ๐ณ๐ช๐ด๐ฌ ๐ค๐ฉ๐ฆ๐ค๐ฌ๐ด + ๐ฃ๐ข๐ญ๐ข๐ฏ๐ค๐ฆ ๐ถ๐ฑ๐ฅ๐ข๐ต๐ฆ๐ด ๐ธ๐ฆ๐ณ๐ฆ ๐ฅ๐ฐ๐ฏ๐ฆ ๐ข๐ค๐ค๐ฐ๐ณ๐ฅ๐ช๐ฏ๐จ ๐ต๐ฐ ๐ต๐ฉ๐ฆ ๐ฑ๐ณ๐ฐ๐ต๐ฐ๐ค๐ฐ๐ญ ๐ณ๐ถ๐ญ๐ฆ๐ด,
- ๐ฆ๐ฏ๐ฐ๐ถ๐จ๐ฉ ๐ฅ๐ข๐ต๐ข ๐ข๐ท๐ข๐ช๐ญ๐ข๐ฃ๐ช๐ญ๐ช๐ต๐บ ๐ด๐ฐ ๐ถ๐ด๐ฆ๐ณ๐ด ๐ค๐ข๐ฏ ๐ด๐ต๐ช๐ญ๐ญ ๐ฆ๐น๐ช๐ต ๐ฆ๐ท๐ฆ๐ฏ ๐ช๐ง ๐ต๐ฉ๐ฆ ๐ฐ๐ฑ๐ฆ๐ณ๐ข๐ต๐ฐ๐ณ ๐ฅ๐ช๐ด๐ข๐ฑ๐ฑ๐ฆ๐ข๐ณ๐ด.
That โenough data availabilityโ is where @hibachi_xyzโs design choice is interesting:
Hibachi is running a high-performance CLOB and posting encrypted state / trade data to @Celestia (so strategies and positions arenโt public), while still publishing proofs so updates remain verifiable, using SP1 (Succinctโs zkVM) to prove the CLOB.
๐๐๐ ๐๐ต๐ฎ๐ โ๐บ๐ฎ๐๐ฐ๐ต๐ถ๐ป๐ด ๐๐ฎ๐ ๐ฐ๐ผ๐ฟ๐ฟ๐ฒ๐ฐ๐โ ๐บ๐ฒ๐ฎ๐ป๐ ๐ถ๐ป ๐ฝ๐ฟ๐ผ๐ผ๐ณ ๐๐ฒ๐ฟ๐บ๐?
A zk-proof can enforce the same invariants youโd normally rely on an exchange operator to follow, for example:
โค Orders were matched only when prices cross (no impossible fills).
โค The fill sequence respected the venueโs priority rule (e.g., price-time priority, or whatever the venue specifies).
โค Balances/margins were updated correctly (no hidden balance edits).
โค Resulting state root is exactly what you get by applying the rules to the previous state root + the batch.
You can keep the contents private (orders, sizes, positions) by encrypting whatโs published to the DA layer, while the proof convinces everyone that the encrypted update is still a valid state transition.
1 image on X