Pre-trade Privacy (Encrypted Order Flow)

Prevent front-running and information leakage by routing quotes and orders via encrypted or private submission paths so intent, size, and price stay hidden until inclusion. Settlement then proceeds on a shielded pool or confidential rail so the executed amounts also remain private.

Works best when

  • RFQ or secondary trading must not leak intent, size, or price pre-inclusion.
  • Order flow needs protection from both the public mempool and builders that could front-run.

Avoid when

  • Public mempool visibility of orders is acceptable.
  • Latency budgets cannot accommodate threshold-encryption or private builder round-trips.

I2I vs I2U — context differences

Institution to institution

I2I

Institutional block trades signal portfolio intent long before settlement. Encrypting RFQ and quote flow until inclusion prevents counterparties, intermediaries, and builders from adverse selection or front-running. Both sides have legal recourse if an intermediary leaks, so the threat is reputational and economic rather than adversarial.

Institution to end user

I2U

Retail orders are extracted by builders, searchers, and private relays with operator-controlled visibility. Encrypted or threshold-encrypted submission removes the builder's ability to unilaterally front-run, but requires the user's tooling to integrate with the encrypted path. Without a fallback to an unencrypted route, a stalled decryption committee can effectively censor.

Post-quantum exposure

Risk · medium
Vector
Threshold encryption and commit-reveal schemes often rely on pairings (BLS) or curve-based encryption broken by CRQC.
Mitigation
Lattice-based threshold encryption or hash-based commit-reveal with post-quantum VRFs for committee selection.

Visibility

Actor Sees
Counterparty
  • quote_contents
Chain
  • settlement_events
Regulator
  • full_order_lifecycle via audit path
Public —

Components

  • Encrypted submission path: either a threshold-encrypted mempool (committee holds key shares; ciphertext is decrypted only after ordering is committed) or a private-builder stack (confidential execution environment that sees the order but commits to ordering honesty).
  • RFQ broker: off-chain service that routes quote requests to allow-listed counterparties and records the quote lifecycle for audit.
  • Settlement rail: shielded pool or privacy L2 where the winning order settles with amounts hidden.
  • Fallback path: unencrypted submission route invoked if the encrypted path stalls or fails.
  • Audit trail: signed or committed record of every RFQ, quote, and settlement for compliance review.

The encrypted mempool details are covered in pattern-threshold-encrypted-mempool; the settlement layer in pattern-shielding or pattern-privacy-l2s.

Protocol

  1. user A buyer emits an RFQ off-chain. The request is routed to allow-listed counterparties via the RFQ broker.
  2. user Counterparties return quotes privately to the broker, who relays them only to the requestor.
  3. user The requestor selects a winning quote and submits the corresponding order via the encrypted path (threshold-encrypted ciphertext or private builder).
  4. operator The committee or private builder includes the order in a block without revealing its contents pre-inclusion.
  5. contract Settlement executes on the shielded rail: amounts, sender, and receiver stay hidden.
  6. auditor The broker and committee produce an auditable record of the RFQ lifecycle for compliance review.

Guarantees & threat model

Guarantees:

  • No public mempool leakage of intent, size, or price pre-inclusion.
  • Auditable RFQ lifecycle available to regulators via scoped access.
  • Settled amounts remain private when the settlement rail is shielded.

Threat model:

  • Honesty of the threshold committee or private builder. A colluding quorum can decrypt early or leak selectively.
  • Liveness of the encrypted path. A stalled committee or builder forces the fallback path, where orders become visible again.
  • RFQ broker trust. A malicious broker can leak quote flow to non-participants even if the on-chain path is encrypted.
  • Counterparty allow-list correctness. Mis-listed counterparties can exfiltrate order intent legally but undesirably.

Trade-offs

  • Latency and availability are tied to the privacy routing. A slow committee or builder can miss inclusion windows.
  • Additional infra dependency. Both the encrypted mempool and the RFQ broker are new services that must be operated and monitored.
  • Fallback paths reintroduce public mempool visibility; protocol design must make fallback rare and auditable.
  • Allow-listed counterparties create a two-sided trust boundary that must be governed.

Example

  • Three quotes are received for a block trade.
  • The winning quote is submitted via the encrypted path.
  • The losing quotes remain undisclosed to the public and to competing market makers.
  • Settlement finalizes on a shielded pool. On-chain observers see only the settlement event, not the price or size.

See also

Variants

  1. 01

    Threshold-encrypted mempool

    Medium CR via committee, partial privacy (decrypted post-inclusion), low-medium security (committee collusion risk).

    →
  2. 02

    Private transaction broadcasting

    Low-medium CR via private relay, partial privacy pre-inclusion, relies on builder honesty.

    →
  3. 03

    Shielded settlement

    Medium CR, full privacy on amounts/counterparties post-inclusion.

    →

Open-source implementations