The price is right: Realigning proposer-builder incentives with predictive MEV-burn

[soispoke]

Thomas Thiery - February 12th, 2024

Thanks to Anders, Barnabé and Francesco for helpful comments and feedback on the draft.

tdlr: Just like in “The price is right”, predictive MEV-burn incentivises builders to predict the block’s full value at the observation deadline, without going over

MEV	Maximal Extractable Value
ePBS	enshrined Proposer-Builder Separation
EL	Execution Layer
CL	Consensus Layer

Introduction

MEV-burn is a consensus-level proposal to smooth and redistribute MEV rewards to ETH holders (i.e., ). In its most recent iteration, MEV-burn was presented as an ePBS add-on to mitigate the security and economic instabilities caused by the fluctuating and unpredictable nature of MEV rewards. As a topic of active research, MEV-burn pros and cons are currently being examined from both theoretical and empirical standpoints. These efforts have sparked new ideas and lively discussions (see comments in the aforementioned ethresear.ch posts) around designing incentive-compatible mechanisms that prevent collusion between builders and proposers to ensure MEV is efficiently captured and burned, not unfairly diverted. This post aims to (1) summarise vanilla and kickback MEV-burn key features and tradeoffs and (2) introduce pMEV-burn, and propose research directions that might be worth exploring.

MEV-burn recap

MEV-burn as a concept is an attempt to mitigate negative externalities caused by MEV from a protocol perspective. The spiky, unpredictable nature of MEV profits generated by block proposers has led to two main issues:

1. Economic instability: Proposers are rewarded not just from fulfilling their consensus duties but also from substantial execution layer MEV earnings. This dual revenue stream complicates the macroeconomic design of Ethereum (i.e., issuance curve), and leads to undesirable outcomes like “overpaying for security” and an increased validator count. At the microeconomic level, solo stakers also find themselves at a disadvantage compared to large staking pools, which have lower variance and are more likely to mutualise their profits.
2. Security threats: Large MEV spikes also give incentives to proposers to execute all kind of ”rugpool”, reorgs, and DoS **attacks (see Justin and Mike posts for more details) that can impact the protocol’s security and potentially lead to catastrophic events.

To mitigate these issues, MEV-burn borrows its core properties from EIP-1559: First, the protocol must become MEV-aware, and gain knowledge about the “contention” value generated from the EL. Once captured, the protocol must redistribute that value fairly amongst network participants. One way to redistribute that value equally to all ETH holders is to simply burn it. Notably, the recent Execution Tickets proposal also aims to curb the adverse effects of MEV, proposing to burn the entire cost of the tickets. This approach effectively removes MEV from staking revenue. However, we believe that further investigation into a live auction, single slot MEV-burn mechanism might still be warranted in this context. Such a mechanism could potentially (h/t Francesco):

• Increase the amount burned, thereby reducing the portion of the burn that is discounted to offset the risk associated with buying execution tickets (as execution tickets tend to capture a smaller fraction of MEV).
• Enhance censorship resistance by factoring in base fees as part of the criteria for block inclusion, rather than solely relying on priority fees.
• Diminish the likelihood of multi-block MEV by imposing additional constraints on the winning block for each slot.

With that in mind, let’s dive into vanilla MEV-burn (vMEV-burn) implementation details.

The step-by-step mechanism for vMEV-burn has already been described and illustrated elsewhere, but let’s go through it once more so we can settle notations and use it to describe improvement proposals that build on top of it:

1. During slot n-1, builders submit block headers alongside bids composed of (1) the bid’s base fee b_{BF}, which represents the amount of ETH that a block will burn and (2) the bid’s tip b_{tip} paid to the proposer (also in ETH).
2. N seconds before slot n boundary SB (usually N-2), referred to as the observation deadline D, validators on the attesting committee locally set a subjective Base Fee Floor (BFF) based on the highest b_{BF} they have observed so far.
3. At the beginning of slot n SB (around N = 0), the proposer set its BFF selects, signs and publishes the block header with the highest bid’s tip, conditioned on the b_{BF} being higher than their subjective BFF.
4. The N seconds between SB and D are meant to give attesters time to set their BFF so that later on, they can vote for the proposer’s block header if is valid, and matching its bid (i.e., the header chosen by the proposer).
5. If everything goes right, the selected block header starts gathering attestations and the builder releases the block payload containing the list of all transactions included in the block.
6. Attesters vote for the builder’s payload if valid and matching its bid b_{BF}.
7. If all is good, the b_{BF} is burned and the b_{tip} is paid to the proposer

vMEV-burn criticisms

vMEV-burn, by making sure the protocol can credibly capture and redistribute MEV, addresses both economic and security concerns. However, two aspects of the vMEV-burn design were challenged by astute observers (h/t jasalper, cometshock, ethdreamer and aelowsson) and correctly identified in Mike’s Dr. changestuff post:

• Collusion: If MEV-burn is implemented, all the juicy MEV will be burned and redistributed to all ETH holders. Surely there must be a way for us, hardworking builders and proposers, to capture some (all?) of that value instead? Turns out there is.

  • Builder-Builder collusion**:** If all builders cooperate and make sure the base fee floor never gets set above 0 ETH, builders can grief the proposer and share all the juicy MEV rewards between themselves. In the worst case scenario, all builders would have to play along, as a single defecting builder setting a bid BFF above 0 ETH would be enough to break the scheme. That’s a big if but it’s possible, since today [90.46%](https://mevboost.pics/) of blocks are built by the top five block builders. Other more realistic scenarios involve a top cartel of builders, who collude to bid just enough to beat the best bid from other builders outside of their cartel, which could lead to a large delta even with a BFF bid above 0 ETH. Another argument I haven’t seen too much is that the proposer could also choose to build a block locally, set the bid BFF above 0 ETH, and select its own block to make sure colluding builders have to outbid the BFF and can’t capture the whole MEV value. On this note, if participants were to behave honestly after ePBS and MEV-burn are implemented, local block builders would have to (1) subsidise their own bids’ BFF to remain competitive with other bids made by sophisticated builders or (2) decide not to build locally if the difference between their bid and the BFF is too high. It’s also important to note that while Builder-Builder collusion is possible today, and somewhat orthogonal to MEV-burn itself, enshrining a mechanism allowing collusion between builders in the protocol is different than accepting the current out-of-protocol tradeoffs. Finally, Builder-Builder collusion would easily be spotted, and griefing proposers or forcing their hands, knowing they’re the ones ultimately selecting the blocks that make it onchain, might not be strategically sound.

  • Proposer-Builder collusion: A similar, but slightly more elaborate collusion scheme involving all builders and the proposer can be set up. This time, colluding builders all agree to keep the bid BFF at 0 ETH and redirect the entire MEV value into the bid’s proposer tip b_{tip} (this can all be done via side channels as well). None of the value is burned by the protocol and redistributed to ETH holders, instead the proposer can keep some of the value (e.g., equal to the b_{tip} it would’ve collected under honest/normal conditions) and redistribute the rest of the value equally (or not) amongst colluding builders. This set up requires participation from more participants (the proposer has to be in on it too), but is potentially more sustainable and harder to detect if only part of the value is redirected to colluders via side channels. In the Builder-Builder case, builders are explicitly griefing proposers: this could lead to proposers just disconnecting from colluding builders and going back to local block building. In the Proposer-Builder case, both parties are involved, and play against the protocol. Another important point is that builders are not explicitly incentivised to bid before the observation deadline: A builder might want to place a bid right before the deadline, thus defecting from the collusion and winning one particular auction. But builders play in a repeated game, and in this case Proposer-Builder collusion is always worth doing for builders under quasi-perfect competition. Any value they can get away with by colluding will be higher than the close to zero profit margin they can make in a competitive landscape, given that the builder profit margin = actual value a builder can extract from its payload - (b_{BF} (burned) + b_{tip}).

• Late bidding: A separate, but related issue around late bidding behaviour from builders has also been raised. Even if builders don’t intentionally collude and form a “late-bidding cartel” (h/t to Anders for the cool name) to keep the bid BFF at 0 ETH, it turns out that a lot of MEV coming from CEX-DEX arbitrages grows over time in expectation, and is almost always captured during the last second of the slot. This raises valid concerns: if MEV-burn only captures value until SB -2, but significant value still goes to the proposer via the tip, we’re back to square one, and the mechanism isn’t efficient in doing what it’s supposed to. While Toni and Mike both presented interesting estimations of how much value would be burned vs tipped to the proposer based on historical data, it’s important to keep in mind that builders’ bidding behaviour will also evolve based on the incentives they’re presented with or external, unpredictable changes in MEV opportunities and market conditions.

• Observation deadline games: In the vMEV-burn proposal, at observation deadline D, validators on the attesting committee and the proposer locally sets their subjective BFF based on the highest b_{BF} they have observed so far. This means builders are expected to compete and raise their b_{BF} up to that point. The expected behaviour is to see builders raise their b_{tip} after D has passed, up until the slot boundary SB since we expect proposers to select the winning bid based on the highest tip, as long as the b_{BF} is higher than the BFF.

  • However, since there is no consensus on what the BFF value is (it’s set locally), builders and proposers will have to make probabilistic judgements when they observe bids made very close to D: “If I observe a bid at D + 0.5s with the highest b_{BF}, maybe the majority of attesters are better connected than I am, observed it at D, and will treat it as the BFF so my own b_{BF} has to match it?”. This means sophisticated, well-connected proposers will be able to bid more competitively than solo stakers, since they have more confidence regarding whether the b_{BF} they observed was seen by the rest of the network or not.
  • An attacker could also cause consensus instabilities by bidding at D with the highest b_{BF}, and b_{tip} = 0 so that no other builders can outbid it, hoping that the unsophisticated proposer will ignore the attacking bid (since b_{tip} = 0) and knowing that choosing any other bid will be invalid because it won’t meet the BFF requirements, thus causing an empty slot. Since there is no incentive for builders to bid before D in the vMEV-burn design, the cost of this attack could potentially be very low if the equilibrium strategy ends up being waiting after D to start bidding, and the BFF set by other builders is kept around 0 ETH.

kickback MEV-burn

In his recent post, Anders proposed a new mechanism, referred to as kickback MEV-burn (kMEV-burn) to incentivise builders to bid earlier than the observation deadline D. The changes are purely additive to the vMEV-burn design, and can be summarised as follows (focus on the purple writing and the in the figure below):

1. Same as in the vMEV-burn design, other steps that are strictly the same will be skipped
2. At step 2, attesters and the proposer not only set their subjective BFF based on the highest b_{BF} they have observed at D, but also remember the winning builder’s identity (i.e., its public key).

…

4. When attesters vote for the proposer’s selected block if its b_{BF} exceeds their BFF, they also vote TRUE in a separate vote if the winning builder’s identity is the same as the one that submitted the block selected by the proposer. Otherwise they vote FALSE.

…

7. In the end, if the majority of attesters in the slot vote TRUE, the winning builder receives a kickback x, which is a fraction of the winning block’s payload base fee wb_{BF} that otherwise would have been fully burned (e.g., x = 0.05 ).

The builder rewards R_{builder} are determined by the kickback x can be expressed as:

R_{builder}= x * wb_{BF}

They come in addition to the profits (or loss) the builder has made from the difference between the actual value the builder has extracted from wb_{BF} and the ( b_{BF} (burned) + b_{tip}). The proposed kMEV-burn changes are meant to address “late-bidding cartels” forming between builders by explicitly rewarding honest builders that compete to win the auction and set an accurate BFF before at the observation deadline D. Another aspect worth considering is that observation deadline games can still be played under the kMEV-burn design: an attacking builder can still trick proposers into selecting invalid bids raising the BFF right at D, but if other builders are incentivised to win the auction until D, the cost of the attacker would be significantly higher and might incur a loss if it ends up overbidding and being selected by the proposer.

kMEV-burn example scenarios

In this section, we hope to give an intuition on how builders could structure their bids at the observation deadline D and at the slot boundary SB under kMEV-burn by introducing example scenarios. The first one illustrates what a naive, conservative builder would do. We assume attesters’ local BFF is the same as the naive builder’s b_{BF} at D, and that the block chosen by proposer is the one that was built by the same builder:

2. At D, the naive builder observes a given block value, say of 1.2 ETH, and decides to set his b_{BF} to the full block’s value to increase its chances to set the BFF and be remembered by a majority of attesters.

…

7. After D has passed, the builder decides to redirect the additional block’s value to b_{tip}, that will be rewarded to the proposer.

1. If b_{BF} ≥ BFF and the block value is 1.4 ETH at SB, then b_{tip} = 0.2 ETH and b_{BF}=1.2 ETH. If x = 0.05, assuming the block chosen by the proposer was built by the same builder who set the BFF, rewards from the kickback mechanism can be computed as: 0.05 * 1.2 = 0.064 ETH

We can draw several observations from this first example:

• This example scenario assumes near-perfect competition: If a builder is convinced he has access to higher value than any other builder (e.g., because he has access to exclusive order flow), it will probably not bid its full value at D, and would rather bid the lowest value that’s above what other builders will be able to bid, according to his estimates.
• Kickback rewards determined by x have to be high enough so that builders are incentivised to use the mechanism, rather than keeping the difference between the block’s actual value and their b_{BF} for themselves.
• After D has passed, all the additional value captured in the last 2 seconds are redirected to the bid tip and goes to the proposer. This behaviour doesn’t seem to be rational, and we suggest sophisticated builders will either increase their b_{BF} **to get a higher kickback, or keep the excess value to themselves rather than giving it to proposers via b_{tip}.

Based on the last observation, we think builders will naturally tend to (1) bid up to the expected full block’s value in their b_{BF} at D to make sure it sets the highest BFF and (2) return little to no value to the proposer in their b_{tip}. This is an issue, because it means proposers won’t really have the option of selecting bids with the highest b_{tip}. Instead, they’ll be forced to choose the one bid that satisfies the BFF, even if that bid’s b_{tip} = 0. One way to deal with this is to let proposer rewards go to 0 or close to 0. After all, we might want proposers to only get compensated by CL rewards. We can also imagine builders would iterate over very low tips, (e.g., submit block at D with BFF = 10 and b_{tip} = 0, then send a block with BFF = 10 and b_{tip} = 0.00000001, etc…) and keep going until the end, ensuring their b_{tip} is high enough to lead and get selected by the proposer. Here’s an example of what it might look like if the builder is really good at predicting the future total MEV in a given slot:

2. At D, the predictive builder observes a given block value of 1.2 ETH, and decides to set his b_{BF} **based on its expected full block’s value at SB. In this example say the builder expects a full block value of 1.4 ETH , and bids b_{BF}=1.4 ETH and sets b_{tip} = 0 ETH.

…

7. Here, the predictive builder was perfectly accurate in its prediction. The full block’s value at SB is indeed 1.4 ETH. Its b_{BF} **was the highest at D so a majority of attesters set their local BFF to1.4 ETH and remembered the builder’s identity (voted TRUE ). In this case, b_{tip} =0 ETH, b_{BF}=1.4 ETH and kickback rewards are 0.05 * 1.4 = 0.07 ETH. All good, except the proposer doesn’t get any rewards from b_{tip}!

kMEV-burn advantages

• Discourages “late-bidding cartels”: Colluding builders setting a low BFF will not be remembered by attesters, and will not receive builder rewards from the kMEV-burn mechanism.
• “Incentives to predict”: The expected behaviour from competitive builders converging towards bidding the full MEV block value at D is a feature, not a bug. It sets clear goals for builders, and emphasises competition over prediction capabilities that might give a small edge to builders that can build efficient prediction algorithms and low-latency transaction simulation, rather than pure order flow.
• Builders who are good predictoooors can generate a guaranteed revenue stream even in near perfect competition and their margins trend towards zero.

kMEV-burn disadvantages

• Misaligned incentives between builders and the proposer: There is a tension between betting the full expected block value in builders’ BFF at D to win attester auction and giving tips to proposers. Under competitive settings, a plausible scenario would be proposer rewards going to or near zero. This situation could potentially encourage proposers to grief builders and opt for choosing their own payloads.
• Proposer extortion games (h/t Barnabé): Growing the pie and adding builder kickback rewards can lead to situations in which the builder enters side-channel agreements with the proposer to rebate some of the kickback rewards back to the proposer (e.g., “As a proposer, I will only select your block if you send half of your kickback rewards to me. Otherwise I’ll just select another competing bid and you’ll get nothing.”). This type of side channel agreements was the main reason behind burning base fees in EIP-1559, and is a major concern since competing bids will likely have very similar values, so the proposer wouldn’t lose much by selecting another competing bid.
• Complexity: kMEV-burn introduces a new task for attesters and as Anders suggested in his post, this can lead to games in which builders may seek to influence attestations.
• More attestation deadline games: Since in kMEV-burn, attesters have to vote on the builder’s identity, attackers could send tons of bids with very small value differences, making it impossible for attesters to have an homogenous view of who the best builder (by BFF) is at D, and preventing kickback rewards to be distributed.
• Asking builders to predict the future block’s value might lead to more sophistication, which is a known centralisation vector. However, one might argue we’re already way past trying to avoid too much sophistication from builders, and predicting how much value they can extract from MEV opportunities and efficient packing is exactly what competitive builders are doing today.

predictive MEV-burn

The predictive MEV-burn proposal builds on kMEV-burn’s design and is motivated by a first principles approach to builder incentives. If MEV-burn’s main objective is to capture and burn a block’s payload full value, then we should explicitly incentivise builders to accurately predict what the payload full value will be at the observation deadline D (e.g., 2 seconds before the winning bid is selected at SB). The proposal also aims to address some of kMEV-burn disadvantages by (1) Simplifying how builders’ bids are structured by removing b_{tip} and keeping b_{BF} as a single variable to estimate the block value and (2) realigning builder and proposer incentives by introducing:

• Builder rewards R_{builder} set as a proportion x of b_{BF} set at D, referred to as b^D_{BF} or BFF.
• Proposer rewards R_{proposer} set as a proportion y of the b_{BF} at SB, or b^B_{BF}, for proposers

In this post, we assume x = y = 0.05, but more research is needed to determine x and y absolute and relative values. If proposer/builder kickbacks are too high, then the whole purpose of implementing MEV-burn falls apart, as this will generate the same economic and security concerns as MEV today. If the kickback rewards are too low, then builders might not be incentivised to bid earlier than D and might collude (amongst themselves or with the proposer) to keep the BFF low and collect most of the MEV. In the pMEV-burn design:

• Builders want to maximise their b_{BF} at D so they can set the BFF, be seen and remembered by attesters and collect R_{builder} .
• Proposers want to maximise R_{proposer} by choosing the block with the highest b_{BF} at SB.
• For a given slot, both the builder and the proposer only get rewarded of the majority of attesters voted TRUE, meaning the block selected by the proposer was built by the builder that set the BFF (see step 4. in figure below).

These changes mean builders and proposers incentives are now aligned, as there are no more incentives for proposers to extort builders for part of their kickback rewards (see Proposer extortion games section in kMEV-burn disadvantages).

To mitigate attestations deadline games and level the playing field among attesters and the proposer, we also propose to introduce a short time buffer so builders stop bidding 300 ms before the observation deadline, as was suggested in the comments of Anders’ post. This buffer increases the chances of participants having a more homogeneous view of the highest bid to set their local BFF and remember the winning builder’s identity. These changes are represented on the figure below.

We also describe and illustrate an example scenario for the happy case, in which a builder set the BFF at D to 1.4. That builder was also selected by the proposer at SB, and a majority of attesters voted TRUE, meaning they had the same view as the proposer. In this case:

• BFF = 1.4
• R_{builder} = x * BFF = 0.05 * 1.4 = 0.07
• R_{proposer} = y * b^B_{BF} = 0.05 * 1.45 = 0.0725
• The rest of the block value is burned:
  Burn = \text{Block value} - R_{builder} - R_{proposer} = 1.3075

In the in, the pMEV-burn proposal leaves us with a the following parameters to set:

• The attestation deadline D time
• The time buffer before D duration
• The proportion of BFF given to the wining builder x
• The proportion of b^B_{BF} given to the wining builder y

And more empirical/simulation-based analyses are needed to determine the initial values that should be given to these parameters.

pMEV-burn disadvantages

While we believe pMEV-burn presents some advantages outlined in the previous section, this design comes with its own limitations. Its main flaw can easily be illustrated if a large MEV spike happens after the observation deadline D. In that case, the difference between BFF and b^B_{BF} is likely larger than the proportion of b^B_{BF} that constitues R_{proposer} in the pMEV-burn design. In these instances, we can imagine builders and proposers being willing to use side channels to share the value being generated by the MEV spike rather than including it in b^B_{BF} and burning a large portion of it.

An important follow-up analysis to determine the viability of the pMEV-burn design would be to look at bids data submitted to relays and determine the percentage y of total base fees b^B_{BF} so that R_{proposer} are greater than the amount of MEV between D (e.g., at -2 seconds) and SB. Results of this analyses might give good directions to set parameters, but it’s important to keep in mind that builders are not trying currently incentivised to maximise their bids at SB - 2 seconds.

Discussion and research directions

In this post, we set out to summarise key features and tradeoffs, map out the design space, and propose a new design for a single slot, live auction MEV-burn mechanism. Our goal is for this to contribute to the development of a robust and efficient mechanism that can both capture and alleviate the detrimental effects of MEV. While writing the post, we identified several research areas that require further development:

• Attester games: Understanding incentives for a majority of attesters to delay or change their votes (TRUE or FALSE), including potential use of side channels, bribes and extortion games. Explore possibilities of implementing other mechanisms beyond binary votes, like having a committee (similar to a Payload Timeliness committee) vote on the bid value and builder’s identity directly (h/t Anders).
• Costs and profits from collusion: Simulations can help determine when Builder-Builder or Proposer-Builder collusion are profitable strategies compared to playing according to the mechanism’s rules. In turn, this can help setting values for parameters like x and y for builder and proposer rewards, respectively.
• Auction design: MEV-burn designs described in this post assume an open, dynamic first-price auction similar to the MEV-boost auction. Other designs should be explored (e.g., sealed bid, to maximise the amount of MEV captured by the protocol and limit centralising forces that can emerge from latency games and strategic bidding behaviour.

This list is not exhaustive, and a key aspect of future research will be to explore methods of critically evaluating existing proposals, which could lead to the development of new and innovative ideas.

[aelowsson]

I really like the graphical presentation’s way of capturing MEV burn with builder kickbacks!

There seem to be two changes relative to my design:

1. the tipping mechanism is removed,
2. the proposer also gets a kickback if it selects the winning builder.

I consider the buffer as part of the kickback design, as proposed in the associated post comment you correctly link. I have some concerns with both changes to MEV burn with builder kickbacks that I will now outline.

1. When it comes to removing the tipping mechanism, this is ostensibly done as a simplification. The post acknowledges that side channels will then be required in the case when MEV not accounted for in the bid at the observation deadline comes in after the deadline. In fact, side channels will be required for any attempt of the proposer and builder to interact, unless they are integrated—something which would simplify the process for these parties. A design requiring the proposer to operate side channels to sometimes maximize the value of the slot is also a design that rewards proposer sophistication. Due to these concerns, I have to question the value of removing the tipping mechanism. If the idea is to suppress tips administered before the observation deadline, then attesters can simply be tasked with summing the tip and the base fee of the bid when they observe it, and count this sum as the base fee when setting the floor.

2. When it comes to giving a kickback also to the proposer, I make the following observations:

(A) Proposers will now be required to be more sophisticated and try to guess who actually won the attester auction (at least, they are advantaged by it). But the winner may not always be immediately clear. In MEV burn with builder kickbacks, they simply need to pick a payload with a bid above the base fee floor (like in the original design). The tip will then indicate to them which bid they should select, and the more sophisticated builder can thus communicate its assessment of the outcome of the attester auction through the tip.

(B) I also make a further observation pertaining to the ideal condition for burning MEV: when it is readily available already at the observation deadline and nothing more comes in thereinafter. If there is perfect competition among conservative builders, then all MEV can be burned in MEV burn with builder kickbacks in this scenario. If they are not conservative, more MEV than available will be burned (see further below for more analysis of bidding strategies in this mechanism). In the proposed design however, the proposer’s cut will not be burned with conservative builders. The observation can be extended to more natural circumstances with some loss of generality along the way.

---

I will also provide a few more general comments pertaining to MEV burn with builder kickbacks.

@soispoke

We can draw several observations from this first example:

…

• Kickback rewards determined by x have to be high enough so that builders are incentivised to use the mechanism, rather than keeping the difference between the block’s actual value and their b_{BF} for themselves.
• After D has passed, all the additional value captured in the last 2 seconds are redirected to the bid tip and goes to the proposer. This behaviour doesn’t seem to be rational, and we suggest sophisticated builders will either increase their b_{BF} to get a higher kickback, or keep the excess value to themselves rather than giving it to proposers via b_{tip}.

Based on the last observation, we think builders will naturally tend to (1) bid up to the expected full block’s value in their b_{BF} at D to make sure it sets the highest BFF and (2) return little to no value to the proposer in their b_{tip}. This is an issue, because it means proposers won’t really have the option of selecting bids with the highest b_{tip}. Instead, they’ll be forced to choose the one bid that satisfies the BFF, even if that bid’s b_{tip} = 0

Let me counter these observations with some observations of my own.

Remember that builders can only include the available MEV in their payloads at the observation deadline. If they bid above available MEV when submitting the payload at the observation deadline, they must update the payload in a new bid after the deadline to actually attain that value. If they tip 0 when they update the bid, the proposer can grief the builder by selecting the payload presented before the observation deadline, thus depriving the builder of the MEV during the last seconds of the slot. The proposer and tentatively winning builder of the attester auction thus enter into an ultimatum game, wherein the builder must provide sufficient tips to incentivize the proposer to not grief it. We must thus assume that some of the value will flow to the proposer and some stay with the builder under equilibrium, since both parties can harm the other by not playing along. I make no judgment here whether it is desirable that either party attains the surplus. As discussed in my last comment, it is not a specific design goal of MEV burn with builder kickbacks to provide value from MEV to the proposer.

When it comes to the role of x and its effect on the burn mechanism, I would also like to offer another perspective. If we describe the MEV extractable by a builder at the observation deadline as V_b, the conservative builder (a builder that does not presume the ability to update the payload after the deadline) can bid \frac{V_b}{1-x}, because they know beforehand that in the scenario where they win the auction, they recoup the kickback. If the best builder has an edge V_e over the second best builder and is conservative, it in this scenario bids \frac{V_b-V_e}{1-x}. Thus, there is no guaranteed profit for builders under perfect competition (this is self-evident once you think about it). As mentioned in the previous paragraph, if the builder wishes its bid to reflect the full expected MEV of the entire slot, V_s, it should still make room for providing an anti-griefing tip t_g to the proposer. Otherwise, even if there are no competing builders, the proposer can simply select the builder’s bid from the observation deadline. The less conservative builder can thus bid a maximum of \frac{V_s-t_g}{1-x} at the observation deadline. The minimum it can bid and still win the auction is instead \frac{V_s-t_g-V_e}{1-x}. While x thus can be compensated for in the actual bid (to quite some extent), a high x can still have detrimental effects by making integration between proposer and builder favorable. This topic is beyond the scope of my comment, and a more detailed review will be provided in a post on MEV burn with builder kickbacks.

@soispoke

Proposer extortion games (h/t Barnabé): Growing the pie and adding builder kickback rewards can lead to situations in which the builder enters side-channel agreements with the proposer to rebate some of the kickback rewards back to the proposer (e.g., “As a proposer, I will only select your block if you send half of your kickback rewards to me. Otherwise I’ll just select another competing bid and you’ll get nothing.”).

There is no need for any side channel, this is what the tip is for. The proposer will never select a payload with a 0 tip unless forced by the mechanism and it is perfectly fine if it selects a competing bid that has also been able to provide a base fee above the floor. The winning builder of the attester auction is not entitled to win the proposer auction, but must earn this right (if it wants to get an updated payload included) by providing tips of size at least t_g.

@soispoke

Misaligned incentives between builders and the proposer: There is a tension between betting the full expected block value in builders’ BFF at D to win attester auction and giving tips to proposers. Under competitive settings, a plausible scenario would be proposer rewards going to or near zero. This situation could potentially encourage proposers to grief builders and opt for choosing their own payloads.

Aligning incentives between proposers and builders is not a design goal of MEV burn with builder kickbacks. A few of the design goals are to: (1) keep builders from cartelizing, (2) keep proposers from cartelizing with builders, (3) keep the MEV burn high, (4) make the smallest possible changes to the design, (5) ensure that blocks keep getting included in the blockchain in an orderly manner. The proposer cannot grief a builder by using their own payload unless they are able to bid up the base fee floor; and if so, they derive little to no value from the process.

[soispoke]

Thanks @aelowsson for your feedback and comments!

1. You’re right that the idea behind removing the tip was mostly done as a simplification. And in pMEV-burn rewards don’t come from tips anymore so there was really no reason to keep base fees and tips separate. I like the idea of attesters summing the tip and base fee to set the floor!
2. (A) About proposer sophistication, I’m not sure I agree. Having the buffer helps a lot with choosing who won the auction. I actually think there is more chances for the proposer not choosing the same bid as the builder in the kickback design since the bid setting the base fee floor isn’t at all indicative of whether that same bid will also be associated with the highest tip. Proposers have no reason whatsoever to choose the builder’s bid that set the BFF, which is why aligning incentives is useful imo.
   (B) In ideal conditions, I don’t think all MEV can be burned in any case, since some of it goes to builders via kickbacks? But if we ignore the builder kickbacks then I follow your reasoning. This case, when builders perfectly estimate the amount of MEV at the observation deadline, is important because I argue it will happen more often than not. I think this will lead to builders competing to set the maximum base fee floor, and iterating giving super small tips so proposers get nothing or close to nothing all the time. And maybe that’s fine, but I wanted to make it explicit in the examples I gave.

Observation 1: If the builder accurately predicts the MEV value at the observation deadline, and tips 0 ETH then the proposer can’t grief the builder? It has to choose a bid that is above the observed BFF, and I argue the builder might not care about MEV during the last seconds of the slot because its bid at the observation deadline already accounts for it (it’s predicting it).

On Proposer extortion games: let’s imagine the proposer see two bids:

• One by builder A that set the BFF at 1 ETH and is tipping 0.001 ETH
• One by builder B, that didn’t set the BFF (but his bid is above it), and is tipping 0.00099 ETH
  If x = 5%, the builder kickback will be 0.05 ETH. The proposer can extort builder A for a portion (let’s say 50%) of its kickback:
  – If builder A says no, the proposer chooses the second highest bid by builder B and wins 0.00099 ETH, and builder A gets nothing
  – If builder A says yes, the proposer wins 0.001+ 0.025 = 0.026 ETH and builder A wins 0.025 ETH (win-win )
  Am I missing something? This doesn’t seem to be an outcome we’d want to elicit, as it would incentivise proposer-builder integration, and here x is not high (5%), it’s more about the value of x vs relative to tips.

[aelowsson]

@soispoke

in pMEV-burn rewards don’t come from tips anymore so there was really no reason to keep base fees and tips separate

Just to be clear, any analysis of pMEV burn must incorporate side channel tips as a potential option. If there are incentives for tipping, we shall assume that it will happen, regardless of if the mechanism is incorporated in-protocol.

@soispoke

Having the buffer helps a lot with choosing who won the auction.

The buffer is not implemented to help determine who won the auction, and does not help in this regard. Its purpose is to reduce uncertainty regarding the base fee floor F_f. The moment when the auction winner is set, we can expect many quickly rising bids. This is true regardless of if there is a buffer or not, which is why the winner can be hard to determine. If F_f is set at the same time, the proposer may sometimes derive an expected profit by gambling on selecting a bid with a lower base fee and higher tip that turns out to be below F_f. I motivated splitting up the two deadlines as follows in the original post comment:

@aelowsson

…the deadline for selecting the subjective winner could be shifted to be slightly before the deadline for selecting the subjective base fee floor. The proposer will then always select a bid that at least matches the winner of the auction and not gamble.

Studying your graph closer for pMEV burn, I see that you indicate the deadline for setting the base fee floor as being before the deadline for determining the winner instead of after (I missed it in my first viewing). This is problematic by itself, because it negates the point of having the kickback in the first place. Its role is to ensure that there is no late-bidding cartel. If the base fee floor F_f is determined before the winner of the attester auction, late-bidding cartelization can still be profitable. Note that having the observation deadline for determining F_f first still does not make it easier to determine the winner of the attester auction.

@soispoke

I actually think there is more chances for the proposer not choosing the same bid as the builder in the kickback design since the bid setting the base fee floor isn’t at all indicative of whether that same bid will also be associated with the highest tip.

This is not relevant to the question, which is the issue of the pMEV design leading to proposer sophistication. It is perfectly fine if the proposer relies on tips to select the winner of the proposer auction, there is no harm done. It is also perfectly fine if it does not select the winner of the attester auction. However, importantly, note that the winning builder of the attester auction in MEV burn with builder kickback stands to gain xF from being selected by the proposer, where F is its base fee bid in the attester auction. This is the surplus value that cannot be attained by the second-best builder. If the winning builder is certain of its win, this thus leaves room for it to tip higher in the proposer auction when updating its payload, to attain the kickback.

@soispoke

In ideal conditions, I don’t think all MEV can be burned in any case, since some of it goes to builders via kickbacks?

No, all MEV can be burned and it will happen in the example I outlined. The conservative builder can bid the base fee F = \frac{V_b}{1-x} in the attester auction and will recoup the kickback and MEV, xF+V_b. These two are equal:

\frac{V_b}{1-x} =xF+V_b

\frac{V_b}{1-x} =x\frac{V_b}{1-x}+V_b

\frac{V_b}{1-x} =\frac{xV_b+(1-x)V_b}{1-x}

\frac{V_b}{1-x} =\frac{V_b}{1-x}

The reason why the conservative builder can bid \frac{V_b}{1-x} in the first place is because it derives that bid value from this equality. Also note that the conservative builder is here assumed to place the bid well in time to ensure it does not pass F_f without also winning the attester auction.

@soispoke

Observation 1: If the builder accurately predicts the MEV value at the observation deadline, and tips 0 ETH then the proposer can’t grief the builder? It has to choose a bid that is above the observed BFF, and I argue the builder might not care about MEV during the last seconds of the slot because its bid at the observation deadline already accounts for it (it’s predicting it).

The purpose of building blocks is to extract MEV. It is of no use to the builder that it predicts the MEV if it does not also extract it. Therefore it wants to update the payload through a new bid—to extract the MEV at the slot boundary (easy to forget the basic premise once you go into the nitty details).

@soispoke

On Proposer extortion games: let’s imagine the proposer see two bids:

• One by builder A that set the BFF at 1 ETH and is tipping 0.001 ETH
• One by builder B, that didn’t set the BFF (but his bid is above it), and is tipping 0.00099 ETH
  If xxx = 5%, the builder kickback will be 0.05 ETH. The proposer can extort builder A for a portion (let’s say 50%) of its kickback:
  – If builder A says no, the proposer chooses the second highest bid by builder B and wins 0.00099 ETH, and builder A gets nothing
  – If builder A says yes, the proposer wins 0.001+ 0.025 = 0.026 ETH and builder A wins 0.025 ETH (win-win )
  Am I missing something? This doesn’t seem to be an outcome we’d want to elicit, as it would incentivise proposer-builder integration, and here x is not high (5%), it’s more about the value of x vs relative to tips.

In your example, let us review what happens if Builder A gives the proposer an offer that it deems fair, say it tips 0.01 ETH. The proposer then gains 0.01 and Builder A 0.04. The total sums to 0.05, which is the value of the kickback (the example seems to assume that the builders do not gain anything from the actual MEV, which you may have forgotten to include in the analysis as noted in my previous comment). This is also the value that Builder A and the proposer can extract if they integrate. There is no surplus from integration (under the outlined premise). Also note that Builder A would win 0.024 in your suggested deal, not 0.025.

The problem with your example is that you assume that the builder should not need to share any of its surplus with the proposer. If Builder A is able to extract a higher surplus from a deal, it benefits by offering a price that reflects it, to ensure that the deal comes to fruition. This is not a matter that we as protocol designers need to specifically concern ourselves with, but one that can be resolved by market participants in the open market (through the tipping mechanism). As previously mentioned, some issues however emerge if x rises too high.

[soispoke]

@aelowsson

The problem with your example is that you assume that the builder should not need to share any of its surplus with the proposer. If Builder A is able to extract a higher surplus from a deal, it benefits by offering a price that reflects it, to ensure that the deal comes to fruition. This is not a matter that we as protocol designers need to specifically concern ourselves with, but one that can be resolved by market participants in the open market (through the tipping mechanism). As previously mentioned, some issues however emerge if xxx rises too high.

Let me focus on this first, because I think it might be the crux of our disagreement:
I don’t assume builders should not need to share their surplus with the proposer, nor did I forget MEV surplus builders might generate, rather I’m saying:

• Today, some builders almost never make profits (no surplus) from MEV, they even subsidise their blocks to gain market shares so I’m assuming very small builder profits in general under highly competitive environments.
• The only way for builders to set the BFF and get a chance to win the auction (and get the kickback) is to put as much of their value as possible into the base fee. Moreover, the more value they pour into their BFF, the higher their rewards will be (because the kickback is proportional to the BFF)
• This alone has the immediate effect of leaving proposers with very small tips
• But proposers can choose other bids, with higher tips, which acts as an incentive for builders to choose higher tips
  Is this right?
• What if all builders all agree to compete with each other but with extremely small tips? (let’s say, never higher than 0.00001 ETH).

@aelowsson

In your example, let us review what happens if Builder A gives the proposer an offer that it deems fair, say it tips 0.01 ETH. The proposer then gains 0.01 and Builder A 0.04.

I agree that the total sums to 0.05, but why would the builder tip 0.01 and not 0.00001?

@aelowsson

you assume that the builder should not need to share any of its surplus with the proposer.

It’s not really an assumption, I just really don’t see why the builder would want to share its surplus, since there are no incentives for him to do so.

@aelowsson

No, all MEV can be burned and it will happen in the example I outlined. The conservative builder can bid the base fee F = \frac{V_b}{1-x}F=Vb1−xF = \frac{V_b}{1-x} in the attester auction and will recoup the kickback and MEV, xF+V_bxF+VbxF+V_b.

Ah, ok thanks for spelling it out that makes sense

[aelowsson]

@soispoke

I agree that the total sums to 0.05, but why would the builder tip 0.01 and not 0.00001?
…
I just really don’t see why the builder would want to share its surplus, since there are no incentives for him to do so.

The incentive for a builder that won the attester auction and faces no competition in the proposer auction is that having its payload+bid from the slot boundary selected allows it to capture more MEV than if the proposer selects its payload+bid from the attester auction. It wants to convince the proposer to not grief it by selecting its earlier payload in their ultimatum game. And of course, the incentive for builders under competition in general is to get their associated payload selected to extract the MEV. So they pay up to the base fee floor and then tip, but this is probably clear.