Private Transaction Broadcasting

Hide transaction content from the public mempool before inclusion so that front-runners, sandwich bots, and competitors cannot observe or exploit pending trades. Transactions are routed through private relays or published as ciphertexts decrypted only after ordering, so adversaries see the transaction only once it is committed to a block.

Works best when

  • Transaction content must stay hidden from the public mempool until block inclusion to prevent MEV extraction.
  • Large institutional trades must not signal intent to competitors before settlement.
  • A block-inclusion latency overhead of tens to low hundreds of milliseconds is acceptable.

Avoid when

  • Public transparency of the pending transaction is required by policy or regulation.
  • Hard real-time inclusion guarantees are required and fallback to the public mempool is unacceptable.

I2I vs I2U — context differences

Institution to institution

I2I

Between institutions the relay or threshold committee can be contracted under SLA with diverse operators, audit logging, and an escalation path. Reputational and legal recourse bound the risk of a relay that peeks at or reorders transactions.

Institution to end user

I2U

For end users the relay or threshold committee is operated by parties the user cannot audit. Protection strength depends on cryptographic enforcement (threshold decryption) rather than reputation, and on the availability of a fallback path that does not silently leak the transaction to the public mempool.

Post-quantum exposure

Risk · medium
Vector
Threshold-encryption schemes built on pairings or elliptic-curve key agreement are broken by CRQC; recorded encrypted transactions face HNDL risk. Relay authentication channels typically use TLS with classical key exchange.
Mitigation
Migrate threshold-encryption and relay authentication to post-quantum primitives (lattice-based KEMs and signatures) as the ecosystem ships them. See Post-Quantum Threats.

Components

  • Private relay network that accepts signed transactions from users and forwards them to participating block builders under contractual or protocol rules.
  • Builder set that includes privately-routed transactions in blocks without republishing them to the public mempool.
  • Threshold decryption committee (for encrypted-mempool variants) that reveals transaction content only after the block containing it is committed.
  • Client-side encryption library for threshold-encrypted submissions.
  • RPC or wallet integration that routes traffic to the private endpoint with a configurable fallback policy.
  • Optional MEV-redistribution mechanism that returns part of any extracted value to the originator.

Protocol

  1. user Sign the transaction locally with standard tooling.
  2. user Submit the signed transaction to a private RPC endpoint instead of the public mempool.
  3. relayer Forward the transaction to participating block builders under the relay's operating rules.
  4. validator Include the transaction in a block without re-broadcasting to the public mempool.
  5. contract Execute the transaction; its content becomes visible only after on-chain inclusion.
  6. relayer Optionally return a share of extracted MEV to the originator via an MEV-sharing mechanism.

Guarantees & threat model

Guarantees:

  • Transaction content (target, value, calldata) is hidden from public mempool observers during the pending phase.
  • Front-running, sandwiching, and just-in-time-liquidity attacks based on pre-inclusion observation are prevented.
  • In the threshold-encrypted variant, ordering is committed before content is revealed, so ordering cannot depend on the plaintext.
  • Execution semantics are unchanged from direct submission; the pattern is a transport change, not an execution change.

Threat model:

  • In the relay variant: a colluding relay or builder can observe content; protection reduces to contractual and reputational enforcement.
  • In the threshold variant: a committee above the decryption threshold can reveal content before inclusion, defeating the guarantee.
  • Sender address and gas payer are typically visible during the pending phase.
  • A fallback to the public mempool on relay unavailability can silently leak the transaction; the fallback policy must be explicit.
  • Post-inclusion transaction details are fully public; this pattern does not provide shielded amounts or counterparties.

Trade-offs

  • Block-inclusion latency overhead in the tens to low hundreds of milliseconds, plus a decryption step for the threshold variant.
  • Inclusion priority depends on the relay's agreements with builders; private routes may see higher variance in inclusion time than direct builder submissions.
  • Relay coverage varies over time; users should monitor live coverage metrics rather than assume a fixed figure.
  • The threshold variant requires a decryption committee infrastructure and adds a liveness dependency.
  • Cost model varies: some relay services are free, others take a share of MEV or charge fees.

Example

  • A bank settles a large institutional stablecoin transfer by routing through a private relay so the transfer does not appear in any public mempool explorer. The block builder includes the transaction; competitors and MEV bots observe it only after confirmation.
  • A dealer wins an RFQ and submits the settlement transaction encrypted under a threshold key. Validators commit the ciphertext to a block. Only after inclusion does the committee publish decryption shares, after which the transaction executes. Competing dealers cannot front-run or copy-trade the order.

See also

Open-source implementations