# \[Proposal\] Updated MEV Policy for Lido

**URL:** <https://research.lido.fi/t/proposal-updated-mev-policy-for-lido/12183>\
**Category:** Proposals\
**Created:** [November 4, 2026, 3:20pm UTC](https://research.lido.fi/t/proposal-updated-mev-policy-for-lido/12183 "2026-11-04T15:20:08Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Gabriella\_S](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/gabriella_s/32/5515_2.png) [@Gabriella\_S](https://research.lido.fi/u/Gabriella_S)\
**Post date:** [November 4, 2026, 3:20pm UTC](https://research.lido.fi/t/proposal-updated-mev-policy-for-lido/12183/1 "2026-11-04T15:20:08Z")

</div>

# **Executive summary**

Ethereum’s upcoming enshrined Proposer-Builder Separation (ePBS) introduces new ways for validators to participate in block-building markets. Most importantly, it enables builders to compete directly for block proposals, with payments guaranteed by the Ethereum protocol, reducing the need for trusted intermediaries.

This proposal seeks to preserve the principles of Lido’s existing MEV Policy while adapting it to ePBS: maximizing rewards for stakers, supporting open and competitive block-building markets, and ensuring that Node Operators (NOs) do not favor particular builders or withhold MEV rewards.

Following the discussion in [Lido’s call for an updated MEV policy](https://research.lido.fi/t/ethereum-mev-extraction-and-rewards-part-2-revisiting-stance-in-light-of-epbs/11818). It proposes a two-track approach: 1. An open, permissionless market where Lido validators can accept bids from any builder meeting Ethereum’s protocol requirements, provided payments are guaranteed by the protocol. 2. A vetted market where builders and intermediaries offering additional payments outside Ethereum’s guarantees must be approved through Lido’s Allowed List. Both tracks apply regardless of how a bid arrives: via p2p, a direct connection, or through one of the available sidecars.

APR is maximized as operators can source from the full market; MEV hiding remains detectable because every bid is signed and attributable; and the trust previously placed in relays (now builders) is either removed or explicitly scoped through regular governance.

This policy would remain mandatory for all NOs.

# **Disclosures**

I am a contributor to Lido’s Node Operator Mechanisms (NOM) workstream and authored the Part 2 post.  
This proposal draws on public feedback in the Part 2 thread and on conversations with client teams, builders, and relay operators. Thanks to the Commit-Boost, Stakely, and Titan teams for their detailed responses.

# **Table of contents**

- Executive summary
- Disclosures
- What ePBS changes for proposers
- Proposed policy
- Monitoring compliance
- Allowed List transition

# What ePBS changes for proposers

ePBS reduces reliance on trusted intermediaries. However, ePBS also supports additional payments that are not guaranteed by the protocol. These payments retain counterparty risks similar to those present in the existing MEV market. Changes to bid delivery, builder identification, and monitoring also require updates to the policy and its enforcement. This allows Lido to broaden builder participation, while preserving the current protections of the policy.

Here we highlight the six key points that inform this policy.

- A single bid can include two types of payment: a trustless `value`, owed once the proposer includes the bid, whether or not the builder reveals the payload, and a trusted `execution_payment`, settled outside the protocol.
- The transport determines the permitted payment types: bids sent over the p2p bidpool must be fully trustless (`execution_payment = 0`), while bids sent over a direct Builder API connection can combine trustless and trusted payments.
- Every bid is attributable: bids are signed by a registered builder index, and self-built blocks are easily identifiable.
- Relay registrations are replaced by a proposer’s stated preference: validators broadcast signed preferences for upcoming slots, specifying the fee recipient and gas limit. The trustless payment goes to the fee recipient named in the bid. If a validator broadcasts no preferences for a slot, it accepts no trustless bids for that slot.
- Bid handling moves into the beacon node: validator clients now expose top-level settings for p2p bids (`min_bid` and `builder_boost_factor`). Each direct connection has its own entry, with a URL, builder pubkeys, a trusted payment cap (`max_execution_payment`), a `min_bid`, and a boost factor.
- Sidecars such as Commit-Boost can continue to aggregate several relay and builder connections.

See [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732) and the [Gloas honest validator spec](https://ethereum.github.io/consensus-specs/specs/gloas/validator) for details on the mechanics.

# Proposed policy

Lido validators are expected to source blocks competitively, maximizing attributable rewards to the protocol without preferential treatment of particular builders, including those affiliated with their Node Operator, subject to legitimate operational and reliability constraints.

The proposed policy specifies how existing rules carry over to ePBS; with points 2 and 3 defining the new rules for the trusted and trustless tracks.

| | Trustless track | Trusted track |
| --- | --- | --- |
| Payment | Only protocol-enforced payments (`execution_payment = 0`) | Bids containing a trusted payment`execution_payment` |
| Transport | p2p bidpool, direct Builder API connection, or compatible sidecar | Direct Builder API connection or compatible sidecar |
| Eligible builders | Any builder meeting Ethereum’s in-protocol registration and collateral requirements (specified below) | Builders or relays approved on Lido’s Allowed List |
| Configuration | p2p: top-level client settings. Direct/sidecar: per-entry settings with `max_execution_payment = 0` | Per-entry settings with `max_execution_payment` \> 0 |
| Governance | No Lido-specific builder approval required | Approval and ongoing oversight through the Allowed List, vetted by the CMC |
| NO requirements | p2p bid reception must remain enabled on all nodes capable of proposing Lido blocks. NOs are responsible for builder registrations. | NOs configure as many entries as possible from the designated “must-use” list, and any number of entries from the general Allowed List. |

### 1. Reward distribution and fee recipient

All rewards attributable to Lido block proposals, including protocol-guaranteed and trusted builder payments, must be directed to the designated Lido EL Rewards Vault.

- Every Lido validator must broadcast signed proposer preferences for each upcoming proposal slot, with the Lido EL Rewards Vault as fee recipient.
- Any bid a Lido validator accepts must name the EL Rewards Vault as fee recipient. Both trustless and trusted payments must be delivered to the vault.

See [Lido on Ethereum Standard Node Operator Protocol – Block Proposals](https://github.com/lidofinance/documents-and-policies/blob/main/Lido%20on%20Ethereum%20Standard%20Node%20Operator%20Protocol%20%E2%80%93%20Block%20Proposals.md).

### 2. Trustless track

- All Lido validators must maintain access to the permissionless builder market introduced by ePBS.
- Operators may also use direct connections or compatible middleware to access this market., provided those entries are limited to trustless bids (`max_execution_payment = 0`)
- No additional approval from Lido is required for these builders. Any builder meeting protocol requirements can win a Lido slot through this track.

Trustless builders must meet several requirements:
- Registration: Register a BLS public key through the builder deposit contract
- Minimum stake: Deposit at least 1 ETH
- Activation: The deposit epoch must be finalized
- Valid signature: Sign bids with the registered builder key
- Payment coverage: Maintain sufficient available balance to cover the in-protocol bid
- Valid bid: Meet slot, parent, gas-limit, and other protocol requirements

- Top-level settings must not exclude p2p bids, except through a `min_bid` within community guidance (see point 4).

### 3. Trusted track

- Builders and intermediaries offering payments outside Ethereum’s protocol guarantees must be approved through Lido’s Allowed List.
- Thus, any winning bid containing a trusted payment from a builder not on the list would be flagged as potentially non-compliant with this policy.
- The list keeps its current structure: NOs configure at least one (but as many as possible) “must use some” entry, and any number of “may use” entries.
- Relays running an open auction remain the preferred entry type. Direct builder connections may also be approved, subject to appropriate assessment of reliability, transparency and payment practices (see “Allowed List transition”).

### 4. Local block building and min-bid

- Local building remains permitted, within values set by community consensus according to the [min-bid guidance thread](https://research.lido.fi/t/lido-node-operator-mev-boost-min-bid-guidance/3347). This applies to both p2p bids and individual builder or relay connections.
- The current guidance is maintained at ePBS activation. Because ePBS changes bid dynamics, the value should be reviewed once there is enough available mainnet data.
- NOs must not deliberately bypass competitive builder bids or favor locally built blocks where higher-value eligible bids are available.
- A self-built block where monitoring observed eligible external bids exceeding the configured min-bid is flagged for investigation under the existing outreach and escalation process.

### 5. Configuration consistency

- Every node that could serve a Lido proposal, including backup and failover nodes, must conform to the updated policy.
- DVT clusters must apply the same configuration across all cluster members, subject to their middleware’s ePBS support.

### 6. Builder failures

- Clients are developing circuit breakers that stop requesting bids from builders that fail to reveal a payload. These configurations are per-client and still changing, so this proposal leaves this intentionally open.
- NOs should maintain available client safeguards against builder failures (e.g. builder circuit breaker , builder-specific blacklisting, etc.) where available, and report incidents through the existing process.
- An allowlisted entry that fails to deliver a payload, or to honor a trusted payment, is handled under the existing incident process.

# Monitoring compliance

Because ePBS allows multiple valid paths for block delivery, it increases monitoring requirements for both Lido and the NOs.

| Check | What is observed | Flagged when |
| --- | --- | --- |
| Fee recipient | Fee-recipient addresses in signed proposer preferences and accepted bid | A Lido validator broadcasts a preference or accepts a bid specifying an address other than the EL Rewards Vault |
| Open track enabled / Participation in the permissionless builder market | Proposer preferences; client bid logs where available | Required proposer preferences are missing, or available evidence indicates that P2P bid reception was disabled |
| Payload source | Builder identity, payment fields and block-production method for each proposed block | A bid containing a trusted payment is accepted from a non-allowlisted builder, or a locally built block is proposed despite monitoring observing external bids above the applicable min-bid threshold |
| Trusted payment delivery | Trusted payment amount committed in the winning bid and corresponding receipts at the EL Rewards Vault | The expected trusted payment is not received in full within the applicable settlement period |
| Bid-value deviation | Value of the selected bid compared with the highest-value eligible bid observed by the monitoring system | The selected bid is below the configured percentage (initially 90–95%) of the highest-value eligible bid observed by monitoring |

Fee recipient violations will continue to be handled under the current process. Other new flags will follow the existing outreach and escalation path in Section E of the SNOP, and the [Fees Monitoring Dashboard](https://fees-monitoring.lido.fi/) will also be updated to show which track each Lido block came through.

# Allowed List transition

Existing Relay Allowed List entries may remain eligible following the ePBS transition, subject to demonstrating technical compatibility, identifiable builder participation and sufficient transparency for Lido monitoring., as long as they meet four conditions immediately following the fork:

1. Registered as an in-protocol builder, or relaying only for registered builders.
2. Published the builder pubkeys and indices they bid with and keep them current.
3. Ran an ePBS-compatible Builder API endpoint on Hoodi through the testnet fork.
4. Keep public bid and delivered-payload data that Lido monitoring can consume.

New applicants, including individual builders, will follow the [standard registration process](https://research.lido.fi/t/lido-on-ethereum-call-for-relay-providers/2844) and will be vetted by the Curated Module Committee (CMC) before addition to the new List.

The proposal and transition will be put to a vote in November, but implementation will only take effect following the Glamsterdam upgrade on Ethereum mainnet.