MEV stands for maximal extractable value: the value that can be captured by controlling the inclusion, exclusion, or ordering of transactions inside a block, on top of the standard block reward and gas fees. It is one of the most discussed and least understood parts of validator economics, partly because it sits at the intersection of markets, infrastructure, and protocol design. This post explains what MEV is, who captures it, why validators mostly access it through a marketplace rather than directly, and what the risks are - without promising any yield figure, because MEV income varies block by block and any single number would be misleading.
Start with a simple example. Suppose two trades on a decentralised exchange would move a token's price, and a third transaction could profit from that price move by trading in between them. The order of those three transactions inside a block decides who profits. Whoever builds the block decides the order, so block construction itself has value. That value is MEV, and it exists on any chain where transactions are visible before they are confirmed and where ordering affects outcomes. The classic forms are arbitrage between exchanges, liquidations on lending protocols, and sandwiching, where a trade is placed before and after a victim's trade to profit from its price impact.
The supply chain: searchers, builders, relays, proposers
Modern MEV on Ethereum flows through four roles, and understanding the split is the key to understanding the whole system. Searchers scan the pending transaction pool for profitable opportunities and package them into bundles of transactions. Builders take bundles and ordinary transactions, assemble them into complete candidate blocks, and bid for the right to have their block proposed. Relays sit between builders and proposers: they collect bids, check that blocks are valid, and pass the best bid along. Proposers are the validators themselves, who select a bid and sign the block header. The validator does not need to see the block's contents before choosing; it chooses on the bid value, and the full block is delivered after selection.
This division of labour has a name: proposer-builder separation, often shortened to PBS. The idea is that building a competitive block and proposing a block are different skills, and forcing every validator to be an expert block builder would push staking toward a few sophisticated operators. Separation lets a small validator access builder competition without running search infrastructure, which is why the current system is built around a marketplace rather than around each validator extracting MEV alone.
MEV-Boost: the middleware most validators use
MEV-Boost is the widely used middleware that implements this marketplace outside the Ethereum protocol itself. A validator running MEV-Boost connects to one or more relays, receives bids for each slot it proposes, and picks the highest valid bid. The relay is the trust layer in this design: the proposer trusts the relay to deliver the block it bid on, and the builder trusts the relay not to reveal its block before selection. That trust is the system's main weakness, and it is why protocol-level proposer-builder separation, often called enshrined PBS, is under development: moving the builder auction into the protocol would replace trusted relays with rules enforced by the chain itself. That work is still in progress, so for now the relay layer is the reality operators live with.
What MEV means for a small validator
For a validator operator, the honest summary is this: MEV-Boost is the default route to block-building revenue, and running it is a configuration decision, not a trading strategy. You do not need to write search bots or predict markets; you connect to relays, and the market comes to you. But you do need to make three decisions deliberately. First, which relays to trust, because relay choice affects which blocks you propose and whether you are exposed to transaction filtering. Second, whether to run a fallback that builds blocks locally if relays fail, because a relay outage at your proposal slot costs you that slot's revenue. Third, how to monitor the setup, because a silently broken MEV-Boost connection looks exactly like a healthy validator that is simply earning less - the failure mode the Grafana monitoring post and the Telegram alerts post on this blog are designed to catch.
The risks nobody should skip
MEV comes with risks that are easy to ignore while revenue looks good. Relay risk: a relay that fails to deliver a payload costs the proposer its slot, with no recourse in the current design. Filtering and censorship questions: relays differ in which transactions they include, and a validator's relay choice is therefore a policy choice as well as a revenue choice, so read each relay's stated policy before connecting. Centralisation risk: block building has concentrated among a small number of builders, which is the exact pressure PBS was designed to relieve at the validator layer, and it means the builder market deserves the same scrutiny as the validator set. And variance risk: MEV income is lumpy, with most blocks ordinary and a few unusually valuable, so budgeting as if every block pays the average is a planning mistake.
What MEV is not
Three misconceptions cause the most damage. MEV is not free money: it is value transferred from someone, often from traders whose transactions get sandwiched or from protocols whose liquidations get captured, and the ethics and user impact of that transfer are a live debate in the ecosystem. MEV is not a guaranteed yield: it depends on market activity, builder competition, and your own relay configuration, and it can fall sharply in quiet markets. And MEV is not something every chain handles the same way: other chains have different ordering rules, private transaction options, and sequencer models, so an Ethereum MEV playbook does not transfer automatically. If someone quotes you a single MEV return figure without a date range, a chain, and a relay configuration, treat it as marketing, not data.
For operators, the practical takeaway is modest and useful: understand the four roles, choose relays deliberately, run a local fallback, monitor the connection, and budget for variance. MEV is part of running a competitive validator today, but it is infrastructure work, not trading work, and the operators who treat it that way are the ones who keep earning through quiet markets as well as busy ones. If you want help configuring a validator with MEV-Boost, relays, and monitoring that catches silent failures, DevOpsBy's node operations service covers exactly that stack, and the free infra audit is the place to start.
Disclaimer: This post is educational only, not financial advice. Figures are listing or project data as of 2026-11-03 and may change - always confirm version numbers, requirements, and dates in the official docs before acting on them.