Why a Private Mempool Has Become a Baseline Requirement
A private mempool is a way to send a transaction around the public queue, where anyone can see its contents. In the normal mode, a signed transaction first enters an open waiting pool and remains there until it is included in a block.
Seconds, sometimes minutes, pass between sending and inclusion, and during all that time the transaction's composition, the amount, and the target contract can be read and analyzed.
The cost of this openness is that the queue is read not only by the recipient. Observers recognize large swaps and build their own transactions around them — a buy before yours and a sell immediately after.
This works as trade front-running: you execute at a worse price, and the difference is taken by whoever managed to get into the queue ahead of you.
The larger the volume, the further the actual price moves from the one you expected when signing, and protection against value extraction in public mode simply does not exist.
A private mempool closes this window. The transaction goes directly to whoever builds the block, bypassing open propagation: until the moment of inclusion, no one except the executor sees it.
Hidden transactions are revealed exactly when the block has already been built — reordering and inserting alongside is technically impossible because the contents became known too late.
The scheme has its conditions. A trusted route is needed: if the sending node leaks the contents, privacy is nullified.
There may be trade-offs in inclusion time and a risk that the chosen block builder will not accept the transaction — then a correct fallback to the regular channel without loss of funds is needed.
We break down how this is addressed at the level of routing, block-building rules, and access control for the transaction flow.
Measurable Effect of Protected Sending
Protected sending is measured not by a feeling of calm but by metrics visible in monitoring: the share of successful transactions, the spread of time to confirmation, and the deviation of the actual price from the calculated one.
The private mempool is a standard first implemented at scale by Flashbots, and its effect is calculated by comparing these metrics before and after.
Share of Failed Transactions
In the open pool, some trades fail because someone else's insertion lands before yours: the route shifts, and the price limit triggers.
When the order goes directly to validators, only failures related to the contract's own logic remain — the share of failed transactions drops severalfold, and it no longer needs to be factored into limit buffers.
Routing Losses
The difference between the price shown by the calculation and the one obtained on execution is paid by the sender in the open pool. Private sending reduces this gap to the route fee — there is no longer a premium for someone else's strategy in it.
Speed and Predictability of Confirmation
Overwriting a transaction with a higher fee for speed is needed less often: the order does not compete in the common queue, and the spread of time to inclusion in a block narrows. Planning operations by time becomes possible, rather than "as luck would have it."
Sending Stability and a Whole Class of Failures Gone
When the network is congested, the transaction does not get stuck and is not canceled en masse — sending remains predictable. A whole class of failures disappears: front-running, sandwiching, and disclosure of an unexecuted strategy before its publication.
Private Mempool: Comparison of Routing Approaches
Routing determines who will see the transaction signature before it is included in a block. As soon as it enters the public mempool, searcher bots manage to read it and rebuild the block in their favor — by inserting before or after.
Therefore, choosing a route is a trade-off between delivery speed, content privacy, and inclusion predictability.
| Routing Option | When It Fits | Limitations of the Approach |
|---|---|---|
| Direct via a trusted node | Regular transaction flow, predictable latency needed | The node sees the contents; its unavailability stops sending |
| Batch sending | High-volume operations: payouts, withdrawals, migrations | Waiting for the batch to accumulate; if it fails, the whole batch rolls back |
| Hybrid scheme | Mixed load, critical and background operations | More expensive to maintain: two paths, different retry and rollback rules |
In practice, the route is not fixed once and for all. Critical transactions are sent directly through a trusted node, background ones — in batches, and the hybrid scheme works as a foundation with switching when one of the paths degrades.
The decision is made based on metrics: first-attempt inclusion rate, delay to entering a block, and the share of transactions that still went to the public mempool.
The limitations are mutual: the higher the privacy, the fewer options there are to reroute on failure. Therefore, the configuration is assembled for the load profile, not according to the principle of "the most protected path for everyone."
Implementation Procedure for Protected Sending
The implementation procedure for protected sending is not installing a module but rebuilding the transaction path from signature to inclusion in a block.
Below are the stages we go through with the client's team: from auditing the sending scheme to handover to operations with procedures and metrics.
- Audit of the sending scheme. We collect how transactions are currently formed, signed, and broadcast: nodes, relays, wallets, who sees the signature before it enters a block. The result is a map of leak points and a list of operations vulnerable to front-running.
- Route design. We separate flows: which operations go through the private mempool, and which can be left public. For each route, we fix priority, waiting time for inclusion, and behavior when the channel is unavailable.
- Configuration of channels and access policies. Keys, endpoints, separation of permissions, isolation from the public pool, per-sender limits. Separately — resend rules so that the transaction does not "multiply" in both pools.
- Testing on a testnet. We run scenarios: the standard route, relay failure, a competing trade for the same asset, resending. We calculate the share of transactions that reached the target block with the expected order.
- Route validation on real data. We reproduce past trades and compare execution price before and after changing the sending scheme — the discrepancy shows where the route still leaks.
- Handover to operations. We hand over configurations, the route scheme, the incident response procedure, dashboards, and alerts. Plus the described fallback to the public path — in case the channel degrades.
Artifacts and Procedures You Receive
Implementing a private mempool is not only a running forwarding service but also a package of documents according to which the system lives after handover.
We fix the route configuration, roles and access rules, key rotation and failure analysis procedures, so that operations do not depend on a specific engineer. Below is the full list of implementation artifacts that remain with you.
- Route configurations — how a transaction enters the private channel, which nodes participate, where public broadcasting is disabled, and how the route rolls back.
- Flow diagrams — the path from client signature to inclusion in a block, with markers showing at which step and to whom the contents are disclosed.
- Access policies and roles — who sees the transaction body, who changes routes, who removes a node from the channel; access by the principle of least privilege.
- Operations procedure — a set of metrics (latency, failure rate, divergence from the public channel), on-call actions, and the threshold for moving the channel to backup mode.
- Procedures for rotating signing and access keys, including the order of revocation and replacement without stopping transaction intake.
- Integration documentation — request and response formats, error codes, call examples for your team.
- Incident analysis and rollback plan — configuration checkpoints, procedure for returning to public broadcasting, work completion criteria.
- Acceptance scenarios — checks confirming that transaction contents do not leak before inclusion in a block and that front-running trades do not intercept execution order.
Case Study: How We Eliminated Sandwich Attacks on Routing
The client was a liquidity aggregator that assembled a trade route across several pools. Orders went to the public mempool, where bots saw them before inclusion in a block and wrapped them in a sandwich bundle: a buy before the order, a sell after.
The share of front-run trades reached 11%, and unplanned losses consumed about 3% of the volume of each large route.
We moved execution into a private mempool: the order is not published in the open pool but goes directly to a block builder and is revealed only at the moment of inclusion.
The route is rebuilt according to the current state of the pools, not the state at the moment of sending — otherwise protection from front-running is traded for slippage.
We separately limited the share of the route that could be executed with one leg, so that partial disclosure would not give a bot a hook.
Metrics Before and After
| Metric | Before | After |
|---|---|---|
| Share of front-run trades | 11% | 0.4% |
| Unplanned losses on the route | ~3% of volume | 0.2% |
| Confirmation time | ~40 seconds | ~24 seconds |
Measurements were checked against public MEV activity measurements — discrepancies in the front-running share remained within observation error.
The result of the implementation: sandwich bundles stopped being a regular event, the reduction in losses holds across volume rather than looking like a one-off effect.
Confirmation time decreased because the order no longer waits for a bundle to form around it: the builder receives it immediately and includes it in the nearest block.
What to Do If a Transaction Has Already Entered the Public Queue?
As soon as a transaction has entered the public queue, its contents are seen by all nodes and observers, and anyone can intercept it before inclusion in a block.
The cost of a mistake is not only missed profit: the intention is disclosed, and protection built on concealment stops working.
Resending helps in one case: the transaction did not reach the network or its lifetime in the queue expired. If it is already in the mempool, resending changes nothing — the node sees a duplicate by signature and discards it, and confirmation times do not shift.
Something else works: routing the operation through a private mempool — a route in which the transaction does not enter public propagation.
Replacing a transaction follows the network rules, not the sender's wishes: the new version keeps the same account nonce and gives a noticeable fee increase, otherwise the node will reject it.
Below the threshold, the replacement is silently discarded, and you consider the operation accelerated while the old version quietly sits in the queue. Before replacement, we check through our own node that the original transaction has not yet been confirmed.
We assess residual risk honestly: the information has already leaked. Until a sufficient share of nodes has accepted the replacement, the old version remains valid and may enter a block first.
No one guarantees confirmation times, so we measure the window between detection and replacement in seconds.
The failure plan is written before the incident. It includes: which service signs and sends transactions, where notification of a stuck operation goes, what fee increase we consider the maximum, and after what timeout we rebuild the trade from scratch.
A separate item is how we verify against node logs so as not to send a second replacement on top of one already accepted.
Technical Concerns and Limitations of the Approach
A private mempool does not make a transaction invisible — it narrows the circle of those who see it before inclusion in a block.
The cost is trust in the private sending operator, services of the Flashbots Protect level: the node knows the contents of the call, the signature, and the sender's address.
The threat model shifts from front-running "in full public view" to the logging and access policy of a specific provider.
Compatibility is limited not by the contract but by the wallet and client. The contract receives a normal call with the usual gas and nonce, while the signing party chooses the route.
If an application, hardware wallet, or smart wallet cannot pass a transaction through to the private channel, it will go public — and the protection will not work.
Is this compatible with our contracts?
At the execution level — yes: the contract sees a standard call, and no separate support is needed. Exceptions are batch swaps, multicallers, and smart wallets with their own signing logic: there the route is set by the relay module, and it is checked separately.
What happens if the private route is unavailable?
Without a defined default behavior, the transaction hangs in the queue. We specify a timeout and fallback — resending through the public network with a higher fee; for time-sensitive operations, this is a mandatory failure scenario.
Who sees the data before confirmation?
The private sending operator and the block builders to whom the transaction is passed for inclusion. Concealment is not equal to anonymity: after entering a block, the address, amounts, and calls are public. We fix this boundary in the threat model before starting work.
Let's Discuss the Task and Come Back with an Estimate and Plan
For the estimate to be substantive and not approximate, we need a few inputs from you. They take one conversation and a couple of documents — that is enough to come back with a work plan and timelines, not general statements.
- Scenario: which transactions and for whom should remain invisible until the moment of inclusion in a block.
- Current environment: how the nodes are set up, who signs transactions, whether there is a separate test environment for checks.
- Constraints: internal policies, audit and compliance requirements, roles with key access.
- Target metrics: the share of transactions that bypass the public mempool and the acceptable time to inclusion.
- Responsible parties: who approves architecture decisions and who accepts the result at acceptance.
After the conversation, we send a package of documents that allows a decision to be made without additional clarifications — it immediately shows the scope of work, timelines, and the next step.
- Scope of work by stage with boundaries: what we do and what remains on your side.
- Timelines with checkpoints — when an intermediate result can be reviewed.
- Effort estimate and distribution by stage, with no hidden blocks.
- Risk matrix: what we do in case of a leak of transaction information or node failure.
- Rollback scheme to the public mempool without losing already sent transactions.
- Acceptance procedure: which checks confirm that the protection works.
The next step is a short, businesslike conversation: describe the task, and we will come back with an estimate and plan.