Note: This post may be kind of stale already, but its draft having been shared semi-publicly, I am inclined to publish the post anyways, for the sake of record-keeping/future discussions. See also Christine Kim’s write-up of ACDE #188 for an overview of the community’s thinking on this issue.

EIP-1559 introduced a new fee market in August 2021, where a user is able to set two parameters with their transactions:

• maxFeePerGas, denoting their highest willingness to pay per unit of gas.

• maxPriorityFeePerGas, denoting a “tip” accruing to the producer of the block.

EIP-1559 is also characterised by the introduction of a baseFeePerGas, a minimum price per unit of gas which the transaction must incur to be included. The baseFeePerGas is updated dynamically, according to the demand for inclusion, as measured by block fullness.

According to the analysis by Tim Roughgarden, in most cases when the chain is not congested and there is enough room to include all transactions that pay at least the base fee, a user should set their maxPriorityFeePerGas to some value μ which compensates the block producer for the cost of including an extra unit of gas to their block.

Gas opportunity cost in Proof-of-Work

In Proof-of-Work, a block producer indeed incurred such a cost. Adding an extra unit of gas translates to extra block size (in bytes) and thus longer propagation time over the network. This longer propagation time meant that a miner who solves the PoW puzzle could be “front-run” by another successful miner with a lighter block. Thus a miner ought to require at least the opportunity cost of adding extra weight to their block.

This opportunity cost was estimated in this note among others. The calculation gets a bit tricky accounting for possible MEV in the block (more on this in the following), but lands at roughly 1 Gwei as a good value that the block producer should demand to compensate for the extra orphaning risk (assuming no MEV).

In practice, clients such as Geth would set a “minimum priority fee” parameter, and would not include transactions which pay them a lower (effective) priority fee than this minimum.

Transaction opportunity cost in Proof-of-Stake

The move to Proof-of-Stake proceeded in September 2022, a year after EIP-1559 was deployed. In PoS, the block production schedule is quite different. Instead of multiple miners competing at the same time to find a PoW puzzle solution that will allow them to produce the next block, a single validator is given a window of time to produce their block, at t = 0 seconds at the start of a 12-second slot. Attesters ensure the timeliness. Attesters will wait for 4 seconds to receive a block, after which they will vote as if the block was missing. In other words, the validator has now 4 seconds to propagate their block on their network, without fear of anyone front-running them.

In this case, what does the priority fee pay for, when there is no congestion to enter the block? It is quite unclear, since there is no reason for the validator to not include an extra transaction as long as it pays them something. A validator could set their minimum priority fee to any value they desire of course, but could find themselves in situations where they drop transactions from their produced block for no good reason, as the following example shows:

Suppose Alice the block producer sets her minimum priority fee to 1 Gwei, the default value under Proof-of-Work. If Bob the user sent a transaction paying Alice 0.5 Gwei priority fee, Alice would not include it, even when including it would not hurt her chances of landing her block in time. Alice simply foregoes 0.5 Gwei per gas which Bob’s transaction uses. This is an argument for Alice to set her minimum priority fee as low as possible, as long as she can ensure to be timely, which the 4 seconds in principle give her plenty of time to be.

The same dynamics were observed by Péter here:

MEV, PBS and timing games

But yep, things are never so simple of course, and with the emergence of timing games (paper), we’ve observed that block producers would rather not be early in sending their blocks to the network, instead waiting as late as possible in these 4 seconds to accumulate more transactions and publish a more valuable block. Further, the intermediation of block proposing and building with MEV-Boost adds another layer to this game, which we describe below.

In MEV-Boost, a validator is able to receive offers from builders, who take care of sequencing the execution payload against a fee paid to the validator (known here as “proposer”). In this setting, the builder is the “block producer”, and thus is the entity who is responsible for deciding whether a transaction should be included or not.

Is the “minimum priority fee” relevant for a builder? The builder is assumed to be a fairly sophisticated entity, an “active block producer” in the language of “Transaction Fee Mechanism Design in a Post-MEV World” (Bahrani et al., 2024), which chooses to include transactions based on their capacity to offer them MEV. We may readily consider priority fees offered by users through their maxPriorityFeePerGas parameter as MEV, as it is indeed value received by the “miner”. But again, should a builder set some kind of minimum priority fee to filter which transactions to include in their block?

I argue that it is unnecessary. A builder may wish to include a transaction paying 0 maxPriorityFeePerGas, if the builder is able to extract value from this transaction. The builder, as a sophisticated entity, would be perfectly able to decide which transactions are meaningful to them to include.

While this argument may hold, this does not tell us what a user should set their priority fee to. Should it be zero? This is where timing games come into play. If a block proposer wishes to play timing games, the transaction must compensate the proposer for the extra propagation time which the block will require, and which would force the proposer to forego extra MEV from delaying their proposal a little longer and play the timing game. In other words, if x dollars of includable MEV accumulate per unit of time, and adding some transaction forces the proposer to propose t units of time earlier in order to make the 4-second deadline, then the proposer should expect at least t * x dollars from the transaction as priority fees to compensate for the extra delay which the transaction imposes. All of this however is on the user to set, and not relevant to the minimum priority fee parameter.

Suppose a validator does not connect to MEV-Boost, and builds their block locally instead. There are now two cases:

• The validator does not play timing games: This is then the case described in the section above, where the validator ought to set their minimum priority fee parameter low enough to not reject transactions for no reason.

• The validator plays timing games: In this case, the validator will wish to demand more fees from transactions to compensate them for the extra propagation time which prevents them from playing the timing game further. Mediating this demand with the minimum priority fee is however tricky, as the minimum priority fee ought to be dynamic and estimate x, i.e., the ambient measure of how much MEV accumulates per unit of time. I don’t believe Geth developers or other EL clients need to consider this case, as a validator playing timing games on their own may be considered sophisticated enough to be able to set their minimum priority fee themselves.

Wat do

In my opinion, clients should set their minimum priority fee parameter to a residual value, possibly 0. The priority fee pays for priority when the chain is congested, in which case the minimum priority fee is not relevant. When the chain is not congested, the minimum priority fee ought to compensate for some cost which the block producer incurs for including a transaction in their block. In Proof-of-Work, this cost was well-founded, and induced by the race to publish one’s block first when successful. In Proof-of-Stake, the minimum priority fee may be relevant in the context of timing games, but not so in the context of builders who decide which transactions to include.

I would also argue that 0 miner tips do not “favor MEV”. They are a natural consequence of market forces pushing them down, as the example above showed. These minimum fees were reasonable in Proof-of-Work, where the miner incurred a real opportunity cost from including an extra transaction due to orphan risk. They may be reasonable in the context of timing games again, where a block producer must be compensated for forfeiting potentially more value than they could obtain by delaying a bit longer. But it is not reasonable to “pay miners for their service”, if this cost does not represent any tangible, economic phenomenon, as is the case in Proof-of-Stake without timing games. In fact, for the block proposer to demand a minimum fee where this minimum fee is not required for proper network functioning is MEV, i.e., a rent which the proposer obtains at the expense of the user or the network more generally. It is therefore reasonable to deprecate the minimum priority fee if it does not help convey a real cost which the proposer must be compensated for.