feat(privacy_of_intent): PoC proposal, Jigsaw matcher vs encrypted mempool

[Meyanis95]

Draft proposal for discussion. Posting as an issue to gather feedback before writing a full REQUIREMENTS.md / SPEC.md. Open questions are intentional.

Motivation

• Public mempools and order flow leak intent (MEV, front-running, information asymmetry). Institutional flow cannot be published in the clear.
• Two distinct designs worth evaluating side by side; they answer different questions.

Relation to iptf-map

• Anchors under pattern-pretrade-privacy-encryption: a meta-pattern that explicitly composes the three building blocks below. This PoC is a concrete instantiation.
• Maps cleanly to two sub-patterns, one per option:
  • Option A (Jigsaw): pattern-private-shared-state-cosnark (multi-party joint computation over shared secret inputs, which is what the matching servers do) and pattern-co-snark (delegated proving, the closest single-pattern primitive for the server-side construction).
  • Option B (encrypted mempool): pattern-threshold-encrypted-mempool (Shutter is the canonical impl) and pattern-private-transaction-broadcasting.
• Settlement leg: pattern-shielding; approach-level context in approach-private-trade-settlement and approach-private-broadcasting.
• Driving use cases: use-cases/private-derivatives, private-stocks, private-fx.

Option A: Jigsaw-style private matcher (Renegade lineage)

• Construction: client-side ZK + server-side co-SNARKs.
  • Each trader produces a regular ZK proof that their intent is well-formed (constraints met, funds available, etc.) without revealing the intent itself.
  • A set of matching servers runs the matching algorithm under co-SNARKs (MPC + ZK across the server set). Under the co-SNARK honest-majority assumption, no single server learns any intent in plaintext; the output is a verifiable proof that two intents matched correctly.
• Privacy properties: intents stay hidden both on-chain and from the matching server(s). The matcher executes the algorithm but never sees the plaintext.
• Renegade is the canonical deployed system in this lineage (P2P co-SNARKs between traders, blind relayer).
• No known open-source implementation of the Jigsaw paper itself exists. Reproducing it would be custom from-scratch work, not a library wrap. This is a real scope cost worth surfacing before committing.

Option B: Toy encrypted mempool

• Threshold-encrypted transactions, decrypted after ordering by a committee (Shutter-style).
• Demonstrates the generic encrypt → include → decrypt → execute pipeline.
• Broader applicability than A, but weaker privacy (post-decryption everything is public, matching the partial privacy rating in pattern-threshold-encrypted-mempool).
• Reference impl exists: Shutter (Go).

Trade-offs to discuss

• A: strong, narrow, crypto-heavy, custom impl required. B: weaker, generic, simpler, library available.
• A is closer to a product; B is closer to infrastructure.
• Scope asymmetry matters: A is a multi-quarter build; B is plausibly a few weeks on top of Shutter.
• Natural fit for the multi-approach PoC pattern in CLAUDE.md: shared REQUIREMENTS.md, two SPEC.mds.

Open questions

• Which matters more for institutional adoption: app-specific privacy (A) or generic mempool privacy (B)?
• Pick one, or build both under a single "private intent" PoC?
• Option A scoping: since there is no public Jigsaw impl, do we (i) reproduce the paper faithfully (large), (ii) build a simplified single-operator + client-side ZK approximation, or (iii) start from Renegade's open-source components and document the gap to Jigsaw?
• Option B: which threshold scheme (BLS / class groups / threshold FHE)? How do we handle committee liveness in a toy?
• Where does settlement happen: L1, an L2, or out of scope for the PoC?

Prior art

• Jigsaw paper.
• Renegade Fi.
• Shutter Network; Osmosis encrypted mempool.
• Flashbots SUAVE.