Spec has now been merged. Great thread on feature here for implementation by Lighthouse: https://x.com/sproulm_/status/1720604070207950883

@naviechan is looking into this

I guess there are couple questions that we want to answer before implementing it:

1. Should we give users the option (via a flag) to enable/disable proposer boost reorg feature?
2. If so, should it be enabled or disabled by default? imo, it should be enabled by default to contribute to the overall health of the protocol.
3. Since the spec doesn’t enforce the implementation of should_override_forkchoice_update() which is a collection of conditions that need to be satisfied in order to skip the late block, how closely should we follow the suggested implementation? Furthermore, any condition that should be added or removed on top of the suggested impl?

I guess there are couple questions that we want to answer before implementing it:

1. Should we give users the option (via a flag) to enable/disable proposer boost reorg feature?

According to their PR, it looks like it's on by default but there is a --disable-proposer-reorgs to turn it off. I think we should do something similar.

2. If so, should it be enabled or disabled by default? imo, it should be enabled by default to contribute to the overall health of the protocol.

Yes, on by default is my preference here to help with network health.

3. Since the spec doesn’t enforce the implementation of should_override_forkchoice_update() which is a collection of conditions that need to be satisfied in order to skip the late block, how closely should we follow the suggested implementation? Furthermore, any condition that should be added or removed on top of the suggested impl?

I would say we should try to match at least what Lighthouse is doing and the options they give, which is explained very well in their PR here: sigp/lighthouse#2860

Will let the team also chime in to see if there's anything else we can add to it.