Ethereum Glamsterdam & Hegota Fork Readiness Assessment

[techgangboss]

Overview

Glamsterdam (Gloas/Amsterdam) is targeting May-June 2026 mainnet activation and is currently in devnet-2. Hegota (Heze/Bogota) targets late 2026 and is in early scoping. This issue tracks all protocol changes that impact mev-commit and the action items needed to maintain compatibility.

The assessment covers the mev-commit monorepo (P2P node, oracle, bridge, CL, contracts), the mev-commit-geth fork, and the mev-commit-relay fork.

---

Glamsterdam EIPs

EIP-7732: Enshrined Proposer-Builder Separation (ePBS) — CL Headliner

Impact: CRITICAL — Core settlement infrastructure breaks

ePBS moves proposer-builder separation into the Ethereum protocol itself. Builders submit SignedExecutionPayloadHeader commitments directly in the BeaconBlockBody. Third-party MEV-Boost relays become architecturally unnecessary.

What breaks

1. Oracle L1Listener (oracle/pkg/l1Listener/l1Listener.go)

The oracle currently polls MEV-Boost relays at /relay/v1/data/bidtraces/proposer_payload_delivered every 2 seconds to determine which builder won each L1 block. It extracts builder_pubkey from the relay response and calls RecordL1Block(blockNumber, winnerBLSKey) on the BlockTracker contract.

With ePBS, builder identity is embedded in the beacon block body as a SignedExecutionPayloadHeader — the relay API may cease to exist or become non-canonical. The oracle needs to be rewritten to derive builder attribution from the beacon chain's ePBS data structures instead.

2. BlockTracker attribution (contracts/contracts/core/BlockTracker.sol)

recordL1Block(blockNumber, winnerBLSKey) depends on relay-sourced builder BLS keys. With ePBS, the builder's identity comes from the in-protocol SignedExecutionPayloadHeader. The BlockTracker's input data source changes fundamentally.

3. mev-commit-relay fork (primev/mev-commit-relay)

The forked relay filters blocks based on ValidatorOptInRouter to ensure only blocks from registered mev-commit providers are forwarded when a proposer is opted-in. With ePBS, the relay fork may become entirely irrelevant. The opt-in enforcement mechanism needs a new enforcement point — potentially an ePBS-native sidecar or a protocol-level filter.

4. Provider registration model

Providers register BLS keys in ProviderRegistry that map to relay-submitted builder pubkeys. With ePBS, builder identity is protocol-native. The BLS key mapping needs to align with ePBS's builder registration mechanism.

5. New validator duty

ePBS introduces "payload timeliness attestations" — a new duty for validators. The opt-in model and validator reward calculations may need to account for this additional responsibility.

Action items

• Prototype ePBS-native oracle attribution that reads builder identity from SignedExecutionPayloadHeader in the beacon block body (use Glamsterdam devnet-2)
• Design the migration path: dual-mode oracle that can read from both relays (pre-ePBS) and beacon chain (post-ePBS) during the transition
• Evaluate the mev-commit-relay fork — determine whether it should be deprecated or converted to an ePBS-native sidecar
• Update ValidatorOptInRouter enforcement to work at the protocol level rather than relay level
• Update ProviderRegistry BLS key semantics to align with ePBS builder registration
• Assess impact on provider commitment logic — builders interacting directly with proposers via ePBS changes the timing and trust model of preconfirmation commitments

---

EIP-7928: Block-Level Access Lists (BALs) — EL Headliner

Impact: MEDIUM — Dependency updates required, builder strategy changes

BALs add a new block_access_list_hash field to the block header. Blocks must declare all accounts and storage slots accessed during execution, enabling parallel transaction execution. Average overhead is ~70 KiB per block.

What to check

1. Oracle block parsing

The oracle fetches L1 blocks to verify transaction inclusion and position constraints. The new block header field changes the RLP encoding. If the go-ethereum dependency (currently v1.15.11) isn't updated to a Glamsterdam-compatible version, block deserialization will fail.

2. mev-commit-geth fork rebase

primev/mev-commit-geth has custom modifications (BLS verification precompile, zero-fee addresses, POA consensus). These need to be rebased on post-Glamsterdam upstream geth, which will include the BAL implementation. This is a non-trivial rebase given the custom precompiles.

3. Engine API version bump

The CL block builder (cl/blockbuilder/blockbuilder.go) currently uses Engine API V4 (engine_newPayloadV4, engine_forkchoiceUpdatedV3, engine_getPayloadV4). Glamsterdam will likely introduce V5 endpoints. The engine client (cl/ethclient/engineclient.go) needs new method implementations.

4. Builder strategy impact

Builders who commit to preconfirmations must now also construct valid BALs. This adds computational overhead to the commitment decision process and changes the economics of block building — more transactions per block become feasible with parallel execution, altering MEV extraction strategies and potentially increasing the value of preconfirmations.

Action items

• Track upstream go-ethereum for the Glamsterdam release and plan the dependency bump
• Plan the mev-commit-geth rebase — identify all custom patches and their compatibility with BAL changes
• Update the CL engine client to support Engine API V5 (or whatever version Glamsterdam uses) once specs are finalized
• Evaluate whether BAL construction overhead affects provider commitment latency and adjust commitmentDispatchWindow if needed

---

Gas Repricing Package (EIP-8007 meta)

Impact: LOW-MEDIUM — Configuration adjustments and bidAmount logic review

EIP-8007 is a meta-EIP organizing all Glamsterdam gas repricing proposals. The goal is to align gas costs with actual computational complexity, targeting a 60 Mgas/s floor. Key sub-EIPs:

EIP	Change
EIP-7904	General repricing of 18+ underperforming operations
EIP-2780	Reduce intrinsic transaction gas (currently 21,000)
EIP-7976	Increase calldata floor cost
EIP-7981	Increase access list cost
EIP-8038	State-access gas cost increase (SLOAD/SSTORE)
EIP-8037	State creation gas cost increase
EIP-7778	Block gas accounting without refunds

What to check

1. BN254 precompile gas costs

PreconfManager uses ecAdd (address 0x06) and ecMul for ZK proof verification of commitment openings. If alt_bn128 precompiles are repriced under EIP-7904, gas estimates for commitment opening transactions change. The oracle's gas limit settings may need adjustment.

2. State access repricing

BidderRegistry and ProviderRegistry perform heavy SLOAD/SSTORE operations for deposit/withdrawal/staking flows. EIP-8038 (state-access gas cost increase) makes these operations more expensive. Gas limit estimates in the oracle and P2P node need updating.

3. Intrinsic gas reduction (EIP-2780)

Lower base transaction cost could benefit mev-commit chain throughput if the chain adopts the same repricing. For L1 interactions, it marginally reduces the cost of oracle settlement transactions and bridge operations.

4. Bidder nodes and FastRPC bidAmount logic

Important: The gas repricing package changes the cost of many EVM operations. Bidder nodes and FastRPC need to review and potentially update their bidAmount calculation logic. If the cost of executing a preconfirmed transaction changes due to repricing (cheaper intrinsic gas, more expensive state access, etc.), the expected MEV and therefore optimal bid amounts shift. The decay parameters (decayStartTimestamp, decayEndTimestamp) and slashAmt calculations may also need recalibration against the new gas economics.

Specifically:

• Bid profitability calculations that factor in gas costs need updated gas estimates
• FastRPC's backrun simulation and MEV estimation must use the new gas schedule
• If a preconfirmed transaction's execution cost changes, the margin between MEV extracted and bid amount changes
• Builders receiving bids also need updated simulation with new gas costs to accurately assess commitment profitability

Action items

• Audit all contract operations against the new gas schedule once EIP-8007 sub-EIPs are finalized
• Update DefaultGasLimit, DefaultGasTipCap, DefaultGasFeeCap in the P2P node options
• Update oracle gas estimates for RecordL1Block and ProcessBuilderCommitmentForBlockNumber calls
• Review and update bidder node bidAmount calculation logic against the new gas economics
• Review and update FastRPC MEV estimation and backrun simulation to use the post-Glamsterdam gas schedule
• Test settlement transactions on Glamsterdam devnets to verify gas estimates

---

Hegota EIPs (Late 2026)

EIP-7805: FOCIL (Fork-Choice Enforced Inclusion Lists) — CL Headliner

Impact: MEDIUM-HIGH — Protocol-level changes to commitment model

FOCIL uses a committee of validators (not a single proposer) to construct inclusion lists of transactions that must be included in blocks. The fork-choice rule enforces compliance. This is the most controversial Hegota proposal due to legal implications for validators.

What this means for mev-commit

1. Constrains builder discretion

Builders currently have full control over block content when issuing preconfirmation commitments. With FOCIL, certain transactions must be included regardless of builder preference. A provider who commits to a specific block layout may find that FOCIL forces inclusion of additional transactions, potentially displacing committed transactions or changing position constraints.

2. Slashing risk for providers

If a provider commits to a preconfirmation but FOCIL-mandated inclusions make that commitment impossible to fulfill (e.g., the block is too full after required inclusions), the provider faces slashing through no fault of their own. The oracle's settlement logic needs to understand FOCIL-forced inclusions when evaluating commitment fulfillment.

3. Changes MEV dynamics

FOCIL reduces censorship-based MEV extraction. Revenue from excluding/delaying transactions decreases. This could reduce overall bid volumes for certain use cases while making inclusion-based preconfirmations more predictable.

Action items (begin when Hegota specs stabilize)

• Analyze how FOCIL inclusion lists interact with preconfirmation commitments — can a provider check the inclusion list before committing?
• Design oracle settlement logic that accounts for FOCIL-forced inclusions when evaluating commitment breaches
• Evaluate whether the bid structure needs a FOCIL-awareness field or whether providers should factor inclusion list constraints into their commitment decisions
• Assess impact on mev-commit bid volume and provider economics

---

Current Readiness Status

Component	Pectra (Live)	Fusaka (Live)	Glamsterdam	Hegota
go-ethereum dep (v1.15.11)	✅	✅	❌ Needs bump	❌
Engine API (V4)	✅	✅	❌ Needs V5+	❌
mev-commit-geth fork	✅	✅	❌ Needs rebase	❌
Oracle (relay-based attribution)	✅	✅	❌ Breaks with ePBS	❌
mev-commit-relay fork	✅	✅	❌ May be deprecated	❌
Smart contracts (Solidity 0.8.26)	✅	✅	⚠️ Gas audit needed	❌ FOCIL changes
Epoch/timing (12s slots, 32 slots/epoch)	✅	✅	✅ No changes	✅
EIP-7702 (setcode)	✅	✅	✅	✅
Testnet (Hoodi)	✅	✅	⚠️ Need devnet-2	—
Bidder/FastRPC bid logic	✅	✅	⚠️ Gas repricing	⚠️ FOCIL

---

Improvement Opportunities

1. Prepare ePBS Migration Path (Urgent)

Even before ePBS, the oracle's relay dependency is fragile — relay operators can change APIs, go offline, or return inconsistent data. The relay API (/relay/v1/data/bidtraces/proposer_payload_delivered) is not a protocol-guaranteed interface.

Recommendation: Start building an alternative builder attribution path that reads from the beacon chain directly. With EIP-7732, the BeaconBlockBody will contain SignedExecutionPayloadHeader with the builder's identity. A dual-mode oracle (relay + beacon chain) would provide resilience now and a migration path for ePBS.

Steps:

1. Stand up a Glamsterdam devnet-2 node
2. Prototype beacon chain-native builder attribution (read SignedExecutionPayloadHeader from the beacon API)
3. Implement dual-mode oracle: try beacon chain first, fall back to relay
4. Run both paths in parallel on testnet to verify consistency
5. Deprecate relay path once ePBS is live on mainnet

2. Leverage Deterministic Proposer Lookahead (EIP-7917, Live Now)

EIP-7917 (shipped in Fusaka) pre-calculates a deterministic proposer schedule in the beacon state at every epoch start. This is directly useful for preconfirmation protocols.

Current state: The P2P node connects to a BeaconAPIURL and the epoch calculator (x/epoch/epoch.go) computes timing. The node already queries proposer duties.

Opportunities:

• Longer-horizon preconfirmations: With a deterministic proposer schedule, mev-commit can offer preconfirmations for blocks further into the future with higher confidence. Providers can commit earlier when they know the proposer is opted-in.
• Pre-qualification of proposers: Before a bidder submits a bid, the system can check whether the upcoming proposer(s) are opted-in via ValidatorOptInRouter. If no upcoming proposer is opted-in, the bid has no value — don't send it.
• Improved ProposerNotifyOffset: The configurable offset in the node options can be tuned more precisely now that the proposer schedule is guaranteed-accurate. This could reduce wasted network traffic and improve commitment timing.
• Bidder UX: Surface proposer opt-in status for upcoming slots in the bidder API so bidders can make informed decisions about when to bid.

Action items

• Verify the P2P node is reading from the EIP-7917 deterministic proposer schedule (not the older, non-deterministic beacon API endpoint)
• Add pre-qualification logic: check upcoming proposer opt-in status before propagating bids
• Tune ProposerNotifyOffset based on deterministic schedule accuracy
• Expose upcoming opted-in proposer slots in the bidder API

---

Timeline

Priority	Action	Target
P0	Prototype ePBS-native oracle on devnet-2	Now (March 2026)
P0	Plan mev-commit-geth rebase strategy	Now
P1	Leverage EIP-7917 proposer lookahead	Q1 2026
P1	Audit contracts against gas repricing	When EIP-8007 sub-EIPs finalize
P1	Review bidder/FastRPC bidAmount logic for repricing	When EIP-8007 sub-EIPs finalize
P2	FOCIL compatibility analysis	When Hegota specs stabilize (Q3 2026)

---

References

• EIP-7773: Hardfork Meta - Glamsterdam
• EIP-7732: Enshrined Proposer-Builder Separation (ePBS)
• EIP-7928: Block-Level Access Lists
• EIP-8007: Glamsterdam Gas Repricings
• EIP-7805: FOCIL
• EIP-7917: Deterministic Proposer Lookahead
• Ansgar's Glamsterdam EL PFI'd EIPs (categorized)
• Conduit: Glamsterdam EIPs Guide
• Base Blog: Glamsterdam Proposals
• Blockworks: Ethereum Refactors for Glamsterdam

[techgangboss]

Execution Client Update (primev/erigon)

Status: Low risk — no immediate action required.

The mev-commit chain runs on a fork of Erigon (primev/erigon, branch primev/patches), based on Erigon v3.0.5. The fork has only 4 functional modifications:

1. Fee routing to coinbase — all fees (tip + base + blob) to coinbase instead of burn; zero-fee addresses get refunds
2. Zero-fee address whitelist — --zerofee.tx.list CLI flag
3. BLS precompile at 0xF0 — custom BLS12-381 signature verification (cloudflare/circl, Prague activation, 50k+5/byte gas)
4. Txpool empty block fix — prevents blocking when external CL produces empty blocks

All Glamsterdam features (EIP-7928 BALs, EIP-8007 gas repricing, Engine API V5, new opcodes) will come with the upstream Erigon rebase — no custom implementation needed. The rebase itself is straightforward given the minimal 8-commit diff. The main conflict point will be core/state_transition.go (fee routing patch).

ePBS (EIP-7732) does not affect the sidechain execution client — that impact is entirely on the oracle side (covered above in this issue).

Action

A full Erigon fork readiness assessment will be done when upstream Erigon ships their Glamsterdam-compatible release. Until then, the only pre-work is:

• Extract the 4 patches into documented, replayable diffs to make the rebase mechanical
• Resolve BLS precompile interface inconsistency between the legacy geth fork (primev/mev-commit-geth) and the active Erigon fork (primev/erigon) — different input formats, gas costs, and output formats at the same 0xF0 address

[techgangboss]

Oracle Builder Attribution: Deep Dive

How It Works Today

The oracle (oracle/pkg/l1Listener/l1Listener.go) determines the winning builder for each L1 block exclusively via MEV-Boost relay APIs:

1. Polls L1 every 2s, lagging 10 blocks behind tip (MEV_ORACLE_LAGGERD_MODE)
2. For each block, fans out concurrent GET requests to all configured relays:

   GET {relay_url}/relay/v1/data/bidtraces/proposer_payload_delivered?block_number={n}
   

3. Matches response on block_number AND block_hash — first relay match wins
4. Extracts builder_pubkey (BLS key) from the relay response
5. Calls BlockTracker.recordL1Block(blockNum, blsKey) → resolves BLS key to EOA via ProviderRegistry.getEoaFromBLSKey()
6. Fallback: If no relay returns a match → logs "out of PBS block", records address(0) as winner → no commitments for that block are settled (neither slashed nor rewarded)

Default relays: Aestus, Titan, Bloxroute Max Profit, Flashbots, Bloxroute Regulated (MEV_ORACLE_RELAY_URLS)

Can Builder Identity Be Derived Without Relays Today?

No — not with cryptographic certainty. Every alternative is heuristic and spoofable:

Method	In block?	Reliable?	Problem
extra_data (execution header, 32 bytes)	Yes	No	Voluntary, trivially spoofable. Codebase has blockBuilderNameToAddress in BlockTracker but not used in main oracle flow
fee_recipient / coinbase	Yes	No	Set to the proposer's address, not the builder's. Builder pays proposer via the last tx
Beacon block body	Yes	No	Contains proposer_index only. No builder field in the consensus protocol
Beacon graffiti	Yes	No	Set by the proposer/validator, not the builder

The relay API is the only authoritative source today. The relay verified the builder's BLS signature before forwarding the block to the proposer — that's the chain of trust.

Post-ePBS (EIP-7732): Builder Attribution Becomes Protocol-Native

Under ePBS, builders become staked, first-class protocol entities with a 0x03 withdrawal prefix and a persistent builder_index in the beacon state:

class Builder(Container):
    pubkey: BLSPubkey
    version: uint8
    execution_address: ExecutionAddress
    balance: Gwei
    deposit_epoch: Epoch
    withdrawable_epoch: Epoch

The BeaconBlockBody replaces ExecutionPayload with SignedExecutionPayloadBid:

class ExecutionPayloadBid(Container):
    parent_block_hash: Hash32
    parent_block_root: Root
    block_hash: Hash32
    builder_index: BuilderIndex      # ← BUILDER IDENTITY
    slot: Slot
    value: Gwei
    execution_payment: Gwei
    ...

The bid is BLS-signed by the builder — cryptographically authenticated, non-spoofable. Self-built blocks use builder_index == UINT64_MAX (BUILDER_INDEX_SELF_BUILD).

Post-ePBS oracle attribution (pseudocode):

builder_index = beacon_block.body.signed_execution_payload_bid.message.builder_index

if builder_index == UINT64_MAX:
    # Proposer self-built, no external builder → equivalent to "out of PBS block"
else:
    builder = beacon_state.validators[builder_index]
    builder_pubkey = builder.pubkey
    builder_address = builder.withdrawal_credentials[12:]  # last 20 bytes

Available via standard beacon chain APIs. No relay dependency.

Migration Path

Phase	Attribution Source	Relay Dependency
Now → pre-Glamsterdam	Relay API (builder_pubkey from bidtraces)	Required
Post-Glamsterdam (transition)	Beacon chain primary (builder_index), relay fallback	Optional
Steady state	Beacon chain only	Eliminated

Oracle Action Items (updated)

• Pre-ePBS (now): No relay-free alternative exists. Current architecture is correct.
• Pre-ePBS (resilience): Consider adding extra_data heuristic as a secondary signal for monitoring/alerting (not settlement), to detect relay downtime vs actual out-of-PBS blocks
• Post-ePBS: Rewrite L1Listener to read builder_index from beacon block body via beacon API (/eth/v2/beacon/blocks/{slot}), then look up builder pubkey/address from beacon state
• Post-ePBS: Update BlockTracker.recordL1Block() to accept builder_index in addition to or instead of BLS key — the ePBS builder_index maps to a pubkey in the beacon state, not the relay-registered BLS key. The ProviderRegistry BLS key mapping needs to align with ePBS builder registration.
• Post-ePBS: Handle BUILDER_INDEX_SELF_BUILD (UINT64_MAX) — equivalent to current "out of PBS block" behavior
• Transition: Implement dual-mode oracle that tries beacon chain first, falls back to relay API during the overlap period
• Prototype on devnet: Use the epbs-devnet-0 infrastructure (ethpandaops) to prototype beacon chain-native attribution

References

• EIP-7732: Enshrined PBS
• Consensus Specs - Builder (ePBS)
• Flashbots Relay Specs
• Titan Builder: Builders and Relays in ePBS
• Strong Builder Identity (ethresear.ch)
• Beacon API Specification

[techgangboss]

Post-ePBS Oracle Strategy: Beacon-Only Attribution

Decision: Beacon chain primary, relay as short-term fallback only — then deprecate relays entirely.

Post-ePBS, every block built by an external builder will have builder_index in the beacon block body regardless of whether a relay was involved. The beacon path covers 100% of externally-built blocks. The relay path adds no data that the beacon path doesn't already provide.

The beacon chain source is also strictly superior in trust model — builder_index is cryptographically authenticated via BLS signature and enforced by the consensus protocol. Relay data is just a trusted API response from a third party.

Why relays become unnecessary for the oracle

• ePBS replaces the relay's core function (trusted intermediary) with protocol-level mechanisms: the Payload Timeliness Committee and unconditional builder payments at the consensus layer
• Builder identity is embedded in every beacon block body — no external API call needed
• Self-built blocks are explicitly flagged (BUILDER_INDEX_SELF_BUILD = UINT64_MAX), replacing the current heuristic of "not found in any relay = out of PBS block"
• Prysm has already indicated they won't maintain MEV-Boost compatibility post-ePBS

Rollout plan

Phase	Duration	Oracle behavior
Pre-fork	Now → Glamsterdam activation	Relay-only (current)
Transition	First ~2 weeks post-fork	Beacon chain primary, relay fallback for operational safety
Steady state	After transition stabilizes	Beacon-only, relay code deprecated and removed

No investment in long-term dual-mode maintenance — the relay path becomes dead code after transition.

[techgangboss]

5. Reference Implementation: ePBS Builder Bid Filtering (mev-commit-builder-filter)

Problem

Today, mev-commit-relay enforces a critical security invariant: only builders registered in ProviderRegistry (with sufficient stake) can win opted-in slots. The relay filters incoming bids by checking builder BLS keys against the on-chain registry before forwarding to proposers.

In ePBS (EIP-7732), builders submit SignedExecutionPayloadBids directly to the protocol — no relay in the path. Without a replacement for this filtering, non-registered builders without stake could win opted-in slots, voiding preconfirmation guarantees.

Solution: mev-commit-builder-filter Go Library

A Go package that validators import into their consensus client to filter ePBS bids. This is the primary integration path — minimal overhead, no extra processes, no external dependencies.

Core Components

1. Registry Sync Client

• Connects to mev-commit chain RPC
• Reads ProviderRegistry contract for registered builder BLS pubkeys + stake status
• Polls every epoch (~6.4 min) or subscribes to registry events (ProviderRegistered, ProviderDeregistered)
• Maintains in-memory set: map[BLSPubkey]RegistrationInfo

2. Builder Index Resolver

• Connects to local beacon node API
• Maps ePBS builder_index → BLS pubkey via beacon state (builders are staked entities in EIP-7732 with pubkey, execution_address, balance in the Builder container)
• Caches index→pubkey mappings (stable once assigned)
• Fetches on cache miss

3. Bid Filter Engine

• Resolves builder_index from incoming SignedExecutionPayloadBid → BLS pubkey
• Checks pubkey against registry set
• Returns accept/reject

// Core interface — validators hook this into their bid selection logic
type BidFilter interface {
    // IsEligible returns true if the builder at this index is registered 
    // in mev-commit ProviderRegistry with sufficient stake
    IsEligible(builderIndex uint64) (bool, error)
    
    // FilterBids returns only bids from registered builders
    FilterBids(bids []SignedExecutionPayloadBid) []SignedExecutionPayloadBid
}

// Config for the filter
type Config struct {
    MevCommitRPC   string        // mev-commit chain RPC endpoint
    BeaconAPI      string        // local beacon node API
    RegistryAddr   common.Address // ProviderRegistry contract address
    SyncInterval   time.Duration  // registry refresh interval (default: 1 epoch)
}

Integration Point

Validators add a few lines to their CL client's proposer bid selection:

filter, _ := mevcommitfilter.New(mevcommitfilter.Config{
    MevCommitRPC: "https://chainrpc.mev-commit.xyz",
    BeaconAPI:    "http://localhost:5052",
    RegistryAddr: common.HexToAddress("0x..."),
})

// In proposer's bid selection loop:
eligibleBids := filter.FilterBids(incomingBids)
// Select best bid from eligibleBids only

Optional: Commit-Boost Module

For validators already running Commit-Boost (v0.9.x, audited by Sigma Prime), the same core library can be wrapped as a Commit-Boost CommitModule. This provides the filtering as a single config line addition — no CL client changes needed. This is a convenience path, not a requirement.

Build Phases

Phase	What	When
Phase 1 (now)	Core library: registry sync + BidFilter interface + unit tests	Can start immediately — independent of ePBS client implementations
Phase 2 (ePBS devnets)	Builder index resolver (depends on CL client beacon API for builder_index → pubkey resolution) + integration tests	When any CL client ships ePBS devnet support
Phase 3 (optional)	Commit-Boost module wrapper	After Phase 2, for validators who prefer module-based integration

Open Dependencies

• ePBS beacon API: The exact endpoint to resolve builder_index → pubkey depends on CL client implementations of EIP-7732 (not yet shipped). The BidFilter interface is stable regardless — only the resolver internals will need updating.
• CL client bid selection hooks: Each CL client (Lighthouse, Prysm, Teku, Lodestar, Nimbus) exposes proposer bid selection differently. The Go library approach is the most portable — validators import it wherever their client handles bid ranking.

Enforcement Model (Post-ePBS)

Two complementary enforcement layers replace the relay's current role:

1. Proposer-side filtering (this library) — Opted-in validators only consider bids from registered builders. Prevents non-registered builders from winning opted-in slots.
2. Validator slashing (existing) — If an opted-in validator accepts a bid from a non-registered builder, they can be slashed via PreconfManager. This is the backstop that makes filtering economically enforceable even if a validator doesn't run the filter.

Together these provide the same security guarantee as the current relay filtering + slashing model, without requiring a centralized relay in the bid path.

[techgangboss]

Trustless Attribution & Post-ePBS Filtering Architecture

Following internal discussion, here's a refined approach that eliminates the oracle entirely for builder attribution and maintains relay-based filtering alongside newer enforcement points.

---

Builder Attribution: SSZ Proofs Against EIP-4788 Beacon Roots

Post-ePBS, builder identity is embedded in the beacon block body as SignedExecutionPayloadHeader at a known SSZ generalized index. EIP-4788 (live since Dencun) exposes parent beacon block roots in the EVM via the BEACON_ROOTS precompile (0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02).

This enables a fully trustless proof path:

beacon_root (EIP-4788, on L1)
  → SSZ Merkle proof through BeaconBlockBody
    → SignedExecutionPayloadHeader
      → builder_pubkey

How it works:

• A verifier contract validates the SSZ Merkle proof on-chain against the beacon root for a given slot
• BlockTracker.recordL1Block becomes permissionless — any party submits slot number + builder pubkey + proof, the contract verifies
• No trusted oracle needed. Any party can construct and submit proofs, incentivized by settlement rewards
• mev-commit chain needs access to L1 beacon roots via the bridge or by mirroring the BEACON_ROOTS precompile

Considerations:

• SSZ proof verification is SHA256-heavy (~15-20 tree levels) — gas cost is bounded but non-trivial
• EIP-4788 stores the parent beacon root, so proofs are available one slot behind — acceptable for settlement which already operates within a window
• The generalized index for the builder pubkey in the post-ePBS BeaconBlockBody needs to be pinned once the spec stabilizes

The oracle should be fully deprecated. Rather than keeping it as a speed layer, a clean break removes a trusted dependency and simplifies the architecture. The proof submission path is fast enough for settlement purposes, and removing the oracle eliminates an entire class of trust assumptions and operational overhead.

---

BLS Key Filtering: Three Concurrent Enforcement Points

Filtering — ensuring only blocks from registered mev-commit providers are accepted when a proposer is opted-in — is a real-time decision at block construction time and can't be solved with proofs. Three enforcement methods should operate concurrently:

1. Relay (existing, maintained)

The mev-commit-relay fork's ValidatorOptInRouter filtering remains a valid enforcement point. Many validators will continue using relays post-ePBS — relays may evolve into submission/routing layers even if they're no longer architecturally required for PBS. The relay fork should be maintained as an opt-in filtering method for validators who prefer this path. This is the lowest-friction option for existing mev-commit validators.

2. Commit-Boost sidecar (new, recommended)

A Commit-Boost module that intercepts builder submissions and checks ProviderRegistry / ValidatorOptInRouter before the proposer signs. Validators running mev-commit already run extra infra; a Commit-Boost module is incremental. This aligns with the ecosystem direction and works regardless of whether the validator uses a relay.

3. Consensus layer modification (new, tightest integration)

Embed the opt-in check directly in the mev-commit CL fork. The CL already has custom logic in cl/blockbuilder/ — extending it to filter based on provider registration status gives the tightest control and lowest latency. More invasive to maintain across upstream CL rebases but offers the strongest guarantees.

---

Target Architecture

Function	Current	Post-ePBS
Attribution (settlement)	Trusted oracle polling relay API	SSZ proof against EIP-4788 beacon root (trustless, permissionless)
Filtering (block production)	Relay fork only	Relay fork + Commit-Boost module + CL mod (concurrent)
Oracle	Required, trusted	Deprecated

Updated Action Items

• Spike: SSZ proof verifier contract — implement Merkle proof validation against BEACON_ROOTS for builder pubkey extraction
• Determine the SSZ generalized index for builder pubkey in post-ePBS BeaconBlockBody (track spec as it stabilizes on devnet-2)
• Design the bridge mechanism for L1 beacon roots to be accessible on mev-commit chain
• Implement permissionless BlockTracker.recordL1Block that accepts proof submissions instead of oracle calls
• Build Commit-Boost module for ValidatorOptInRouter / ProviderRegistry filtering
• Extend CL fork (cl/blockbuilder/) with provider registration filtering
• Maintain relay fork filtering as a concurrent method — update relay to work with ePBS submission flow if relay APIs evolve
• Plan oracle deprecation timeline: dual-mode during transition, full removal post-ePBS mainnet activation