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 filtering and local/remote selection logic, which can alter which execution payload is proposed and associated MEV routing.

Overview
Per-builder min_bid and builder_boost_factor now apply when bids come from the Builder API, instead of always using the top-level BuilderConfig values.

RemoteBid carries an optional BuilderEntry (replacing builder URL only) so selection can resolve entry-level min_bid and builder_boost_factor, with P2P bids still falling back to the global config. Builder API bids are filtered against their entry min_bid, the best remote bid is chosen by boosted value (value × builder_boost_factor), and local-vs-remote comparison uses the winning remote bid’s boost factor. BidForBlock still exposes the builder URL by mapping from the entry when present.

^{Reviewed by Cursor Bugbot for commit b92f08b. 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.

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b92f08b. Configure here.}

[cursor]

Zero boost factor collapses remote ranking

Medium Severity

selectBestRemoteBid ranks remotes only by valueInGwei times builderBoostFactor. PREFER_EXECUTION is 0, so every such bid scores 0 and max returns an arbitrary winner. When the local payload is unavailable, that remote is used unconditionally, so a lower-value bid can be proposed.

 

^{Reviewed by Cursor Bugbot for commit b92f08b. Configure here.}

[StefanBratanov]

@tbenr I think this whole class needs a different approach, we can pass all remote bids to selectBestBidForBlock and do the boosted ranking there, however this makes the change slightly larger in that case

[tbenr]

ye that's an edgy thing. maybe we can return a pair of bids (best "raw" and best "boosted") so we can can consider the raw only during local -> remote fallback.

anyway latest changes seems to capture well the most common configuration. If that idea adds complexity (assuming is a good direction) we can add it in a followup PR

[StefanBratanov]

yeah in both cases, it's bit edgy, we can go with this for now, at least for testnets and readjust later

[tbenr]

LGTM