production hybrid I2I + I2U
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.
CR
Medium
Censorship Resistance
O
Partial
Open Source
P
Partial
Privacy
S
Medium
Security
CROPS context
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.
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.
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.
Intent
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.
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.
Post-quantum
medium risk 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.
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.
Open-source implementations