Use the configured min_bid and builder_boost_factor per builder

[StefanBratanov]

PR Description

Use the configured per builder min_bid and builder_boost_factor if builder is used when filtering remote bids and choosing local/remote bids.

Fixed Issue(s)

related to #11194

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

---

Note

Medium Risk
Changes block-production bid selection and thresholds; misconfigured per-builder values could reject valid bids or skew local vs builder choice, though P2P behavior is unchanged when no entry is attached.

Overview
Builder API bids now carry the full BuilderEntry on RemoteBid (replacing a URL-only optional), so bid selection can use per-builder settings instead of only top-level BuilderConfig.

Remote bid filtering applies a shared min_bid predicate: Builder API bids use the entry’s min_bid; P2P bids still use the global min_bid. Local vs remote comparison uses the entry’s builder_boost_factor when the winning remote bid came from the Builder API, otherwise the top-level factor. BidForBlock still exposes an optional builder URL, derived from the entry when present.

Tests cover entry-level min_bid filtering and entry builder_boost_factor overriding top-level config.

^{Reviewed by Cursor Bugbot for commit d8f3fe7. Bugbot is set up for automated code reviews on this repo. Configure here.}

[tbenr]

Seems a valid concern from gpt:

[P1] Apply per-builder boosts before choosing the remote candidate: ExecutionPayloadBidSelector.java:155. selectBestRemoteBid first picks the highest raw value, then only this bid’s factor is applied. For local=95, bid A=100 at 90%, and bid B=90 at 120%, it selects A and then local, although B’s boosted value is 108 and should win. Rank all eligible bids by overflow-safe boosted value and add a multi-builder test.

[StefanBratanov]

Seems a valid concern from gpt:

[P1] Apply per-builder boosts before choosing the remote candidate: ExecutionPayloadBidSelector.java:155. selectBestRemoteBid first picks the highest raw value, then only this bid’s factor is applied. For local=95, bid A=100 at 90%, and bid B=90 at 120%, it selects A and then local, although B’s boosted value is 108 and should win. Rank all eligible bids by overflow-safe boosted value and add a multi-builder test.

I am not sure about that on a second thought, if local bid is too small (most of the time), we are missing out on a larger bid potentially, if it has a lower builder_boost_factor, it's tricky to make it right. Should we raise an issue about it and look at it later?

[tbenr]

I am not sure about that on a second thought, if local bid is too small (most of the time), we are missing out on a larger bid potentially, if it has a lower builder_boost_factor, it's tricky to make it right. Should we raise an issue about it and look at it later?

We can definitely followup on that, but I'd apply the boost to all remote bids before comparing in this PR, otherwise the behaviour would be a bit strange. If even that is too complicated for this PR we can reconsider.