MEV protection: where exactly order execution price is lost
Order execution price is lost not at the moment of the trade, but long before it. While a transaction waits to be included in a block, its contents are visible to network participants: order size, side, acceptable price slippage, and entry point.
That is enough to build a separate strategy around the client's order and extract profit before it executes. This extraction of value at the expense of someone else's order is called MEV, and MEV protection begins when the order stops being visible until execution.
Front-running trades is the simplest scenario: a third-party participant buys up liquidity at the current price, the client's order arrives in an already shifted order book, and it closes noticeably worse than expected.
Transaction reordering produces the same effect without direct interception — if an order is moved to the end of a block, the difference between the estimated and actual price turns from randomness into a constant.
The third source is failed transactions. In a competitive environment, several participants send similar transactions, one goes through, and the rest revert: the client pays for the attempt and gets no execution.
Partially filled orders make the picture worse — the remainder is filled at worse levels, and the final price slippage is made up of several episodes instead of one.
Across a flow, execution losses do not look one-off: they recur in every order and accumulate as a stable amount.
Next, we break down how this is closed architecturally — by routing outside the shared pending transaction pool, batch execution, and order state control at every step.
What managed order execution delivers in practice
The first measurable effect is the share of trades executed at the expected price. While an order goes through an open pool, between signing and inclusion in a block it can be reordered — this is MEV, value extraction from the transaction queue.
Managed order execution removes this gap: the route is calculated in advance, and deviation from the estimated price is recorded as a separate metric rather than found out after the fact.
The share of canceled trades changes in nature. Cancellation stops being an emergency scenario: an order does not go through if at execution time the price has moved beyond a set threshold — this is pre-described system behavior, not a failure.
Instead of a stream of "stuck" operations, a predictable trade cost appears: the participant knows the boundaries of the range within which the order will be executed.
Network activity spikes are a separate mode of operation. When competition for block space grows, the inclusion cost rises one-off, and without management an order either does not go through or executes at a worse price.
Resilience to activity spikes is provided by a priority channel and a time-limited queue: the order stays within a narrow range of conditions rather than chasing the market.
At the infrastructure level, this is a private order submission channel and an auction for the right to include, processed by Flashbots.
A side result is that the share of trades executed at the expected price stops being a random variable and becomes a parameter that can be measured and maintained.
These indicators are consolidated into one loop: share of executions at the expected price, share of cancellations by threshold, and delay until inclusion at load peaks. Such a set is visible in monitoring and can be compared before and after changes rather than estimated by eye.
MEV protection: comparison of order routing modes
The role of a routing mode is in who sees the order before it enters a block and who gets the right to execute it. This determines whether the profit from the price difference goes to an outside observer or stays in the strategy.
Below are working alternatives that are actually chosen between, with their applicability and limitations.
Comparison of modes
| Routing mode | When it fits | Limitations |
|---|---|---|
| Private submission channel | large orders sensitive to leakage into the public queue | a trusted intermediary is needed, some routes are not supported, order inclusion in a block is not guaranteed |
| Batch order processing | many small orders, high-frequency retail flow | delay until the next window, cross-batch arbitrage is possible, order cancellation becomes more complex |
| Execution auction | when competition for the right to execute and the best price are needed | a pool of market makers is required, some order parameters are disclosed, audit is more complex |
| Direct submission to the public queue | simple scenarios, low sensitivity to front-running | maximum exposure: front-running, sandwich attacks, price rollbacks |
In practice, modes are combined: large orders go through a private channel, the flow of small orders is collected into batches, and what is put up for auction is where competition gives the best price.
The limitations add up — therefore we fix the flow profile (share of large orders, sensitivity to delay, cancellation requirements) before choosing the scheme.
Implementation stages: from flow analysis to launch
Implementation of MEV protection starts not with code but with analysis of the real order flow: otherwise the protection covers the wrong area. Then comes the routing scheme, configuration, testing on past blocks, and controlled launch.
We do not reorder the stages: testing on history without a ready routing scheme shows nothing, and launching without it turns into debugging on live trades.
- Order flow audit. We map it out: which contracts sign the trade, through which nodes and relays the transaction goes, at what moment it becomes public, and who manages to see it.
- Routing scheme. We design the order's path until inclusion in a block: private submission, batch sending, priorities by trade type, behavior when a relay is unavailable.
- Configuration setup. We set batch size limits, disclosure delays, and escalation rules on the side of nodes and protection contracts.
- Historical data testing. We run past blocks through the new scheme and calculate how many trades would have executed openly and how the execution price would have changed.
- Controlled launch. We move part of the flow to the protected route, leave the rest on the previous one, and compare execution across both branches.
- Handover to operations. We deliver regulations, dashboards, and alerts, fix the procedure for changing parameters, and test rollback to the previous scheme.
What remains with the team: configurations, policies, regulations
A secure order execution system does not work "as configured at handover": its behavior is set by configurations and policies that then live in the customer's environment.
Along with the launched system, we hand over a full set of artifacts — so parameters can be changed by your own team rather than depending on the contractor for every edit.
- Access policies — rules for services, wallets, and external integrations: who initiates order execution and under what conditions.
- Operator roles — separation of duties between the on-call engineer, risk control, and configuration change rights, so that critical actions are not performed by one person.
- Routing schemes — logic for choosing the execution path, priorities between directions, volume limits, and conditions for stopping the flow.
- Environment configurations — separate sets of protection layer parameters for test and production environments, with change history and a clear rollback method.
- Response procedure — step-by-step order when metrics deviate from normal: who records it, who stops execution, who restores it, and how the cause is documented.
- System documentation — description of components, flow diagrams, list of failure points, and procedure for returning to the previous configuration.
- Observability — a set of measurements showing that MEV protection is operating normally, and rules for the on-call engineer to read them.
We hand over each artifact in editable form, not as a "as is" snapshot: configuration files with comments, routing schemes with branch points marked, checklists for the on-call shift.
We conduct the handover separately — we go through with your team which change is safe to apply immediately and which requires a run in the test environment. After that, parameter edits remain with you.
Case study: how execution losses were reduced severalfold
A liquidity provider with a flow of several thousand orders per day came with a non-obvious symptom: some trades executed at a price worse than expected, and the source was systematically not found. Logs were within tolerances, so the spread was attributed to market volatility.
Pre-implementation measurements showed a different picture: the share of trades at a price no worse than target held around 62%, and every ninth operation was canceled after submission.
What the order flow analysis showed
The spikes coincided in time: seconds before large orders, an abnormal flow of opposite orders appeared in the shared channel, and our trade went through at a shifted price.
We separately measured reaction time — when an anomaly was detected, the on-call engineer stopped execution manually, forty seconds or more. With such a gap, part of the price shift was already recorded irreversibly.
What was changed and what happened
Orders were moved from the shared channel to a private one, an auction operating on the Flashbots model was added, and execution was split into small portions with randomized output.
On top, a rule was set: if the price deviates from the expected one above the threshold and if there is a jump in opposite flow, the order does not go to the market automatically.
The share of trades at the expected price rose from 62% to 94%, cancellations dropped from 11% to 2%, and reaction to abnormal order flow became automated — a few seconds instead of forty-plus, without on-call involvement. Drawdown on an individual strategy stopped depending on who was on shift at that moment.
How private order submission differs from auctions
An auction and private submission solve one task — executing an order — but handle order data disclosure differently. In an auction, volume, direction, and limit price go to a circle of participants before the trade.
In private submission, the order is encrypted until settlement, and it is impossible to build a position against it in advance.
Private order submission works as follows: the client signs the order, encrypts the contents, and passes it to an intermediary with an obligation to execute it within a set window.
If not executed on time, the signature is voided, and there is nothing left to use to dispose of the order further. The risk of order leakage is fully removed: the payload is read only at the final settlement stage.
Execution auctions give something else — competition on price: participants bid for the right to execute the order, and the client gets a better rate. The price for this is the order's predictability for those trading against the flow.
The approach was introduced by Flashbots, and it works where there are many participants and orders are standard.
| Approach | When it fits | Limitations |
|---|---|---|
| Private submission | Large and rare orders sensitive to disclosure | Less competition on price, a trusted intermediary is needed |
| Auction with disclosure | Liquid pairs, dense participant flow | Order data is visible before the trade |
| Hybrid with staged disclosure | Both the best price and order confidentiality are needed | Takes longer, harder to maintain |
The choice between approaches is a calculation, not a matter of taste: the order's sensitivity to disclosure, the acceptable execution window, and the density of competing participants.
In practice, they are combined — an auction for liquid pairs, private submission for large orders where leakage costs more than a missed rate.
Engineers' questions: attacks, delays, and flow privacy
Engineering doubts before launch are almost always the same, and they concern not the choice of network but what happens to the order between the client's signature and inclusion in a block. Below are short answers to what most often comes up during environment approval.
How do you distinguish an execution attack from ordinary market noise?
We do not rely on a single heuristic but build a set of observable signs: price divergence between the moment of signing and actual execution, recurring executor addresses next to our orders, systematic front-running in time.
Each sign contributes to the assessment, and the threshold is configurable. False positives are separated by historical background — the detector is calibrated on real flow, not synthetic data.
We already have an execution environment deployed. Do we need to rebuild it entirely?
No. The private route is introduced gradually: first part of the flow goes through it, metrics are compared with the previous channel, and only then does the share increase.
Returning to the previous scheme is done by switching the route — without stopping trading and without data migration. Order integrity is controlled by an event log: signature, receipt time, execution fact.
Will order processing delays increase?
Flow privacy and speed are not mutually exclusive. Orders are collected into short windows synchronized with the expected block time so as not to wait an extra tick.
We measure the latency distribution, not the average: the upper percentile matters, because it determines execution quality in a sharp market.
We go through these points before launch, not after the first incident — this way the environment is assembled for your order flow from the start.Let's discuss the task and come back with an estimate and plan
So that the estimate and work plan are based on facts rather than guesses, we need inputs on the order flow: where orders come from, at what moment the transaction is formed, who signs it, and how the execution route is currently chosen.
From these answers, we see exactly where the order becomes visible before inclusion in a block and which parts of the flow need to be closed first.
Next, we analyze the current scheme for leaks: submission to the public mempool, retries on cancellation, behavior under network congestion and competing orders.
This forms the scope of work — not an abstract "we will implement protection", but a concrete set of changes in routing, submission, and trade confirmation.
On our side, we come back with:
- an order flow diagram with leakage points and control points marked;
- protection architecture options with each one's limitations and a recommendation for your order profile;
- scope of work by stages: preparation, changing submission, test environment, rollout to production;
- a work plan with stage order, dependencies, and points where your confirmation is needed;
- requirements for access, environments, and data needed to start the project;
- a rollback policy: how to restore previous behavior if metrics do not match;
- a list of acceptance metrics — share of orders processed without leakage and confirmation time.
Describe the task and send what you already have: submission logs, service diagram, statistics on failures and cancellations. We will come back with an estimate and work plan in the same form — with stages, timelines, and responsibility boundaries.