Thanks to Barnabé Monnot and Alex Stokes for helpful feedback and discussion.

Proposer-Builder Separation (PBS) is a design philosophy where parts of block construction are outsourced to out-of-protocol agents. PBS currently exists in the form of MEV-Boost.
In all of these designs, however, we need to decide whether to implement block auctions or slot auctions. In Barnabé’s post on the state of PBS, he briefly introduced the topic of block vs. slot auctions. The goal of this post is to expand upon this by defining the two situations more precisely, investigating how different forms of maximum extractable value (MEV) behave under either auction mechanism and discuss whether there are other possible options than block or slot auctions.

What are Block and Slot Auctions?

In this text, we presume without loss of generality that we are in the two-slot Proposer-Builder Separation mechanism, where the proposer makes a beacon block committing to a builder, and the builder then releases their own block

In PBS, builders compete for the right to construct a certain block. They do this by sending bids to the proposer who controls that block. The proposer is then in general free to choose the bid that they want, which would rationally be the highest paying bid. There could also be a mechanism to force proposers to choose the highest bid, such as MEV-smoothing or MEV-burn. To achieve this there must be consensus over what the highest bid is. These consensus bid mechanisms are irrelevant for the discussion on block vs. slot auctions, as they tell you how the bid is used, and not what the bid values, i.e., which good is being sold.

Block or slot auctions refer to a difference in time when a builder needs to commit to the contents of the block they will send to the proposer if they win. Although the exact timing has not been specified, in PBS a builder sends a bid to the proposer, the proposer then picks one bid as the winner and the builder then needs to send the contents of their block.

Block auctions require a builder to commit to the contents of their block at the time of their bid.

In slot auctions, a builder publishes a bid. The proposer then commits to a certain block builder. The builder then releases their block contents when it is the time to do so.

First of all, what are builders exactly buying when they bid for the right to make the block? Block auctions mean that the builder has committed to one specific block's contents. They cannot deliver a block with a different content, they could however choose not to deliver the payload meaning that the proposer must submit an empty block. A winning bid with a certain block header in block auction PBS can thus be seen as an option on one specific future state of the blockchain and an option on an empty block being submitted to the chain. In slot auctions a winning bid can be seen as an option on a larger set of future states of the blockchain, such that all future sets satisfy the state transition function given the current state and the transactions in the mempool. The option obtained via a slot auction is thus more general than the option obtained via a block auction and the future state that can be accessed using the block auction option can also be accessed using the slot auction option.

Since the block auction option is encompassed by the slot auction option, a slot auction intuitively unlocks more value. We could thus expect bids in slot auctions to be higher than bids in block auctions.

There are other related topics that are relevant for block building mechanics. In the following two sections we explore how these topics are influenced by the different auction mechanics.

Latency or Just-In-Time Block Building

Here, we define latency as the difference in time between an agent sending a bid or block and their bid or block being registered by the proposer. Just-In-Time Block Building refers to builders using low-latency infrastructure to build blocks just before the time their block needs to be committed to. Just-In-Time Block builders usually monitor the mempool for additional transactions. With this additional information they can build a block that is better or at least as good as a builder without this additional information, keeping all else constant.

In my opinion the discussion on block vs. slot auctions is orthogonal to considerations about latency or just-in-time block building. Under both auction mechanisms a builder with low latency can profit in similar manners because they gain more information, which leads to centralization or efforts to reduce latency. In block vs. slot auctions though, it is about what a competitive builder needs to predict but more on this later.

Timing Games

Timing games are slightly different than just-in-time block building because with timing games the time at which something should be done is moved to a later time and with just-in-time block building this is not the case. Introducing a bid and a block commitment means that there will also be timing games around this.

• In both block and slot auctions, the builder is incentivized to publish their bid as late as possible subject to their bid still being seen by the proposer.

  • In block auctions, the builder is incentivized to do so because the builder can build a more valuable block and they can base their bid on more information.

  • In slot auctions, the builder is incentivized to do so because they can base their bid on more information.

• In slot auctions there is an additional incentive to commit to the contents of their block as late as possible. Later block commitment means the builder can build a more valuable block.

Timing games are an area of open research. Check this Robust Incentives Group Open Problem (ROP) if you are interested!

MEV Effects

One reason to implement PBS in the first place is to preserve the decentralization of the validator set. The ideal of PBS is to provide an environment where all proposers, regardless of their trustworthiness or sophistication, receive equal payments in expectation. It is thus important to analyse how (de)centralization behaves under the different auction mechanisms.

Single-domain MEV

For block vs. slot auctions it is important to distinguish between single-domain and cross-domain MEV. Single-domain MEV refers to all MEV that is extracted while only using one domain, hence all MEV that is not cross-domain MEV.

With block auctions, a builder knows exactly how much single-domain MEV they will extract. This means it is easy for the builder to value how much they are willing to bid to get their block included in the canonical chain.

With slot auctions, a builder does not know how much single-domain MEV they will extract, since more transactions will enter the mempool between the time of a builder submitting their bid and a proposer demanding the block. These transactions could carry MEV with them meaning that competitive builders would most likely need to bid more than the amount of MEV that they could currently extract given the mempool at the time of bidding. Determining how much to bid thus becomes more difficult under slot auctions. Even if you have a very accurate prediction mechanism for the future inflow of MEV, a long-term builder needs to have capital to sustain the event where they may be wrong a few blocks in a row.

Users will not be affected much by the auction choice. Their single-domain MEV will be extracted in either auction. The time to inclusion for users will be slightly higher under block auctions.

Cross-domain MEV

Cross-domain MEV is not a large amount of MEV that is currently extracted. The largest form of cross-domain MEV is now probably arbitrageurs extracting Loss-Versus-Rebalancing (LVR) from liquidity providers. If we bake one auction mechanism into the protocol, however, it must not only be designed for now but also for the reasonably distant future. As price discovery shifts from centralized exchanges (CEX) to possibly decentralized exchanges (DEX) on multiple domains such as rollups, we need to ensure that the auction mechanism does not harm the decentralization of the validator set.

A builder who has won the right to build the next block has a guaranteed execution right on a DEX. If the price on a DEX is higher than the price on a CEX, the builder will sell on the DEX and buy on the CEX to lock some cross-domain arbitrage in and vice versa if the price on a DEX is lower than the price on a CEX. A profit maximizing builder will then try to trade on the CEX whenever the difference between the CEX and the DEX price is the largest. In the assumptions of LVR the external market price - effectively the price on a CEX - is a martingale, hence a builder could not make an educated guess on whether or not the external market price will rise or fall. In practice a builder will extract value via statistical arbitrage.

With slot auctions, the builder knows they are guaranteed to extract LVR, hence they can establish exactly how much to extract based on the current external market price. With block auctions, the builder needs to use the external market price at the time of the bid to construct a transaction extracting LVR. They will only make the trade on the CEX whenever their DEX leg of the trade is guaranteed.

Since the LVR extraction will be based on an external market price that is closer to the external market price at execution of the block, the DEX prices will be a better price “oracle” for external market prices under slot auctions than under block auctions. Other oracles could also be updated more closely to execution time, however, the builder does need to be explicitly incentivized to do so. Furthermore, even under slot auctions there is a time difference between commitment to the block contents and execution hence DEX prices will still be off from the external market price.

Aside from LVR, there could be many other cross-domain MEV opportunities. In general slot auctions seem to ease the extraction of cross-domain MEV because a builder can decide whether to extract or not based on whether they are allowed to control the block or not. I believe, however, that under block auctions cross-domain MEV will be extracted as well. Competitive builders will still try to predict the cross-domain MEV activity and bid accordingly. Keeping all else equal, builders that then try to extract cross-domain MEV are more likely to win the auction than those that do not, meaning that cross-domain MEV would still be extracted.

Other domains also need to decide on whether they will use block or slot auction mechanisms. This decision might have an impact on the amount of cross-domain MEV extracted. We can draw a game-theoretic table indicating how much cross-domain MEV is extracted under these design decisions. What the values of cross-domain MEV extraction would be is unclear.
Suppose two domains choose to use slot auctions. It seems intuitive that there will be more cross-domain MEV extraction than if both would choose block auctions, but this is not certain. What if one domain chooses block auctions and the other slot auctions? How much cross-domain MEV will be extracted and how is this MEV allocated?

Multi-block MEV

For MEV to be multi-block, the sum of MEV extraction in two blocks must be smaller than the MEV extraction over both blocks. Multi-block MEV is a centralizing force because it requires one builder to control multiple blocks.

For multi-block MEV it is very important to know a priori that you will control the contents of multiple blocks. Given this knowledge, you can decide on the block contents. Consider this example by Alex Nezlobin, multi-block MEV is extracted based on knowing whether you control both blocks. The auction mechanism is irrelevant. When using slot auctions, a builder may have a small amount of extra time to obtain this right of constructing multiple blocks but this effect is small. Currently, proposer can know they will propose a block 2 epochs in advance, hence they could sell their slot in an off-band slot auction 2 epochs in advance, unless consensus bids are required by the protocol. The small timing difference between a block and a slot auction is then unlikely to have an effect.

There might be other multi-block MEV cases that do rely on a specific auction mechanism and this remains an open problem.

In general, with slot auctions a bidder needs to predict single-domain MEV and a part of cross-domain MEV but that last prediction is less difficult than with block auctions; with block auctions a bidder needs to predict cross-domain MEV.

Hybrid Auction Mechanisms

Choosing block auctions means builders need to predict cross-domain MEV. Choosing slot auctions means builders need to predict single-domain MEV and a part of cross-domain MEV.

Justin Drake recently suggested a hybrid auction mechanism, where block builders can commit to a part of their block but are not required to at the time of their bid. For example, the builder could commit to building a block with a certain block prefix. In this case the builder can choose a mix of block and slot auctions.

We could see builders follow strategies like:

• Extract cross-domain MEV via slot auction mechanisms, i.e. do not commit to specific block contents at the time of their bid for this part of the block.

• Extract most single-domain MEV via block auction mechanisms by committing to a specific block contents at the time of their bid.

• Extract more single-domain MEV from the transactions entering the mempool after the bid has been placed via slot auction mechanisms.

The advantages of this are that the protocol does not bake in one specific auction model and a block builder committing to specific block contents means they could sell soft preconfirmations to users; the builder could guarantee that their transaction will be included in the next block if they win the auction. If the value of selling these soft preconfirmations is higher than the value the builder forgoes by restricting its future optionality, the builder could build an even more valuable block. The advantages for users are that they can buy soft pre-commitments and the average time to inclusion for user transactions will decrease compared to block auctions because transactions that are only seen after the builder publishes its bid are still included in the next block.

One problem such an auction mechanism faces is that it is unclear at what state of the EVM the preconfirmed block contents are executed, unless the pre-committed part is a block prefix.

Conclusion

In deciding between block vs. slot auctions, there are many uncertainties but it is important to analyze what leads to the most decentralization. Slot auctions seem to unlock more value as the protocol allows proposers to sell options that are more general than block auctions, but whether they pose more centralization risk is unclear. A hybrid auction where builders can decide on what part of their block is pre-committed to could be the best of both worlds and would allow for soft pre-commitments.

Here are some questions to think about when deciding on block vs. slot auctions:

• How is the block builder optimization problem different under block and slot auctions?

• Does the protocol want to design for cross-domain and multi-block MEV extraction or not?

• What exactly is the execution time of Ethereum that can be used to calculate the size of cross-domain MEV opportunities such as LVR?

• How do timing games in Ethereum differ under block or slot auctions?

• How can we minimize the advantages of low-latency for builders?

• Is there classic auction theory that can be applied to block vs. slot auctions?

• What is the best hybrid auction mechanism?