A transaction that looks final the moment a desk signs it is nothing of the sort. Between signature and settlement it passes through several layers of infrastructure that most trading agreements never mention, and at each layer someone else has an economic incentive to look at it, delay it, or reorder it before it lands. For an execution desk moving size onchain, understanding that path, and what it costs, is a market-structure question, not a cryptography one.
What a signed transaction actually does before it settles
On Ethereum, a signed transaction that is broadcast normally does not go straight to whoever assembles the next block. It first reaches the public mempool, a shared, visible pool of pending transactions that any node, and any bot watching that node, can read. The transaction sits there, with its destination, size and price, until someone decides to include it. Ethereum's own developer documentation describes this stage plainly: since the move to proof of stake, validators control which transactions are included, excluded and ordered within a block, and that discretion is exactly what creates the opportunity. Visibility before finality is the root of the problem this piece covers, and nothing downstream fixes it unless it removes that visibility.
Searchers, builders and relays: the market between you and the block
Three specialised roles now sit between a broadcast transaction and its inclusion, at least on Ethereum's base layer. Searchers run algorithms that scan pending transactions and current chain state for profitable opportunities and submit their own transactions, or bundles of transactions, to capture them. Ethereum's documentation notes that searchers are willing to pay away most of what they capture, sometimes more than 90% of the revenue, as gas to whoever includes them, which is a useful measure of how competitive that layer is. Builders take bundles from searchers plus ordinary transactions and assemble complete blocks, bidding for the right to have that block proposed. Relays sit between builders and the validator who will propose the block, checking that a builder's bid is valid and that its data is available before passing it on, without exposing the block's contents to the proposer in advance.
How proposer-builder separation changed the picture
Before Ethereum's move to proof of stake, whoever produced a block also decided its contents, so extraction and proposing were the same job. Proposer-builder separation split that: validators now typically outsource block construction to specialised builders and pick the most valuable bid, via relays, without seeing what is inside until it is already committed. Ethereum's roadmap page frames this as doing three things at once. It makes censorship harder, because separating builders from proposers, with inclusion lists that let a proposer enforce inclusion, removes a builder's unilateral veto. It spreads MEV income across ordinary validators, including individual home stakers, rather than concentrating it with whoever runs the best extraction software. And it enables the data-heavy block production that further scaling needs, with specialised builders handling proof generation for large volumes of rollup data. In practice, most validators access this market through MEV-Boost, open-source middleware that Flashbots describes as letting validators reach a competitive block-building market and which, on Flashbots' own figure, can lift staking rewards by over 60% relative to building blocks unaided. That income comes from exactly the extraction described below. Separation does not stop it, it redistributes who captures it and adds a marketplace on top.
Where the value comes from
Maximal extractable value is, in Ethereum's own definition, the maximum value that can be extracted from block production in excess of the standard block reward and gas fees, by including, excluding and changing the order of transactions in a block. For an execution desk, the mechanisms that matter most are these.
Sandwiching and backrunning
A searcher watching the public mempool sees a large pending swap before it lands, buys ahead of it to push the price up, lets the original trade execute at the worse price, then sells immediately after. That is a sandwich. Backrunning is the softer cousin: the searcher does not touch the pending trade at all, but places a transaction immediately after it to capture a dislocation that trade itself created, such as a newly mispriced pool. Both depend entirely on the transaction being visible before it settles.
Liquidation races
The same visibility problem shows up in lending. When a borrower's collateral ratio crosses a protocol's threshold, the liquidation becomes a public, permissionless race, and whoever's transaction lands first captures the liquidation fee. Searchers compete on gas, and since proposer-builder separation on builder relationships too, to win that race. The risk compounds during system-wide stress, when liquidation volumes spike across venues at once, an effect we cover separately in our look at liquidity, leverage and market fragility. For a desk holding leveraged or collateralised positions, the point is that liquidation is not a neutral clock. It is an auction, sitting on top of the mechanics we set out in our explainer on where DeFi lending yield actually comes from.
This is not one design: it depends on the chain
None of the above is universal, and a desk trading across venues should not assume it transfers. Proposer-builder separation via MEV-Boost is an Ethereum base-layer arrangement. Ethereum's rollups do not run it. Arbitrum One's documentation describes a single logical sequencer that orders transactions itself, with a forced inclusion path on the parent chain that only becomes available after a delay measured in hours; OP Stack documentation states that the sequencer's mempool is private, unlike Ethereum's public one, which by its own account limits the MEV opportunities, while deposits submitted through the parent chain cannot be censored. That is a different trade-off entirely, sequencer discretion and forced-inclusion delay in place of an open builder auction, and one we set out in our explainer on Ethereum layer 2 rollups. Solana has no proposer-builder separation either. There the dominant MEV infrastructure is Jito's Block Engine, which runs parallel auctions on a 50-millisecond tick for placement of bundles, groups of at most five transactions that execute atomically or not at all, priced by tip per compute unit, with tips redistributed to validators and their stakers. It is a real, live extraction market, but a structurally different one: no relay layer, no separate builder role, and tips rather than block-level bids as the pricing mechanism. A desk comparing execution quality across Ethereum and Solana venues is comparing two market structures, not one design with different branding.
The mitigations, and what each gives up
Every response to this problem removes visibility, competition or speed from somewhere in the pipeline. None removes the cost for free.
Private relays and direct submission
Sending a transaction straight to a builder or a private relay, bypassing the public mempool entirely, is the most direct fix: nobody can sandwich what they never see. The cost is that the desk now trusts a smaller number of intermediaries with exactly the order information it was trying to hide, and those intermediaries are not accountable to the market-abuse rules a regulated venue answers to. It also does nothing about backrunning once the trade has settled and moved a price, or about liquidations, which have to become public at some point to be executed at all.
Batch auctions
CoW Protocol settles orders in batches, and where the same token pair is traded more than once in the same direction within a batch, those trades clear at the same price. CoW calls this a uniform directed clearing price, and its stated effect is to make transaction order irrelevant, so bots cannot reorder trades to extract a profit; orders that offset each other are matched peer to peer without touching onchain liquidity at all. What it does not remove is solver risk. By CoW's own description, the winning solver must provide at least the price in the user's signed intent and bears the risk of sourcing a valid settlement under those constraints, so a batch is only as good as the settlement a competing solver actually finds. A batch model is a real answer to sandwiching specifically, not to price risk generally.
Encrypted mempools
Encrypting a transaction until after ordering is committed removes the mempool as a place to read intent before execution. Shutter Network, which builds this technology, accepts in a July 2025 post that encrypted mempools are not a silver bullet for eliminating all malicious MEV. The specific limitations it was answering were raised by analysts at a16z crypto: a committee that decrypts transactions early would leave no public evidence of having done so, metadata such as size and gas can let a searcher guess intent even when the payload is hidden, and trade failures from exceeding slippage tolerance are likely to increase. Shutter disputes how severe each of these is and proposes mitigations rather than denying them, which is worth knowing when reading it: the exchange is a live technical argument between interested parties, not a settled account.
Intent-based routing
Rather than broadcasting a specific transaction, a desk states what outcome it wants and lets competing solvers work out how to deliver it, committing to a route only once one is found. This shares the batch model's logic of never exposing a specific transaction to the public mempool, but shifts execution risk onto whichever solver wins the order, and onto the desk's confidence that the solver set is genuinely competitive rather than a small, familiar group bidding softly against each other.
A market-structure concern researchers have raised
BIS staff raised the underlying issue as early as June 2022. In BIS Bulletin No 58, Raphael Auer, Jon Frost and Jose Maria Vidal Pastor wrote that these intermediaries can engage in activities that would be illegal in traditional markets, such as front-running and sandwich trades, described the result as an intrinsic shortcoming of pseudo-anonymous blockchains, and argued that addressing this form of market manipulation may call for new regulatory approaches to this new class of intermediaries. A BIS Bulletin carries the standard note that the views are the authors' and do not necessarily reflect those of the BIS or its member central banks. It is analysis, not a rule in force anywhere, and no regulator appears to have adopted binding MEV-specific rules on this point since, so it is best read as an early and still-unresolved concern rather than settled law.
The concentration that bulletin worried about has, if anything, sharpened. Relayscan, a public dashboard tracking MEV-Boost activity, showed on 18 September 2026 that a single builder, Titan, produced 55.2% of blocks over the preceding 24 hours, with BuilderNet at 19.3% and Quasar at 15.7% behind it. Relay share was more even, led by relay.ultrasound.money at 30.9%, bloxroute.regulated.blxrbdn.com at 28.3% and titanrelay.xyz at 27.5%. MEV Watch, which tracks how many blocks come from relays that filter sanctioned addresses, put that share at 30.5% of 13,765 blocks on 17 September 2026, almost all of it from one relay, and noted it was down 24% over the preceding 30 days. Neither figure is fixed, both dashboards update continuously, and both numbers can move sharply within weeks. The point for a desk is structural rather than the percentage on any given day: a handful of builders currently decide which transactions get through, and a meaningful minority of blocks pass through relays applying their own compliance filtering, a form of discretionary gatekeeping the base protocol was designed not to have.
Ethereum's protocol-level response is in progress rather than shipped. EIP-7732, Enshrined Proposer-Builder Separation, would move builder commitments and payment into the protocol itself instead of relying on relays as trusted intermediaries. It was created on 28 June 2024 and its status is still under peer review. Core developers selected it as the consensus-layer headliner for the Glamsterdam upgrade on All Core Developers Consensus call 162 in August 2025, and no mainnet date for that upgrade has been confirmed. Until it ships, relays remain what Flashbots' own documentation calls doubly-trusted components, trusted by builders for fair payload routing and by proposers for block validity, accuracy and data availability, with no protocol-level enforcement behind either promise.
What a desk should measure and ask
This is not tax, legal or investment advice, and nothing above is a recommendation to use, or avoid, any specific venue, relay or protocol.
Practically, a desk executing size onchain should be able to answer, for each venue it uses: whether its order ever touches a public mempool before settlement, and for how long; which relay or builder set its flow is routed through, and how concentrated that set is; whether execution price is measured against the price at signature or the price at inclusion, since MEV shows up precisely in that gap; and, for any lending position, what the liquidation mechanism pays a searcher to trigger, and at what threshold. A broker or venue offering MEV protection should be able to say which of sandwiching, backrunning or public visibility it addresses, because no single mitigation covers all three, and each buys that protection with a trade-off in trust, speed or price certainty that a desk should be able to name before it accepts it.