MEV-Boost Client Release Notes and Changelog

New MEV-Boost releases often depend on specific consensus client versions to support updated proposer registration or blinded block submission flows. An incompatible pairing can lead to missed proposals or, in rare cases, slashing conditions if the client fails to fall back to local block building correctly. Operators must cross-reference the MEV-Boost and Consensus Client Compatibility Matrix before any upgrade. A mismatch in the supported API version between the sidecar and the beacon node is a primary cause of post-upgrade outages.

Release notes frequently include changes to the profit-switching algorithm or the handling of the min-bid parameter. A new default behavior, such as a change in how late blocks are evaluated against the local execution payload, can directly alter a validator's revenue. Operators should test the new logic on a testnet to model the impact on their specific APY. A poorly tuned min-bid after an upgrade can cause a validator to reject profitable blocks or accept uncompetitive ones, undermining the economic purpose of running MEV-Boost.

A client release may implement a new relay API specification or deprecate an old endpoint. If a validator's configured relay list has not yet adopted the new specification, the upgraded MEV-Boost client will fail to fetch blocks from those relays, silently reducing the validator's effective relay set and potential revenue. Operators must verify that all relays in their curated list support the API version mandated by the new client release. This is a critical check before upgrading to a major version.

Upgrades can alter the sidecar's behavior during relay timeouts or connectivity failures. A change in the timeout duration or the logic for falling back to local block building can be the difference between a missed slot and a successful proposal during a relay outage. Operators should review the changelog for modifications to -relay-check, -request-timeout-getheader, or the circuit breaker logic. Validating these new failure modes in a controlled testnet environment is essential to ensure the updated fallback procedures align with the operator's risk tolerance.

New releases may introduce, rename, or deprecate Prometheus metrics that are critical for operational dashboards and alerting rules. An upgrade can break existing Grafana panels or silence vital alerts for relay connectivity and bid flow. Before deployment, the operations team must audit the release's metrics changelog and update their observability stack accordingly. A post-upgrade validation step should confirm that key metrics like mev_boost_get_header_request_duration_seconds are being correctly populated and visualized.

For validators operating under OFAC or similar sanctions compliance mandates, any change to the relay selection logic or the handling of censorship-resistant features must be scrutinized. A new client version could inadvertently alter how a validator connects to OFAC-compliant relays or processes blocks that exclude sanctioned transactions. A compliance architecture review is necessary to ensure the upgraded software continues to enforce the required legal filters without introducing new operational risks or causing unexpected missed slots.

Treat the official GitHub releases page as the primary version history for MEV-Boost. Review each release entry for fixes, new behavior, upgrade instructions, and references to relevant pull requests. Before rollout, compare the target release with the version currently deployed, identify changed command-line options or defaults, and verify release artifacts through any checksums or signatures published by the maintainers. Large validator fleets should promote releases through test, canary, and production stages rather than upgrading every sidecar simultaneously.

Use the upstream repository to inspect the implementation behind release-note summaries. The README documents supported operation patterns, while commits, pull requests, and tagged diffs expose changes that may affect relay requests, proposer registration, timeout handling, logging, metrics, or local block fallback. Operators maintaining custom containers or deployment wrappers should compare their build inputs against the selected tag and confirm that automation still passes supported arguments. Pin production builds to an explicit release rather than tracking the repository's default branch.

Check the repository's security advisories before approving an upgrade or continuing to run an older version. Advisories may contain affected-version ranges, remediation guidance, and disclosure details that are not prominent in ordinary release notes. Security and staking teams should map any affected range to their fleet inventory, prioritize exposed proposer hosts, and preserve relevant sidecar and consensus-client logs during remediation. Absence of a published advisory should not replace review of release notes, issues, and maintainer communications for operationally significant defects.

Consult the Ethereum builder specifications when a MEV-Boost release changes its interaction with consensus clients, relays, or fork-specific payload structures. These specifications define the interfaces used in the external block-building pipeline and are essential for separating a sidecar implementation change from a broader protocol compatibility requirement. Review the specification revision associated with the target release, then validate the complete combination of MEV-Boost, consensus client, execution client, relay endpoints, and active Ethereum fork in pre-production.

Use the relay API specifications to verify the request and response contracts that MEV-Boost expects from connected relays. Pay particular attention to proposer registration, header retrieval, blinded-block submission, error behavior, and fork-dependent data types. Relay operators and validator infrastructure teams should compare API changes with both their deployed MEV-Boost version and any internal proxies, allowlists, request instrumentation, or schema validators. Run compatibility tests against every configured relay because ecosystem adoption of an interface revision may not be simultaneous.