The topic of ticket sales, including the issues of MEV (what is MEV?!) and the timing of ticket sales (and time games), seems to be more aligned with concerns of the operational layer than with issues that Ethereum consensus can reasonably address, all while maintaining limited hardware requirements. Even if (a big assumption) a protocol could implement a stricter ticket sales market, the design space for such a mechanism is vast. Many potential pricing mechanisms have been discussed, such as bonding curves, 1559-style dynamic pricing, auctions, etc.; making general statements about these is beyond the scope of this article. Therefore, we focus on the “unlimited, 1 WEI fixed price” execution ticket version, in which the complexity internalized by the protocol is minimal. In this framework, we can ask a question that may be burning in your mind, “Given a set of execution ticket holders, how do you choose the winners?”… Sounds simple, right? As it turns out, even with such a seemingly straightforward question, there is much to discuss; let’s explore a few different choices.
Model:
Consider a repeated game where players earn MEV rewards by purchasing execution tickets:
– In each period, each player submits a bid representing the number of tickets they wish to purchase. Let b be the bid vector, where bi is the bid of player i.
– Each player has a value for winning block production rights. Let v be the value vector, where vi is the value of player i.
– Each time step, an allocation mechanism determines each player’s allocation based on the bid vector. Assuming bidders are risk-neutral, we can equivalently say that each person is assigned “a part of the block”, which can also be interpreted as “the probability of winning a certain block”. In a game with n players, let x: b → [0,1]^n represent the mapping of the allocation mechanism, where xi(b) is the allocation of player i, subject to the constraint ∑ixi(b)=1 (i.e., the mechanism fully allocates).
– Payments from each player are collected in each round. Let p: b → Rn≥0 represent the payment rule determined based on the bid set, where pi(b) is the payment of player i.
– Each player’s utility function is defined as Ui(b) = vi xi(b) – pi(b), meaning the player’s utility equals the value of winning a block multiplied by the share obtained minus the amount paid.
Familiar Allocation Mechanisms:
Consider two (entirely different) possible mechanisms.
Proportional Full-Pay
(Slight modification of the original execution ticket proposal)
– In each round, all players submit bids. Let b represent the bid vector.
– The probability of winning the game is the bid value divided by the total sum of all bid values.
– Each player must pay their bid regardless of the game’s outcome (hence called “full-pay”), pi(b) = bi.
Winner Takes All (current implementation of PBS)
– In each round, all players submit bids. Let b represent the bid vector.
– The player with the highest bid wins the game, so x_i(b) = 1 if max(b) = bi and xi(b) = 0 (e.g., lower bid player prioritized in case of a tie).
– Only the winning player pays their bid, so pi(b) = bi if max(b) = bi and pi(b) = 0 (same tie handling).
Comparative Results:
To demonstrate the different outcomes of these two mechanisms, consider a game with two players, where Player 1 has a value of v1 = 4 and Player 2 has a value of v2 = 2 (we consider a fully informed setting where individual values are common knowledge).
Proportional Full-Pay Results:
– Equilibrium bids: b1 = 8/9, b2 = 4/9
– Equilibrium allocation: 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’s bid, receipt, and payment are twice that of Player 2.
Winner Takes All Results:
– Equilibrium bids: b1 = 2+ε, b2 = 2
– Equilibrium allocation: x1 = 1, x2 = 0
– Equilibrium payments: p1 = 2+ε, p2 = 0
This is quite different. Player 1’s bid just exceeds the value of Player 2 (where ε represents a small amount), receiving the full allocation. Player 2 gets nothing and pays nothing.
Now consider the “income” collected by each mechanism in each scenario:
Proportional Full-Pay income: b1 + b2 = 4/3
Winner Takes All income: b1 = 2+ε
The income from Winner Takes All is higher, equivalent to a more accurate MEV oracle (hence the protocol burns or smooths more MEV), rather than Proportional Full-Pay. Intuitively, by allocating block production rights to the lower value player (as Proportional Full-Pay does), we forego the income that could have been obtained if the entire right had been allocated to the highest value player. For a more detailed treatment, see Appendix 1.
Another factor to consider is the “fairness” or “allocation” of the allocation mechanism. For example, suppose we agree on the following metric: √x1⋅x2 (we use the geometric mean, as it maximizes when x1 + x2 is fixed, and is zero if either x1 or x2 is zero). Now, let’s look at the fairness results of the two candidate mechanisms:
Proportional Full-Pay fairness: √1/3⋅2/3≈0.471
Winner Takes All fairness: √1⋅0=0
Here, the “performance” of the two mechanisms is flipped—Winner Takes All is less fair than Proportional Full-Pay because “Player 2” receives no allocation. This demonstrates a quantitative trade-off between the quality of the MEV oracle and the fairness of the mechanism when allocating block proposal rights.
This small example reveals a key conclusion: there is a fundamental trade-off between the quality and fairness of MEV oracles. The Proportional Full-Pay mechanism (the original execution ticket proposal) is fairer because both players have a chance to win the game, encouraging each player (especially high-value players) to adjust their bids accordingly, thus reducing the mechanism’s income and the accuracy of the MEV oracle. The first-price mechanism triggers higher bids because bidders only need to pay when they win the entire block production rights, increasing income, but this winner-takes-all dynamic makes the allocation unfair.
Open Questions: Is the Proportional Full-Pay mechanism the “optimal” defense against Sybil attacks? In a permissionless environment, we only consider mechanisms that defend against Sybil attacks, where players do not benefit from splitting their bids into multiple identities. We believe that the Proportional Full-Pay mechanism lies in the ideal range for defending against Sybil attacks, performing well in terms of income/MEV oracle accuracy and fairness. We leave an interesting open question of determining the degree of “optimality” of the Proportional Full-Pay mechanism (e.g., we have not found another mechanism that outperforms it in both income and fairness).
(In-depth calculations related to side notes #1 and #2 can be found in the original text)
Inference:
Let’s summarize what we’ve learned. Section 3 showed the fundamental trade-off between the accuracy and fairness of MEV oracles in execution ticket mechanisms. A protocol may be willing to pay more for distribution and entropy fees (in the form of reduced income) to improve and maintain the protocol’s trust neutrality. Additionally, deriving equilibrium bids using the model helps us understand the reactions agents may have when faced with various allocation and payment rules.
Further Questions (returning to our three W^4 questions):
What are players competing for? Can we extend the model dimensions to allow different players to value different parts of the block differently (e.g., arbitrageurs may place particular importance on the top of the block but not on the rest)?
When does the game take place? How would the accuracy of the MEV oracle change if the game is played well in advance rather than during the slot period (e.g., pricing future expected MEV versus current achievable MEV)?
How do you choose block builders? Is there a defense against Sybil attacks mechanism that outperforms Proportional Full-Pay in terms of income and fairness? Can we formally describe the fundamental trade-off between income and fairness? Given the constraints of defending against Sybil attacks, which alternative allocation and payment rules should be explored (e.g., Tullock contests where the allocation rule is determined by the parameter α>1, the formula being i=bi^α/∑jbj^α), can we determine the optimal choice?
Returning to a broader perspective, other versions of W^4H questions may require different models for reasoning.
Who controls the game’s outcome? What kind of collusion behavior may arise in mechanism versions enforced by committees? Should we explicitly describe secondary markets if immediate block auctions continue outside the protocol?
When does the game take place? How critical is network latency when considering early block space sales versus simultaneous slot sales? Is it worth modeling partial synchronous environments? If multi-slot MEV is feasible, how would block builder valuations change?
Where does the MEV oracle come from? If from a committee, do committee members have incentives for dishonest behavior? Do these incentives depend on whether the captured MEV by the protocol is burned or smoothed?
As always, there are countless open questions, but we hope that (a) the W^4H questions help expand the understanding of block space allocation mechanisms, (b) an in-depth exploration of allocation mechanisms aids in understanding the potential design space of execution tickets.
