Execution Ticket

An execution ticket is a proposed Ethereum mechanism where validators purchase the right to propose a block in a future slot.

Key Takeaways

Execution tickets are a proposed Ethereum mechanism that separates block proposal rights from the validator set, requiring participants to purchase tickets that grant the right to propose an execution layer block in a future slot.
The design aims to internalize MEV revenue into the protocol by burning ticket proceeds, reducing reliance on trusted relayers in the current MEV-Boost system.
Execution tickets remain a research proposal as of 2026: Ethereum's near-term path is enshrined PBS via EIP-7732 in the Glamsterdam upgrade, with execution tickets as a potential future addition.

What Is an Execution Ticket?

An execution ticket is a proposed protocol-level mechanism for Ethereum that would require participants to explicitly purchase the right to propose a block's execution payload in a future slot. Unlike the current system, where every validator is automatically eligible to propose blocks through a random lottery, execution tickets create a separate market for block proposal rights.

The concept was first introduced by Justin Drake under the name "Attester-Proposer Separation" (APS) at the Columbia CryptoEconomics Workshop and was later formalized by Mike Neuder of the Ethereum Foundation in a December 2023 ethresear.ch post. The proposal addresses a fundamental tension in Ethereum's current design: because maximal extractable value makes block proposal highly profitable, validators face strong incentives to outsource block construction to specialized builders, creating centralization pressure and trusted intermediary dependencies.

The Problem: MEV and the Current Proposer System

Ethereum's current block production involves a single validator selected to propose both the consensus (beacon) block and the execution payload. In theory, any validator can build their own block. In practice, the MEV landscape has made this uneconomical.

Over 90% of Ethereum blocks are now constructed through MEV-Boost, a sidecar protocol where specialized block builders compete to construct the most profitable execution payload. Validators outsource block construction because builders have access to sophisticated MEV extraction strategies: transaction reordering, sandwich attacks, and arbitrage that individual validators cannot replicate.

This creates several issues:

Relayer trust: validators must trust relayers to honestly convey builder bids without tampering, introducing a centralized chokepoint
MEV leakage: the MEV value flows to builders and relayers rather than being captured by the protocol itself
Timing games: validators strategically delay their block proposals to receive higher-value bids, degrading network health
Builder centralization: a small number of builders construct the majority of blocks, concentrating power over transaction ordering

How Execution Tickets Work

Execution tickets restructure block production by splitting each slot into two distinct roles: the beacon proposer and the execution proposer. These roles are filled through separate mechanisms.

Slot Structure

Under the execution ticket design, each Ethereum slot is divided into two phases:

Beacon round: a validator selected from the existing validator set proposes the beacon block. This block no longer contains the execution payload. Instead, it carries an inclusion list: a set of transactions that the execution block must include.
Execution round: a ticket holder, selected via lottery from all outstanding tickets, proposes the execution block containing the full transaction payload.

Each phase has its own attesting committee that validates the respective block. This separation means that regular validators retain their role in consensus but no longer need to deal with MEV extraction in execution payloads.

The Ticket Market

Ticket pricing is a core design question. The proposal suggests an EIP-1559-style pricing model where the protocol adjusts ticket prices based on demand. When demand for block proposal rights is high, ticket prices increase; when demand drops, prices decrease. This creates a smooth, predictable market rather than volatile first-price auctions.

A key property is that ticket proceeds are burned rather than distributed to validators. This mirrors how EIP-1559 burns base fees to benefit all ETH holders. By burning ticket revenue, the protocol effectively captures MEV that currently flows to external parties.

Lottery Selection

Once a participant purchases a ticket, they enter a lottery pool. The probability of being selected to propose the execution block for any given slot is proportional to the number of tickets held relative to total outstanding tickets. A participant holding 10 tickets out of 1,000 total has a 1% chance of being selected for each slot.

// Simplified selection probability
selectionProbability = ticketsHeld / totalTickets

// Expected value calculation for a ticket buyer
expectedRevenue = selectionProbability * expectedMEVPerSlot
ticketCost ≈ expectedRevenue  // Market equilibrium

At market equilibrium, the cost of a ticket should approximate the expected MEV revenue from proposing a block. Early estimates placed this around 0.11 ETH (roughly 0.33% of the 32 ETH validator stake), though the actual price would fluctuate with MEV market conditions.

Execution Tickets vs. Enshrined PBS

Execution tickets are often compared with enshrined PBS (ePBS), an alternative approach to the same problem. EIP-7732 defines ePBS and is currently slated for inclusion in Ethereum's Glamsterdam upgrade, which is targeting Q4 2026 mainnet activation.

Dimension	Execution Tickets	Enshrined PBS (EIP-7732)
Approach	Separate the execution proposer from the validator set entirely	Formalize the proposer-builder relationship within the protocol
MEV capture	Burns ticket revenue, internalizing MEV to the protocol	Proposer receives builder bids, keeping MEV within the validator set
Relayer dependency	Eliminates relayers by removing execution rights from validators	Eliminates relayers by enshrining the builder role in-protocol
Maturity	Research proposal, not scheduled for any upgrade	Implemented in EIP-7732, targeting Glamsterdam
Compatibility	Can potentially layer on top of ePBS	Near-term path, ships first

The two designs are not necessarily mutually exclusive. The original execution ticket write-up suggests that enshrining a PBS auction may still be worthwhile alongside execution tickets. In practice, ePBS is the near-term solution while execution tickets represent a more radical long-term restructuring.

Why It Matters

Execution tickets address a structural problem in proof-of-stake networks: the value of block proposal rights creates economic incentives that distort validator behavior. By pricing and auctioning these rights explicitly, the protocol can:

Capture MEV for all ETH holders through burning, rather than concentrating it among sophisticated builders and relayers
Reduce the economic advantage of large, vertically integrated validator operations
Eliminate the trust assumptions inherent in the current relayer-mediated MEV-Boost system
Create a cleaner separation between consensus duties (attesting, finalizing) and execution duties (ordering transactions, extracting MEV)

For the broader blockchain ecosystem, execution tickets represent an important experiment in mechanism design: using market-based auctions to allocate scarce protocol resources while minimizing centralization. Other networks, including Bitcoin layer 2s and alternative proof-of-stake chains, face similar MEV centralization dynamics and may adopt analogous designs.

Risks and Considerations

Ticket Buyer Centralization

Academic research has raised concerns that execution tickets could concentrate among buyers with low capital costs and high MEV extraction capability. A 2024 analysis found that when ticket buyers are heterogeneous in their MEV extraction skill, the market tends toward dominance by a small number of sophisticated participants. This could recreate the builder centralization problem that execution tickets aim to solve, just at a different layer.

Pricing Mechanism Design

The proposal does not yet fully specify how tickets will be priced and sold. Getting the pricing mechanism wrong could lead to underpricing (MEV leakage) or overpricing (reduced participation). The EIP-1559-style approach is one candidate, but the optimal design remains an open research question.

Inclusion List Complexity

The execution ticket design depends on inclusion lists: beacon proposers specify transactions that the execution block must contain. This mechanism (related to EIP-7547) adds protocol complexity and introduces questions about censorship resistance. If the execution proposer can ignore or circumvent the inclusion list, the separation of roles loses its censorship-resistance benefit.

Implementation Complexity

Splitting each slot into beacon and execution rounds with separate attesting committees is a significant protocol change. It requires modifications to the beacon chain specification, validator client software, and the consensus mechanism itself. The research community has described the design as volatile and subject to change, reflecting its early stage.