Co-authored by Ethereum researchers and a16z researchers: Block Space Allocation Mechanisms
TechFlow Selected TechFlow Selected
Co-authored by Ethereum researchers and a16z researchers: Block Space Allocation Mechanisms
How do block space allocation mechanisms affect MEV?
Navigating Web3 tides with focused insightsAuthored by: mike, Ethereum researcher; Pranav Garimidi, Tim Roughgarden, a16z researchers
Translated by: 0XNATALIE
Co-authored by Ethereum researcher mike and a16z researchers Pranav Garimidi and Tim Roughgarden, “On block-space distribution mechanisms” systematically explores how block-space allocation mechanisms affect MEV. It first articulates the necessity of introducing in-protocol mechanisms for handling block-space distribution, then evaluates and compares existing allocation schemes using a “Who, What, When, Where, How” (W^4H) framework. The paper further delves into how the execution tickets model balances MEV awareness with fairness in allocation. Below is the translation of this article.
TL;DR: Block space—the capacity for transaction inclusion—is the primary resource derived by blockchains. As the crypto ecosystem expands and specializes, the value generated from efficient use of block space (MEV) plays an increasingly important role in the economics of permissionless consensus mechanisms. The research community has produced extensive literature on how protocols should handle MEV (see Related Work). Discussions over the past few years resemble the parable of the blind men and the elephant—offering many distinct perspectives, solutions, and theories, yet each view remains fragmented and difficult to compare. The first half of this paper aims to present a macroscopic picture of the "MEV elephant" by distilling core questions and exploring how existing proposals address them. The second half focuses on allocation mechanisms enabled by execution tickets, revealing a key new insight—the existence of a trade-off between the quality of an in-protocol MEV oracle and the fairness of the mechanism.
Article Structure: Section 1 explains why in-protocol mechanisms for block-space allocation are necessary as part of Proof-of-Stake's "endgame." Section 2 outlines five dimensions for evaluating block-space allocation mechanisms using a familiar set of questions: Who, What, When, Where, How (collectively abbreviated as W^4H). Section 3 examines how block builders are selected, focusing on the execution tickets model. Section 4 concludes with a discussion summarizing insights and proposing open follow-up questions.
Note: This article is lengthy and contains technical elements. We encourage readers to focus on the sections most relevant to their interests. Sections 1, 2, and 4 offer a broad perspective on existing proposals and our analytical approach. Section 3 (comprising ~44% of the text but containing 100% of the mathematical content) provides a detailed analysis of allocation mechanisms enabled by execution tickets. This section can be read sequentially, independently, or skipped entirely—it’s up to you!
(1) Motivation
Before diving into this complex topic, let us briefly clarify the necessity of block-space allocation mechanisms. In Proof-of-Stake, validators have two responsibilities: generating and voting on blocks. The following figure, adapted from Barnabé’s article “More pictures about proposers and builders,” illustrates these as proposing and attesting rights.
1) What
A block-space allocation mechanism is the process by which a protocol determines the owner of the right to propose—or build—a block. Proof-of-Stake protocols typically employ one of the following rules:
-
Block-space (proposing) right – A validator is randomly selected as leader and allowed to create the next block.
-
Voting (attesting) right – All validators vote within a time window on what they believe to be the canonical head block.
Validators are rewarded for performing these tasks. We categorize rewards based on their source: consensus layer (protocol issuance, e.g., newly minted ETH) or execution layer (transaction fees and MEV):
Consensus Layer
a. Attestation rewards – (see attestation deltas).
b. Block rewards – (see get_proposer_reward).
Execution Layer
a. Transaction fees – (see gas tracker).
b. MEV (transaction ordering) – (see mevboost.pics).
Rewards 1a, 1b, and 2a are well-known and “within protocol visibility.” MEV rewards are more challenging because fully capturing the value realized through transaction ordering is difficult. Unlike other rewards, the amount of MEV in a block is effectively unknowable (in a permissionless and anonymous system, it is impossible to track who controls each account and any off-chain activities that may coordinate for profit). MEV also fluctuates significantly over time (e.g., due to price volatility), causing execution-layer rewards to exhibit higher variance than consensus-layer rewards. Moreover, at the time of implementation, the Ethereum protocol lacks insight into the MEV generated and extracted by its transactions. To improve protocol visibility into MEV, many mechanisms attempt to estimate the MEV in a given block—we call these MEV oracles. Block-space allocation mechanisms often have the ability to generate such oracles, making the protocol “MEV-aware.”
This raises the question: why does the protocol care about MEV awareness? One answer is: MEV awareness may enhance the protocol’s ability to maintain equitable rewards among validators even when validators possess varying degrees of sophistication. For example, if the protocol could accurately burn all MEV, validator incentives would be entirely within protocol visibility (like 1a, 1b, and 2a above). Alternatively, a mechanism that shares all MEV equally among validators regardless of their sophistication (e.g., mev-smoothing) appears to promote a larger, more diverse, and decentralized validator set while preserving MEV rewards as additional staking incentives. Without MEV awareness, validators who are best at extracting or smoothing MEV (e.g., due to relationships with block builders, proprietary algorithms/software, access to exclusive order flow, and economies of scale) may receive disproportionately high rewards and exert significant centralization pressure on the protocol.
Ethereum protocol design strives to preserve a decentralized validator set at all costs. Needless to say, but for completeness: the protocol’s credibility neutrality, censorship resistance, and permissionlessness directly depend on a decentralized validator set.
Current Block-Space Allocation
In today’s Ethereum, mev-boost accounts for approximately 90% of blocks. With mev-boost, proposers (randomly selected validator leaders) sell their block-building rights via auction to the highest bidder. The following diagram illustrates this flow (we exclude relays since they are effectively extensions of builders).
Proposers are incentivized to outsource block construction because builders (agents specialized in transaction ordering to extract MEV) pay them more than they could earn by building blocks themselves. Returning to our goal of “maintaining equal validator rewards in the presence of MEV,” we observe that mev-boost allows all validators access to the builder market, effectively equalizing MEV rewards between solo stakers and professional staking providers—great! But…
Of course, mev-boost has several issues that continue to concern parts of the Ethereum community. In short, here are some negative side effects of taking the mev-boost pill:
-
Relays – These trusted third parties broker block sales between proposers and builders. Heavy reliance on relays increases the overall fragility of the protocol, as demonstrated by repeated incidents involving relays. Furthermore, since relays lack inherent revenue sources, more (and closed-source) profit-capturing methods are being implemented (e.g., timing games as a service and bid shading).
-
Protocol-external software vulnerabilities – Beyond relays, participating in the mev-boost market requires validators to run additional software. The standard suite for solo staking now involves running four binaries: (i) consensus beacon node, (ii) consensus validator client, (iii) execution client, and (iv) mev-boost. This not only adds significant overhead for solo stakers but also introduces another potential point of failure during hard forks. See the Shapella incident and Dencun upgrade for complexities arising from additional protocol-external software.
-
Builder centralization and censorship – While perhaps inevitable, the widespread adoption of mev-boost has accelerated builder centralization. Three builders account for approximately 95% of mev-boost blocks (representing 85% of all Ethereum blocks). mev-boost implements an open-bid, first-price, winner-take-all auction, leading to high levels of builder concentration and strategic bidding. Inclusion lists or other anti-censorship tools have not been implemented, giving builders substantial influence over transaction inclusion and exclusion—(see censorship.pics).
-
Timing games – Although timing games are considered a fundamental issue in Proof-of-Stake protocols, mev-boost pushes staking providers into thin-margin competition. Additionally, relays (acting on behalf of proposers in mev-boost auctions) serve as sophisticated intermediaries that facilitate timing games. Consequently, we see marketing campaigns promoting higher yields through staking with specific providers.
(2) Enumeration
Having set the stage, let us now examine the essence of block-space allocation mechanisms more closely.
Elements of Block-Space Allocation
Consider the game of acquiring block space; MEV incentivizes agent participation, while a combination of on- and off-protocol software defines the rules. What elements should be considered when designing this game? To answer this, we adopt the familiar rhetorical pattern of “Who, What, When, Where, How” (hopefully Section 1 sufficiently addressed the “Why”), which we refer to as the W^4H questions.
-
Who controls the outcome of the game?
-
What commodity are players competing for?
-
When does the game occur?
-
Where does the MEV oracle come from?
-
How are block builders selected?
These questions may seem overly simplistic, but when considered individually, each can be viewed as an axis measuring the mechanism design space. To demonstrate this, we highlight various kinds of block-space allocation mechanisms previously explored. Though they may appear unrelated, understanding how they answer the W^4H questions clarifies their interrelationships.
Execution Tickets and Other Approaches
We present outlines of many different proposal mechanisms. Note that this represents only a subset of the vast literature surrounding these designs—(see infinite buffet). For each of the following, we summarize only the key idea (refer to related work for details).
Execution Tickets
Key idea: Block-building and proposing rights are sold directly through “tickets” issued by the protocol. Ticket holders are randomly sampled as block builders with advance notice. Ticket holders have the right to produce blocks during their assigned time slots.
Block Auction PBS (Proposer-Builder Separation)
Key idea: The protocol grants block production rights via a random leader election process. Selected validators can either sell their block directly to the builder market or build locally. Builders must commit to a specific block in the auction. mev-boost is an off-protocol instance of block auction PBS; originally proposed, ePBS is the on-protocol equivalent.
MEV Burning / MEV Smoothing
Key idea: A committee sets a minimum threshold on the bid selected by the proposer in the auction. By requiring proposers to select a “sufficiently large” bid, a MEV oracle is created. MEV is either smoothed among committee members or burned (smoothed to all ETH holders).
Slot Auction PBS
Key idea: Similar to block auction PBS, but instead of selling a block to the builder market with commitment to a specific block, slots are sold without such commitment—sometimes called block space futures. By not requiring builders to commit to a specific block, future slots can be auctioned ahead of time rather than waiting for the slot itself.
Partial Block Auction
Key idea: Allows more flexible units of block space to be sold. Instead of selling entire blocks or slots, proposers can sell _parts_ of their block, e.g., the top of the block (most valuable to arbitrageurs), while retaining control over the rest of the block construction. Operates on other Proof-of-Stake networks, such as Jito’s block engine and Skip MEV lane.
APS Burn-as-you-execute Auction
Key idea: A new proposal from Barnabé that forces proposers to auction block-building and proposing rights in advance. Slots are sold ahead of time (at a fixed interval) without commitment to a specific block; a committee (as in MEV burning/smoothing) ensures bids are sufficiently large.
By comparing how these proposals answer the W^4H questions, we see they represent different regions within the same design space.
Applying W^4H: Comparative Analysis
For each W^4H question, we describe the differing trade-offs across the above proposals. For brevity, we will not analyze every proposal per question, but instead highlight key distinctions along each dimension.
Who controls the outcome of the game?
-
In the execution tickets mechanism, the protocol determines the winner by randomly selecting ticket holders.
-
In block auction PBS, the proposer (leader chosen by the protocol) unilaterally selects the winner.
-
In the MEV burning mechanism, proposers still choose the winner, but the winning bid is constrained by a committee, reducing proposer autonomy.
What are players competing for?
-
In block auction PBS, an entire block is sold, but the bid must commit to block contents.
-
In slot auction PBS, an entire block is sold, but no specific block content needs to be committed.
-
In partial block PBS, only a portion of the block is sold.
When does the game occur?
-
In block auction PBS, the auction occurs during the slot.
-
In slot auction PBS, the auction can occur many slots (e.g., 32) in advance, since no block content commitment is required.
-
In the execution tickets mechanism, tickets are allocated to slots at a fixed lead time.
Where does the MEV oracle come from?
-
In the MEV burning/smoothing mechanism, the committee enforces a minimum bid size, and this bid serves as the oracle.
-
In the execution tickets mechanism, the total expenditure on tickets serves as the oracle.
How are block builders selected?
-
In block auction PBS, any outsourced block production uses a winner-take-all allocation: the highest bidder wins the right to build the block.
-
In the execution tickets mechanism, many different allocation mechanisms are possible. For example, in the original proposal, tickets are randomly selected, and the mechanism is “proportional-to-tickets”; in this case, the highest bidder (holder of the most tickets) merely has the highest probability of selection, but is not guaranteed block-building rights.
If the above seems obscure, don’t worry. The next section will delve deeper into these different allocation mechanisms.
Motivation Recap
Before proceeding, let us revisit our initial motivation:
Block-space allocation mechanisms aim to maintain homogeneity in validator rewards in the presence of MEV.
This is a solid foundation, but if this were our only goal, why not just stick with mev-boost? Recall that mev-boost has several negative side effects that we may want our final protocol design to resist. We emphasize four additional potential design goals for block-space allocation mechanisms:
-
Encourage broader builder competition.
-
Enable trust-minimized interactions between validators and builders.
-
Incorporate MEV awareness into the base-layer protocol.
-
Fully remove MEV from validator rewards.
Note that while (1, 2, 3) are relatively uncontroversial, (4) is more contentious (and presupposes (3)). The protocol might eliminate MEV rewards to ensure consensus-layer rewards (the portion under protocol control) more accurately reflect overall system incentives. This also touches on staking macroeconomics and protocol issuance—more politically charged topics. On the other hand, MEV rewards are a byproduct of network usage; MEV can be seen as a native token value capture mechanism. We do not attempt to resolve these debates here, but rather explore how different answers impact mechanism design.
What can we do at the protocol design level to align with these expectations? As outlined, there are many trade-offs to consider, but in the next section, we will explore “How are block builders selected?” to make improvements in certain dimensions.
(3) Inquiry
Editor’s Note: As previously mentioned, this section is longer and more technical—if you’re short on time (or interest), feel free to skip directly to Section 4.
Partial Objective: Demonstrate a quantitative trade-off between MEV oracle quality and mechanism fairness between the two most familiar methods of allocating block-proposal rights (which we call “Proportional-all-pay” and “Winner-take-all”).
We aim to achieve this objective through the following subsections:
Basics
Before delving into allocation mechanisms enabled by execution tickets, we must first establish a model. Consider a protocol that sells execution tickets under the following rules:
-
Fixed price at 1 WEI, and
-
Unlimited quantity available for purchase and resale.
Note: This version of execution tickets is effectively equivalent to creating two separate staking mechanisms—one for attesting, one for proposing. Small design changes, such as disallowing resale of tickets back to the protocol, could significantly impact market dynamics, but that is not the focus here. We narrowly examine the problem of block-space allocation given an existing set of ticket holders.
Notably, from the protocol’s perspective, block producers and attestors are independent agents—individuals must choose which part of the protocol to participate in, by deciding whether to stake or buy tickets. A secondary ticket market may emerge as a venue for timely resale of block-building rights (much like today’s mev-boost).
Additionally, builders might choose to interact directly with the protocol by purchasing execution tickets, though their capital may be better suited as active liquidity capturing arbitrage opportunities across trading venues. Thus, they may prefer to purchase block space on the secondary market during auctions.
Why limit ourselves to this fixed-price, infinite-supply mechanism? Two reasons:
1. It is unclear whether a complex market can be implemented at the consensus layer. Client optimization enables any validator with consumer-grade hardware to participate. This requirement may be incompatible with fast auctions, bonding curves, or other potential ticket sale mechanisms. Questions regarding the number of tickets sold, on-chain ticket sales including MEV (meta-MEV?!), and timing of ticket sales (and timing games) seem closer to execution-layer concerns than what Ethereum consensus can reasonably implement while maintaining limited hardware requirements.
“One can imagine MEV arising from the inclusion of ET-market-related transactions, whether in beacon blocks or execution payloads.” —Barnabé in “More pictures about proposers and builders.”
2. Even (a big assumption) if the protocol could implement a stricter ticket sales market, the design space is vast. Many potential pricing mechanisms have been discussed, e.g., bonding curves, 1559-style dynamic pricing, auctions, etc.; general statements about these are beyond the scope of this paper.
Therefore, we focus on the “infinite supply, fixed 1 WEI price” version of execution tickets, minimizing protocol-internal complexity. Within this framework, we can ask a question that might be burning in your mind: “Given a set of execution ticket holders, how do we select the winner?” …Sounds simple, right? It turns out even this seemingly straightforward question offers much to discuss; let’s explore several different options.
x:b→[0,1]^n ∑ixi(b)=1 p:b→ℝ^n≥0
Model
Consider a repeated game where players gain MEV rewards through purchasing execution tickets:
-
Each round, each player submits a bid representing the number of tickets purchased. Let vector b denote bids, where bi is the bid of player i.
-
Each player has a valuation for winning block production rights. Let vector v denote valuations, where vi is the valuation of player i.
-
At each time step, an allocation mechanism determines each player’s allocation based on the bid vector. Assuming risk-neutral bidders, we can equivalently say each is allocated a “fraction of the block,” interpretable as “probability of winning a block.” In an n-player game, let x: b → [0,1]^n represent the allocation mechanism mapping, where xi(b) is player i’s allocation, subject to ∑ixi(b)=1 (i.e., the mechanism fully allocates).
-
Payments are collected from each player each round. Let p: b → ℝ^n≥0 denote the payment rule determined by the bid profile, where pi(b) is the payment of player i.
-
Each player’s utility function is defined as Ui(b) = vi xi(b) - pi(b), i.e., player utility equals the value of winning multiplied by allocation minus payment.
Familiar Allocation Mechanisms
Consider two (entirely different) possible mechanisms.
Proportional-all-pay (a slight modification of the original execution tickets proposal)
-
During each round, all players submit bids. Let vector b denote the bids.
-
The probability of a bid winning is proportional to its value divided by the sum of all bid values.
Each player pays their bid regardless of outcome (hence “all-pay”), so pi(b) = bi.
Winner-take-all (current implementation of PBS)
-
During each round, all players submit bids. Let vector b denote the bids.
-
The highest bidder wins, so xi(b) = 1 if max(b) = bi and xi(b) = 0 otherwise (e.g., in ties, prioritize lower bidders).
-
Only the winner pays their bid, so pi(b) = bi if max(b) = bi and pi(b) = 0 otherwise (same tie-breaking).
Comparison of Outcomes
To illustrate the differing outcomes of these two mechanisms, consider a two-player game where player 1 has valuation v1 = 4 and player 2 has v2 = 2 (we assume complete information where individual valuations are common knowledge).
Proportional-all-pay outcome:
-
Equilibrium bids: b1 = 8/9, b2 = 4/9
-
Equilibrium allocations: x1 = 2/3, x2 = 1/3
-
Equilibrium payments: p1 = 8/9, p2 = 4/9
This feels intuitively correct; when v1 = 2·v2 (player 1 values the block twice as much as player 2), player 1 bids, receives, and pays twice as much as player 2.
Winner-take-all outcome:
-
Equilibrium bids: b1 = 2+ε, b2 = 2
-
Equilibrium allocations: x1 = 1, x2 = 0
-
Equilibrium payments: p1 = 2+ε, p2 = 0
This is quite different. Player 1 bids just above player 2’s valuation (denoted by small ε), receives full allocation. Player 2 gets nothing and pays nothing.
Now consider the “revenue” (or sum of bids) collected by the mechanism in each case:
-
Proportional-all-pay revenue: b1 + b2 = 4/3
-
Winner-take-all revenue: b1 = 2+ε
Winner-take-all generates higher revenue, equivalent to a more accurate MEV oracle (thus allowing the protocol to burn or smooth more MEV) compared to proportional-all-pay. Intuitively, by allocating block production rights to lower-value players (as proportional-all-pay does), we forgo revenue that could have been captured by assigning the entire right to the highest-value player. For a more complete treatment, see Appendix 1.
Another factor to consider is the “fairness” or “distribution” of the allocation mechanism. For example, suppose we agree on the metric: √(x1·x2) (we use geometric mean because, with x1 + x2 fixed, it is maximized when x1 = x2 and zero if either x1 or x2 is zero). Now examine the fairness outcomes of the two candidate mechanisms:
-
Proportional-all-pay fairness: √(1/3·2/3) ≈ 0.471
-
Winner-take-all fairness: √(1·0) = 0
Here, the “performance” of the two mechanisms flips—winner-take-all is less fair than proportional-all-pay because “player 2” receives no allocation. This demonstrates a quantitative trade-off between MEV oracle quality and mechanism fairness when allocating block-proposal rights.
This small example reveals a key conclusion: a fundamental trade-off exists between MEV oracle quality and fairness. The proportional-all-pay mechanism (i.e., the original execution tickets proposal) is fairer because both players have a chance to win, encouraging each (especially high-value players) to adjust their bids accordingly, thereby lowering the mechanism’s revenue and MEV oracle accuracy. The first-price mechanism induces higher bids because bidders pay only upon winning the entire block, increasing revenue, but this winner-take-all dynamic makes the allocation unfair.
Open question: Is the proportional-all-pay mechanism the “optimal” Sybil-proof mechanism? In permissionless environments, we only consider Sybil-proof mechanisms—those where players gain no benefit by splitting their bid across multiple identities. We believe proportional-all-pay lies in a desirable region of Sybil-proof mechanisms, balancing well in terms of revenue/MEV oracle accuracy and fairness. We leave an interesting open question: determining the degree of “optimality” of proportional-all-pay (e.g., we have failed to find another Sybil-proof mechanism that outperforms it in both revenue and fairness).
(See original text for side notes #1 and #2 related to specific calculations)
(4) Implications
Let us summarize what we’ve learned. Section 3 demonstrated a fundamental trade-off between MEV oracle accuracy and fairness within instances of the execution tickets mechanism. A protocol may be willing to pay for more distribution and entropy (in the form of reduced revenue) to improve and sustain its credibility neutrality. Moreover, deriving equilibrium bids through modeling helps us understand how agents might respond to various allocation and payment rules.
Further questions (returning to our three W^4 questions):
-
What are players competing for? Can we extend the model to allow different players to value different parts of the block differently (e.g., arbitrageurs may highly value the top of the block but assign no value to the rest)?
-
When does the game occur? How does MEV oracle accuracy change if the game occurs far in advance rather than during the slot (e.g., pricing expected future MEV vs. currently realizable MEV)?
-
How are block builders selected? Are there Sybil-proof mechanisms that outperform proportional-all-pay in both revenue and fairness? Can we more formally characterize the fundamental trade-off between revenue and fairness? Given Sybil-proof constraints, what alternative allocation and payment rules should be explored (e.g., Tullock contests where the allocation rule is parameterized by α > 1 as xi = bi^α / Σj bj^α), and can we determine optimal choices?
Returning to a broader view, other versions of the W^4H questions may require different models for reasoning.
-
Who controls the outcome of the game? What collusion behaviors might arise in committee-enforced mechanism variants? If immediate block auctions continue off-protocol, should we explicitly model secondary markets?
-
When does the game occur? How critical is network latency when considering advance versus same-slot block space sales? Is it worth modeling partially synchronous environments? If multi-slot MEV becomes feasible, how will builder valuations change?
-
Where does the MEV oracle come from? If from a committee, do committee members have incentives to act dishonestly? Do these incentives depend on whether protocol-captured MEV is burned or smoothed?
As usual, open questions abound, but we hope (a) the W^4H questions help expand understanding of block-space allocation mechanisms, and (b) the deep dive into allocation mechanisms helps illuminate the potential design space of execution tickets.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
a16z
