Title: Private Transaction Broadcasting · Pattern · EthSystems

URL Source: https://original.es-internal.pages.dev/patterns/pattern-private-transaction-broadcasting/

Markdown Content:
---
description: 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.
title: Private Transaction Broadcasting · Pattern · EthSystems
image: https://original.es-internal.pages.dev/og.png
---

[Skip to content](#main-content) 

#### 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

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.

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.

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](../domains/post-quantum.md).

## 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

* [Flashbots Protect documentation](https://docs.flashbots.net/flashbots-protect/overview)
* [Flashbots MEV-Share documentation](https://docs.flashbots.net/flashbots-mev-share/overview)
* [Shutter Network documentation](https://docs.shutter.network/)
* [MEV Blocker](https://mevblocker.io/)

### Open-source implementations

* [ github.com Go MEV-Boost relay infrastructure used by the majority of Ethereum validators ↗ ](https://github.com/flashbots/mev-boost)
* [ github.com Go Threshold-encrypted mempool reference stack (production on Gnosis Chain) ↗ ](https://github.com/shutter-network/rolling-shutter)

CROPS profile

Censorship-resistance: mediumOpen source: partialPrivacy: partialSecurity: medium

CRCensorship-resistancemedium

Private relays can refuse individual transactions; censorship resistance depends on relay diversity and on a fallback path. Threshold-encrypted mempools reach `high` once a wide validator set enforces inclusion of encrypted payloads.

OSOpen sourcepartial

Core relay and threshold-decryption software is typically open source. Builder and relay operations often include proprietary orchestration and commercial MEV-capture logic.

PPrivacypartial

Content is hidden from public mempool observers until inclusion. A compromised relay or a threshold committee above the threshold can reveal content early. Sender address and gas payer are typically visible even during the pending phase.

SSecuritymedium

Relay-based variants rely on reputational and contractual enforcement. Threshold-encrypted variants rely on the honest-threshold assumption of the decryption committee and on timely decryption after inclusion.

#### Referenced by

building blocks10
* [FOCIL - Fork-Choice Enforced Inclusion Lists](/patterns/pattern-focil-eip7805/)
* [Mixnet Anonymity](/patterns/pattern-mixnet-anonymity/)
* [Network-Level Anonymity](/patterns/pattern-network-anonymity/)
* [Onion Routing](/patterns/pattern-onion-routing/)
* [Open Intents Framework (OIF)](/patterns/pattern-oif/)
* [Pre-trade Privacy (Encrypted Order Flow)](/patterns/pattern-pretrade-privacy-encryption/)
* [Private Intent-Based Vaults](/patterns/pattern-private-vaults/)
* [TEE-Assisted Network Anonymity](/patterns/pattern-tee-network-anonymity/)
* [Threshold-Encrypted Mempool](/patterns/pattern-threshold-encrypted-mempool/)
* [TLS Payment Bridge](/patterns/pattern-tls-payment-bridge/)
RFPs1
* [Private Reads / RPC Privacy](/rfps/rfp-private-reads/)

×

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://ethsystems.org/#organization","name":"EthSystems","url":"https://ethsystems.org/","logo":"https://ethsystems.org/icon-maskable.png","sameAs":["https://x.com/eth_systems","https://www.linkedin.com/company/ethsystems/","https://github.com/ethsystems"]},{"@type":"WebSite","@id":"https://ethsystems.org/#website","url":"https://ethsystems.org/","name":"EthSystems","publisher":{"@id":"https://ethsystems.org/#organization"}}]}
```