MEV strategies development for validators

Developing MEV Strategies for Validators

After Ethereum transitioned to Proof-of-Stake, MEV distinctions changed. Validators don't execute transactions — they only propose and attest to blocks. Actual transaction ordering and inclusion is delegated via PBS (Proposer-Builder Separation): builders construct blocks, proposers (validators) select the most profitable one. MEV for validators today is primarily about correct MEV-boost configuration and understanding when to reject proposed blocks.

MEV-Boost: Architecture and Risks

MEV-Boost is software that runs alongside a validator's consensus client (Lighthouse, Prysm, Teku). It implements the mev-boost relay protocol: validator requests blocks from multiple relays (Flashbots, BloXroute, Ultra Sound, Aestus, etc.), selects the maximum bid, signs blind header, receives full block body from relay, and publishes.

Validator → MEV-Boost → [Relay 1, Relay 2, ..., Relay N]
                              ↓
                         Builder auction
                              ↓
               Highest bidder's block → Validator signs

Relay Configuration

Connecting to more relays increases competition and bid. But not all relays are equal:

For maximum MEV income — connect to all available relays without OFAC filtering. For institutional validators with compliance requirements — regulated relays only. Income variance: 10–30% depending on period.

Bid Verification Before Signing

Critical issue: relay may offer a block with invalid payload or undervalued bid. MEV-boost checks minimum threshold (min-bid in ETH) below which validator builds locally:

# Run MEV-Boost with multiple relays and minimum bid
./mev-boost \
  -relay https://[email protected] \
  -relay https://[email protected] \
  -relay https://[email protected] \
  -min-bid 0.05 \
  -addr 0.0.0.0:18550

Timing Games

Advanced strategy for MEV maximization — late block proposals. Validator has full slot (12 seconds) to publish a block. If waiting until last 2–4 seconds, builder has time to include more MEV transactions from mempool (later arbitrages, more swaps). Risk: delay > T+9 seconds increases missed slot probability, costing more than late arrival gains.

Optimal timing depends on network conditions and infrastructure geography. Recommend own monitoring: log bid receipt time from each relay, block publication time, final block value.

Self-Managed MEV: Custom Builder

Large staking providers (Lido, EigenLayer operators, Coinbase) build custom builders for vertical integration of MEV. This makes sense from ~1000+ active validators.

Builder Architecture

Mempool monitoring → Transaction ordering → Block template → 
Simulation → Bid calculation → Submission to relay network

Simulation engine is the central component. Each bundled transaction must be simulated before inclusion: gas check, no-revert check, real profit calculation after gas:

type SimulationResult struct {
    Profit    *big.Int
    GasUsed   uint64
    Reverted  bool
    StateRoot common.Hash
}

func (b *Builder) simulateBundle(bundle *Bundle, state *state.StateDB) SimulationResult {
    snapshot := state.Snapshot()
    defer state.RevertToSnapshot(snapshot)
    
    totalGasUsed := uint64(0)
    totalProfit := new(big.Int)
    
    for _, tx := range bundle.Transactions {
        result, err := b.evm.Call(tx, state)
        if err != nil || result.Failed() {
            return SimulationResult{Reverted: true}
        }
        totalGasUsed += result.UsedGas
        // profit calculation from coinbase transfers and gas premium
    }
    
    return SimulationResult{
        Profit:   totalProfit,
        GasUsed:  totalGasUsed,
        Reverted: false,
    }
}

Transaction Ordering Strategies

MEVMAX ordering — greedy algorithm: sort transactions by effectiveFeePerGas descending. Simple and predictable, but not optimal with interdependent transactions (bundles).

Knapsack optimization — transactions with dependencies are treated as atomic groups. NP-hard in general case, solved via heuristics (greedy + beam search) for practical block sizes.

Bundle merging — two non-conflicting bundles can be included in one block. Conflict detection via state access lists (EIP-2930): if two bundles don't touch the same storage slots, they're independent.

Local MEV Strategies (Independent of Relay)

Arbitrage

Classic CEX-DEX arbitrage: price on Binance higher than on-chain Uniswap → buy on-chain, sell on CEX. Validator has natural advantage: can include own transactions in any block position without gas wars.

For validators: when finding arbitrage opportunity — include own arb bundle at block beginning without priority fee (gas savings).

Liquidation Capture

Aave, Compound, MakerDAO have positions becoming liquidatable when prices change. Monitor unhealthy positions:

async def monitor_aave_positions(web3: Web3) -> List[LiquidatablePosition]:
    # Get all active loans via Borrow events
    borrow_events = await get_all_borrow_events()
    
    liquidatable = []
    for position in borrow_events:
        account_data = await aave.functions.getUserAccountData(
            position.borrower
        ).call()
        
        health_factor = account_data[5]  # in wei (1e18 = 1.0)
        if health_factor < 10**18:  # < 1.0
            liquidatable.append(LiquidatablePosition(
                borrower=position.borrower,
                health_factor=health_factor / 10**18,
                max_debt_to_liquidate=account_data[1]
            ))
    
    return sorted(liquidatable, key=lambda p: p.health_factor)

Sandwich Prevention (Anti-MEV Service)

Alternative monetization for validators with large staking operations: offer private mempool for DEX users (for fee), guaranteeing sandwich attack protection. Essentially competitor to Flashbots Protect, but with guarantee of inclusion in specific validator's blocks.

Compliance and Risks

Since July 2023, OFAC sanction list applies to relays. Most large relays refuse to include transactions to/from sanctioned addresses (Tornado Cash). Validator using uncensored relays technically doesn't violate Ethereum protocol rules — censorship resistance is blockchain feature. But legal risk exists for regulated operators.

Missed slot decline: if MEV-boost block doesn't arrive on time (relay timeout), consensus client should automatically fall back to locally-built block. Critical setting: --local-block-value-boost 10 in Lighthouse — prefer local block if within 10% of MEV-boost bid (protects from relay downtime).

Metrics and Monitoring

Essential monitoring for MEV validator:

# Grafana dashboard metrics
- mevboost_bid_received_total: number of bids received per relay
- mevboost_bid_value_eth: bid values distribution  
- validator_block_value_eth: total income per block
- missed_slots_total: missed slots
- local_block_fallback_total: local block usage count

Comparing validator_block_value_eth to p50/p95 network-wide helps assess relay configuration quality. If median block value below network — relay latency or configuration issue.

Developing full MEV infrastructure for large staking operator (10k+ validators): 3–5 months. Basic MEV-Boost configuration with monitoring — 2–3 weeks.