What Is MEV and Proposer-Builder Separation for Ethereum

What does MEV mean, and why should traders care?

MEV stands for maximal extractable value. It describes the profit that can be gained by controlling which transactions enter a block, the order in which they appear, and sometimes which transactions are left out. The term originally referred to miner extractable value, but Ethereum moved to proof of stake, or PoS, so maximal extractable value is now the broader definition.

That control matters because a blockchain is not just a list of transactions. It is also an ordered list. If one trade moves the price of a token on a decentralized exchange, or DEX, another trade placed immediately before or after it may become more profitable. A participant with access to pending transactions can compete to capture that opportunity.

For a regular user, MEV can look like a transaction that executes at a worse price than expected, a swap that fails after paying a fee, or a sudden rush of trading around a large order. Not every poor execution is MEV, and not every MEV strategy harms users. Arbitrage can bring prices between markets closer together. The important question is who captures the value, who pays the cost, and whether the process remains open to ordinary participants.

MEV is therefore better understood as an economic layer around block production, rather than as a single bot, company, or exploit. It affects traders, validators, staking services, protocols, and anyone who depends on transaction ordering.

What are the main MEV risks for ordinary users?

The clearest user-facing risk is a sandwich attack. A bot watches a pending DEX trade, places a purchase before it, allows the user trade to push the market price upward, and then sells after the user trade. The bot earns from the price movement while the victim receives a worse execution. Slippage limits can reduce the damage, but a loose limit may give the attacker more room.

Frontrunning is a wider term for acting before a known transaction to benefit from its expected effect. A bot may copy a profitable trade, compete for a liquidation, or bid for a scarce mint before the original transaction is processed. In public mempools, which are waiting areas where many transactions can be observed before inclusion, the information advantage can be significant.

There are several ways these strategies can fail or become costly. A user can pay network fees for a transaction that reverts, a bot can overbid other bots and lose money, and a DEX pool can move so quickly that the intended trade no longer works. Users also face malicious token contracts, fake trading interfaces, compromised wallets, and private-order-flow services that make promises they cannot verify.

MEV creates system-level risks too. If block construction becomes a race dominated by a few well-funded firms, smaller validators may depend on intermediaries to earn competitive rewards. A builder or relay can censor transactions, delay them, or refuse certain categories of activity. These are not theoretical concerns. After the United States Treasury sanctioned Tornado Cash in 2022, some Ethereum block builders and relays were criticized for excluding transactions connected to sanctioned addresses. That episode showed how compliance pressure can reach transaction ordering even when the base protocol itself does not enforce the exclusion.

Users should also distinguish protocol security from economic fairness. A block can be valid and finalized while its ordering gives sophisticated traders an advantage. MEV does not need to break consensus rules to extract value. The harm may instead appear as poorer execution, less predictable access, or a market structure where only specialized operators can compete.

How does MEV work on a DEX?

When a user submits an ordinary DEX swap, the transaction usually includes details such as the token pair, amount, maximum slippage, and a fee. Depending on the wallet and network conditions, the transaction may be visible to node operators, builders, or specialized searchers before it is included in a block. Searchers are automated traders that look for profitable transaction patterns.

Suppose a user wants to buy a large amount of a token from a liquidity pool. The pool uses an automated market maker, or AMM, that adjusts the price based on its token balances. The user's trade changes those balances and usually raises the token's price inside the pool. A searcher may buy first, causing the user to pay more, and sell afterward. The sequence is profitable only if the price impact and fees leave enough value after competition.

Arbitrage is another common form of MEV. If the same asset has different prices on two venues, a searcher can buy where it is cheaper and sell where it is more expensive. This can restore price alignment and may improve market quality over time. However, the profits can still come from users who create the price difference, and the competition to capture them can raise fees and concentrate infrastructure.

Liquidations create a different opportunity. Lending protocols often allow a third party to repay a borrower's debt when collateral falls below a required level. In exchange, the liquidator receives a reward or discounted collateral. Fast searchers compete to identify these positions and submit the transaction first. This can protect a protocol, but it can also produce intense fee auctions during a market crash.

Why transaction order matters

Ethereum transactions do not simply enter a block in the order users clicked a button. A proposer ultimately publishes a block, and the block's contents and ordering are selected through a market involving searchers, builders, relays, and the proposer. The proposer may receive a payment for selecting a block with valuable transaction ordering.

That payment is not necessarily a hidden theft from every user. Some value comes from arbitrage or protocol incentives that keep markets working. Still, the user may bear the cost through price impact, priority fees, failed transactions, or an execution price that is worse than expected. Calling MEV just arbitrage hides the more important issue: control over ordering can transfer value from less informed users to better-positioned operators.

What is proposer-builder separation?

Proposer-builder separation, or PBS, divides two jobs that can otherwise be performed by one validator. The proposer, usually the validator selected to propose the next Ethereum block, chooses a block and submits it to the network. The builder assembles that block by selecting and ordering transactions, often using bids from searchers and private order flow.

Under a specialized PBS arrangement, builders compete to create the most valuable valid block. They send a block proposal or block header through a relay, which acts as an intermediary that helps the proposer inspect the bid without necessarily revealing the complete block before selection. The proposer chooses the highest credible bid and publishes the corresponding block. The builder keeps the remaining value after paying the proposer and other participants.

On Ethereum today, MEV-Boost is a widely used piece of software that supports this separation for validators. It is middleware rather than the same thing as PBS built directly into the Ethereum consensus protocol. This distinction matters. MEV-Boost can coordinate an open market for block space, but it depends on participating validators, builders, and relays, as well as the assumptions made by the software and its operators.

Protocol-layer PBS, sometimes called enshrined PBS, would place more of these rules inside Ethereum's consensus design. It could define how builders bid, how commitments are verified, and how proposers select blocks without relying as heavily on external infrastructure. A protocol-level design could improve consistency, but it would also make difficult decisions about auctions, data availability, privacy, penalties, and censorship part of the base protocol.

What changes in the market?

Without a builder market, a validator that wants to maximize its reward may need to perform search, transaction ordering, block construction, and risk management itself. That favors operators with trading systems, low-latency connections, and specialist knowledge. PBS lets validators outsource block construction and compete for bids instead.

This can make MEV more transparent and competitive. Builders can combine many searchers' opportunities, compare bids, and pay validators for the right to propose a block. Validators can use a standard interface rather than building an entire trading operation. In theory, competition pushes more of the available value toward the proposer and reduces the advantage of running every part of the stack.

But separation changes who controls the process. The builder with the best access to order flow, capital, hardware, and reliable infrastructure may win more blocks. A market can be competitive at one level while still concentrating at another. PBS moves extraction into a market. It does not eliminate extraction or guarantee equal access to that market.

Does PBS make Ethereum fairer and safer?

PBS can solve some coordination problems without solving the underlying fairness problem. A builder market may improve validator revenue, reduce the need for each validator to become a professional block constructor, and make block value easier to compare. It may also help a proposer avoid accidentally selecting a low-value block when more valuable opportunities exist.

For users, the result is mixed. Better arbitrage can reduce price differences between venues. More organized block construction may make inclusion more reliable for some transactions. At the same time, sophisticated builders may gain better tools for identifying user trades, extracting liquidation value, or prioritizing private order flow. The user may not know which builder handled the transaction or how much value was generated around it.

Private order flow illustrates the trade-off. A wallet or application may send transactions directly to a builder or relay instead of broadcasting them in the public mempool. This can reduce exposure to public sandwich bots. It may also reduce transparency, limit which builders can compete, and give a small group more influence over which transactions are seen and included.

There are also technical failure modes. A relay can fail to reveal a promised block, a builder can submit an invalid or unavailable block, or software can expose a validator to unexpected behavior. Protocols can add safeguards, but every additional participant creates another trust, uptime, and governance question. A user should not assume that the label MEV protection means all forms of extraction or execution risk have disappeared.

What are the centralization and censorship concerns?

Block building benefits from scale. A large builder can spread infrastructure costs across many blocks, maintain connections to more searchers, negotiate more private order flow, and manage complex bidding systems. Those advantages may compound. If a few builders produce most of the valuable blocks, Ethereum can become more dependent on their continued participation.

Centralization can affect more than rewards. Builders may influence which applications receive priority, which transactions are delayed, and what types of activity are considered acceptable. Relays can become gatekeepers between builders and validators. Staking providers can also aggregate many users' ETH and make decisions on their behalf, increasing the importance of their policies and software choices.

Censorship does not require every validator to reject a transaction forever. Even temporary exclusion can matter for liquidations, arbitrage, governance votes, and time-sensitive transfers. A dominant builder might omit a transaction to comply with a legal request, avoid reputational risk, or favor a business relationship. If enough blocks follow the same policy, users may experience practical censorship even when another validator could eventually include the transaction.

The post-Tornado Cash debate made this trade-off visible. Some relays and builders excluded transactions associated with sanctioned addresses, while other participants continued to include them. The disagreement was not simply about whether sanctions should be followed. It was also about whether transaction-level compliance by infrastructure providers could weaken Ethereum's credible neutrality and censorship resistance.

Possible responses include multiple independent builders, diverse relays, open-source software, decentralized staking, privacy-preserving transaction submission, and protocol rules that limit abusive ordering. None is a complete fix. Privacy can reduce sandwich attacks while making order flow less auditable. Stronger protocol enforcement can reduce reliance on intermediaries while giving the protocol more authority over an economic market. The design challenge is to limit harmful extraction without making a small committee the final judge of acceptable transactions.

What should traders, stakers, and developers do?

Traders should start with execution controls rather than trying to predict every MEV strategy. Use a reputable wallet and DEX interface, check the trade route, set a sensible slippage limit, and avoid approving unlimited token spending when a smaller allowance is sufficient. A tight slippage setting can cause a trade to fail, but a very loose setting can make a sandwich attack more damaging. The right setting depends on liquidity, volatility, and the size of the order.

For large or time-sensitive trades, compare execution options and understand whether a service uses private transaction submission. Private routing may reduce public mempool exposure, but it introduces reliance on the provider and may not protect against every form of adverse ordering. Do not treat a protection label as a guarantee, and do not sign an unfamiliar transaction simply because it claims to prevent MEV.

Stakers should examine the software and services used by their validator. Ask whether the setup uses MEV-Boost, which relays are enabled, how missed blocks are handled, and what policies exist for censored or delayed transactions. Diversifying relays and avoiding unnecessary concentration can improve resilience, though each option involves operational and governance trade-offs.

Developers can reduce harm by designing transactions and interfaces that expose realistic slippage, avoid unnecessary public information, and account for adversarial ordering. Protocols should test liquidation and auction mechanisms under high competition, not only in calm conditions. Developers should also publish clear explanations of who receives MEV, how users are protected, and what happens when a builder, relay, or private-order-flow provider fails.

For everyone, the practical lesson is modest. You cannot see every participant in the ordering market, and you cannot infer safety from a successful transaction alone. Read execution data, compare the expected and received amounts, watch failed transaction patterns, and treat unexplained value loss as a reason to investigate rather than as a normal cost of crypto.

How to follow MEV and PBS without the hype

MEV and PBS change quickly because Ethereum governance, validator software, builder markets, wallets, and regulators all influence the outcome. Tracking each proposal, relay policy, builder share, and censorship incident manually is difficult. Zippfeed brings relevant MEV, Ethereum, and protocol headlines together with sentiment scoring marked bullish, neutral, or bearish and an importance rating, helping you separate a meaningful infrastructure change from routine market noise.

Use that signal as a starting point, not as a trading instruction. Read the underlying reporting, check who benefits from a proposed change, and ask whether a claimed improvement shifts risk to users, validators, builders, or another intermediary. That habit is more useful than assuming PBS has ended MEV, because the central question remains who controls transaction order and how accountable that control is.