Select highest-value bid in timing games, not most recent

[Danieldd28]

Summary

When timing games are enabled for a relay, handleTimingGamesGetHeader sends multiple getHeader requests over the course of the slot and picks the bid to use. Currently it picks the most recently received bid from that relay. This PR changes it to pick the highest-value bid received from that relay, with recency only used as a tiebreaker for equal values.

Motivation and Context

The relay's current best bid is not guaranteed to be monotonically increasing across polls within the same slot. A builder can cancel a previously leading bid, or a different builder can briefly be in the lead between polls. If the last poll happens to return a lower value than an earlier one, mev-boost currently discards the higher bid it already received and signed for, even though nothing requires that.

This gets more costly as bidding margins compress, see https://collective.flashbots.net/t/4734: median winning bid duration at Ultrasound dropped from over 80ms to 20ms, and the median competitive bid increment dropped from 0.47% to 0.09%. With margins and time windows that thin, discarding an already received higher bid for a lower one is a direct, avoidable loss to the proposer.

Before / after

Example: a relay's bid value across 3 timing games polls is 0.5 ETH, then 1.5 ETH, then 0.5 ETH (last poll regresses, e.g. due to a cancellation).

Before: returns 0.5 ETH, the bid from the last poll by timestamp.
After: returns 1.5 ETH, the highest value seen across all polls.

Also updated docs/timing-games.md to describe the new selection criteria.

References

https://collective.flashbots.net/t/4734 (margin compression context)
https://collective.flashbots.net/t/491 (unrealized value in mev-boost)

---

I have run these commands

• make lint
• make test-race
• go mod tidy

[Copilot]

Pull request overview

This PR updates mev-boost’s timing-games relay polling logic so that, within a single relay, the selected getHeader result is the highest-value bid observed across all polls (with recency used only as a tie-breaker), rather than always selecting the most recently received bid. This aligns timing-games behavior with the proposer’s objective (maximize bid value) even when relay responses are non-monotonic within a slot.

Changes:

• Change timing-games per-relay selection from “latest received” to “highest value” (ties broken by timestamp).
• Add a regression test ensuring an earlier higher bid is not displaced by a later lower bid.
• Update timing-games documentation to reflect the new selection criteria.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
server/get_header.go	Stores bid value per poll and selects the highest-value bid (recency tiebreak) instead of the latest bid.
server/service_test.go	Adds test coverage for non-monotonic bid sequences across timing-games polls.
docs/timing-games.md	Updates diagram/text to describe highest-value (recency tiebreak) selection within a relay.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.