MEV Strategy for Institutional Ethereum Validators: Relay Selection, Compliance, and What Comes Next

Series: Validator Playbook | MEV Infrastructure

The Validator Playbook is P2P.org's infrastructure education series for institutional Ethereum operators. Each article addresses a specific operational, risk, or governance decision that validator infrastructure teams, staking product managers, ETF issuers, custodians, asset managers, and risk committees face when building or evaluating proof-of-stake infrastructure.

Previously in the series: How ETF Issuers Should Evaluate Validator Infrastructure: An Operational Guide

Learnings for Busy Readers

• MEV-Boost revenue typically adds 10 to 30% to staking rewards. On a 2.78% base APR, that translates to roughly 0.28 to 0.83% additional yield per validator. For institutional operators running thousands of validators, that difference is material.
• The MEV-Boost architecture splits the role of producing a block into four functions: searchers identify MEV opportunities, builders aggregate them into blocks, relays connect builders to validators, and validators propose the selected block to the chain. Validators sit at the end of that chain, not the beginning.
• Of the seven major MEV-Boost relays, only three do not censor according to OFAC compliance requirements. For regulated institutions, relay selection is a compliance decision, not just a yield decision.
• Running multiple relays simultaneously is standard practice. MEV-Boost compares bids across all connected relays and selects the highest-paying valid block for each slot.
• Approximately 88% of Ethereum blocks are currently assembled off-chain through MEV-Boost relays. Running without MEV-Boost means building blocks locally and forgoing the yield uplift from the builder marketplace entirely.
• Glamsterdam's EIP-7732 will move the proposer-builder separation mechanism into the Ethereum protocol itself, replacing the trust-based relay layer with in-protocol bids, commitments, and payments. The relay stack as it exists today has a defined end date.
• The MEV decision for institutional operators involves three distinct layers: the yield layer (relay selection and multi-relay configuration), the compliance layer (OFAC screening and transaction filtering), and the forward-planning layer (preparing for Glamsterdam's ePBS transition).

Why MEV Now Matters at the Institutional Level

Ethereum staking rewards come from two structurally different sources that carry different risk profiles and require different infrastructure decisions.

Consensus layer rewards are protocol-issued and relatively predictable. Validators earn them by attesting to the state of the chain, proposing blocks, and participating in sync committees. Execution layer rewards come from user priority fees and MEV at the time of block proposals. They are variable and market-driven. In Q1 2026, consensus layer rewards accounted for approximately 93% of total validator rewards, with execution layer rewards comprising the remaining 7%.

That 7% is not a rounding error for institutional operators. For institutional operators running thousands of validators, the MEV uplift is the difference between a profitable and marginal operation. The variability also matters: execution layer rewards spike during periods of elevated on-chain activity, including token launches, liquidation cascades, and major market events, and compress during quieter periods. Managing that variability through relay configuration is where institutional MEV strategy begins.

Before Pectra, an institution staking 2,048 ETH ran 64 separate validators, each with its own block proposal slot. Post-consolidation, that same position sits in a single validator. Each block proposal now represents a larger concentrated opportunity to capture execution layer rewards. Validator consolidation has made MEV-per-proposal more consequential, not less.

How the MEV-Boost Stack Works

Understanding the institutional decision requires understanding the architecture. The MEV-Boost proposer-builder separation architecture splits the role of producing a block into three separate functions: searchers identify MEV opportunities and submit bundles of transactions that capture them; builders aggregate searcher bundles and other transactions into proposed blocks; relays connect builders to proposers and provide the trust layer that allows proposers to commit to blocks they have not directly constructed.

MEV-Boost is a sidecar for the beacon node, a separate piece of open-source software, which queries and outsources block-building to a network of builders. Block builders prepare full blocks, optimizing for MEV extraction and fair distribution of rewards. They then submit their blocks to relays. Relays aggregate blocks from multiple builders to select the block with the highest fees. One instance of MEV-Boost can be configured by a validator to connect to multiple relays.

For institutional operators, three properties of this architecture are operationally significant.

First, the relay is a trusted intermediary. Validators commit to a block header before seeing the full block contents. They are trusting the relay not to manipulate or front-run the payload. The trust assumption sits entirely outside Ethereum's protocol rules, which is precisely what Glamsterdam's ePBS addresses.

Second, relay selection is the primary lever. Validators do not choose builders directly. They choose relays, and relays determine which builders they aggregate. The relay decision shapes both the yield profile and the compliance posture of the validator's block production.

Third, multi-relay configuration is the standard operating model. If connected to multiple relays, the validator's MEV-Boost software can compare bids and select the block header that will provide the highest value, increasing the overall staking reward for that block. Running a single relay concentrates both yield and operational risk on that relay's availability and performance.

The Compliance Dimension of Relay Selection

For institutional validators operating under regulatory obligations, relay selection carries a compliance dimension that yield calculations alone do not capture.

Of the seven major MEV-Boost relays, only three do not censor according to OFAC compliance requirements. The remaining relays apply transaction filtering based on OFAC sanctions lists, meaning they will not include transactions involving sanctioned addresses in the blocks they produce. For regulated institutions, using a non-OFAC-compliant relay can expose the validator to sanctions risk if a block they propose contains a transaction involving a sanctioned counterparty.

The compliance question involves two distinct considerations that institutions need to evaluate separately.

The first is sanctions exposure. Regulated institutions operating under US jurisdiction, or serving clients subject to US regulatory oversight, typically need to confirm that their block production infrastructure does not facilitate transactions with sanctioned addresses. OFAC-compliant relays address this by filtering their block payloads against the SDN list before forwarding bids to validators.

The second is censorship posture. OFAC-compliant relays filter transactions, which means they exclude certain transactions from blocks they produce. For institutions with clients or stakeholders concerned about Ethereum's censorship resistance properties, running OFAC-compliant relays exclusively carries a network-level implication beyond the institution's own compliance posture.

The practical resolution for most institutional operators is a multi-relay configuration that includes both OFAC-compliant and non-censoring relays, with MEV-Boost selecting the highest bid at the time of each block proposal. This approach maintains compliance coverage on most slots while preserving access to the full builder market when a non-censoring relay wins the bid.

Source: KuCoin

What Glamsterdam Changes for the MEV Stack

The MEV-Boost relay architecture is transitional infrastructure. Glamsterdam's enshrined Proposer-Builder Separation, EIP-7732, formally separates the job of the proposer from the builder and enshrines this hand-off directly into the protocol. Building the trustless exchange of a block payload for payment directly into the protocol removes the need for third-party middleware like MEV-Boost.

Under ePBS, builders cryptographically seal their blocks and commit to a bid. Validators select the highest bid without seeing transaction contents, and the block is only revealed after the commitment is locked in. The trust assumption that currently sits with the relay moves into the protocol itself.

Glamsterdam has been pushed back from the first half of 2026 to the fourth quarter of 2026. As of September 2026, the upgrade is in active testnet preparation. Glamsterdam is currently in the devnet phase, where client teams test the new rules on small coordinated networks. Public testnets like Sepolia and Hoodi will activate before mainnet.

For institutional operators, Glamsterdam's ePBS transition has three operational implications worth tracking now rather than at activation.

The relay dependency changes but does not disappear immediately. Builders and proposers might still choose to use off-protocol relays or middleware for complex features that are not yet part of the core protocol. The current relay infrastructure will likely operate in parallel with the new in-protocol mechanism during a transition period.

Compliance architecture needs to be reconsidered. Under the current MEV-Boost model, OFAC compliance is implemented at the relay layer. Under ePBS, the filtering logic will need to be remapped to the new in-protocol builder selection mechanism. Institutions that have built compliance programs around relay-level OFAC filtering will need to evaluate how those programs need to adapt.

Gas limit expansion affects execution layer reward dynamics. Glamsterdam will bring bigger blocks, moving from a gas limit of 60 million per block to a gas limit floor of 200 million per block. Whether that expansion increases execution layer rewards depends on how demand for blockspace responds to the increased supply. Institutions modeling execution layer yield projections for staking programs should treat Glamsterdam-era reward assumptions as uncertain until mainnet data is available.

Source: ethereum.org

The MEV Configuration Checklist for Institutional Operators

The following checklist covers the MEV infrastructure decisions that institutional validators need to have documented and actively managed.

Relay selection and configuration

[ ] MEV-Boost installed and running as a sidecar to the beacon node

[ ] Minimum bid threshold configured to ensure local block production fallback when no relay bid meets the floor

[ ] Multiple relays connected to maximize bid competition across slots

[ ] Relay list reviewed for OFAC compliance posture against the institution's regulatory obligations

[ ] Relay availability and performance monitored independently of MEV-Boost defaults

Compliance posture

[ ] OFAC-compliant relays confirmed in the active relay list for all validators operating under US regulatory jurisdiction

[ ] Transaction filtering policy documented and reviewed by compliance team

[ ] Censorship posture decision made explicitly and recorded: full OFAC filtering, partial filtering, or multi-relay with non-censoring fallback

[ ] Relay compliance posture reviewed on a defined schedule, as relay policies change

Operational resilience

[ ] Local block production fallback confirmed and tested: if all relays fail to return a valid bid, the validator must be able to build locally without downtime

[ ] Relay response time monitoring in place: slow relay responses can cause missed proposals

[ ] Client updates for MEV-Boost and beacon node coordinated to avoid version incompatibilities at upgrade boundaries

[ ] Glamsterdam client readiness on the infrastructure roadmap ahead of testnet activation

Reporting and audit trail

[ ] MEV revenue logged per validator per slot for reward attribution and NAV reconciliation

[ ] Relay source logged per block proposal for compliance audit trail

[ ] Execution layer reward variance documented for shareholder reporting and fund-level performance reconciliation

Key Takeaway

MEV-Boost is now standard infrastructure for institutional Ethereum validators. Approximately 88% of Ethereum blocks are assembled off-chain through MEV-Boost relays. Running without it means forgoing the execution layer yield uplift that the builder marketplace generates on every block proposal.

For custodians, asset managers, ETF and ETP issuers, exchanges, treasury teams, staking product managers, and risk committees, the MEV decision is not a single infrastructure choice. It is three parallel decisions: relay selection for yield maximization, relay compliance posture for regulatory alignment, and forward infrastructure planning for Glamsterdam's ePBS transition.

The institutions best positioned across all three have explicitly documented their relay configuration, aligned it with their compliance team's review of OFAC filtering requirements, and placed Glamsterdam client readiness on their infrastructure roadmap before the testnet activation schedule forces the conversation.

P2P.org's validator infrastructure runs MEV-Boost with OFAC-compliant relay configuration as standard across all client accounts. For institutional operators evaluating their MEV infrastructure, get in touch with our team.

Frequently Asked Questions (FAQ)

What is MEV and why does it matter for institutional Ethereum validators?

MEV stands for Maximal Extractable Value. It refers to the additional value that can be captured during block production by reordering, inserting, or excluding transactions within a block beyond the standard consensus layer rewards. On Ethereum, MEV flows primarily through the block builder marketplace: searchers identify profitable transaction ordering opportunities, builders incorporate them into blocks, and validators capture the value when they propose those blocks. In Q1 2026, execution layer rewards, including MEV accounted for approximately 7% of total validator rewards, with the consensus layer providing the remaining 93%. For institutional operators managing large validator sets, that 7% is a material component of total staking economics and needs to be actively managed rather than left to default configuration.

What is MEV-Boost and how does it work?

MEV-Boost is a sidecar for the beacon node, a separate piece of open source software which queries and outsources block-building to a network of builders. Block builders prepare full blocks optimizing for MEV extraction and fair distribution of rewards. They then submit their blocks to relays. Relays aggregate blocks from multiple builders in order to select the block with the highest fees. One instance of MEV-Boost can be configured by a validator to connect to multiple relays. The consensus layer client of a validator proposes the most profitable block received from MEV-Boost to the Ethereum network for attestation and block inclusion. Running MEV-Boost is effectively standard practice for institutional validators because the yield differential between MEV-Boost-enabled and local block production is consistently positive over time.

Why is relay selection a compliance decision for regulated institutions?

Not all relays treat transactions equally. Of the seven major MEV-Boost relays, only three do not censor according to OFAC compliance requirements. Relays that apply OFAC filtering exclude transactions involving sanctioned addresses from the blocks they produce. Regulated institutions operating under US jurisdiction, or serving clients subject to US regulatory oversight, need to confirm that their block production infrastructure does not facilitate transactions with sanctioned counterparties. Running a non-OFAC-compliant relay without explicit compliance team sign-off introduces sanctions exposure that cannot be managed after the fact, since the block is already on-chain by the time a sanctions issue would be detected.

What is the risk of running only one relay?

Relay concentration introduces two distinct risks. The first is yield concentration: if a single relay consistently loses bid competition against others, the validator systematically underperforms on execution layer rewards relative to a multi-relay configuration. The second is operational concentration: if the single relay experiences an outage, latency issue, or returns invalid bids, the validator either misses proposals or falls back to local block production without the execution layer uplift. Multi-relay configuration addresses both risks by distributing bid competition across multiple providers and providing operational redundancy if any individual relay fails.

What does Glamsterdam's EIP-7732 mean for the current MEV relay stack?

Glamsterdam's EIP-7732 moves the proposer-builder separation mechanism into the Ethereum protocol itself. Under ePBS, builders cryptographically seal their blocks and commit to a bid. Validators select the highest bid without seeing transaction contents, and the block is only revealed after the commitment is locked in. Building this trustless exchange directly into the protocol removes the need for third-party middleware like MEV-Boost. However, builders and proposers might still choose to use off-protocol relays or middleware for complex features not yet part of the core protocol. Glamsterdam has been pushed back to Q4 2026 and is currently in active testnet preparation. Institutions should treat current MEV-Boost relay configurations as operational through at least the first half of the 2026 mainnet transition period, while beginning to assess how their compliance architecture will need to adapt to the new in-protocol builder selection mechanism.

How should ETF issuers think about MEV revenue in fund reporting?

MEV revenue flows through the execution layer as part of block proposal rewards. For ETF products that distribute protocol-attributed participation rewards to shareholders, execution layer rewards, including MEV need to be included in the reward attribution methodology. The variability of MEV revenue complicates distribution modeling: execution layer rewards spike during high-activity periods and compress during quieter ones. ETF issuers building NAV calculation infrastructure for staking-enabled products should model execution layer reward variability as a range rather than a fixed assumption, and confirm with their fund administrator that the reporting infrastructure captures relay-source revenue per block proposal for audit trail purposes.

About P2P.org

Founded in 2018, P2P.org helps institutional capital protect digital asset yield across non-custodial staking infrastructure and curated DeFi strategies. With over $10B in assets secured and operating on 35+ proof-of-stake networks, P2P.org maintains a zero-slashing-incident track record, is trusted by over 190 institutional clients and is SOC 2 Type II attested and ISO/IEC 27001:2022 certified. To explore how P2P.org can support your institution's staking or DeFi infrastructure needs, get in touch with our team.

Disclaimer

This material is provided for informational purposes only and does not constitute investment, financial, legal, or tax advice. P2P.org accepts no liability for any actions taken based on it. Latency and performance figures referenced are estimates based on internal benchmarks and may vary depending on network conditions, geography, and client infrastructure. Past performance is not indicative of future results.