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

[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.