Citation

Rasheed, M., Desai, P., Gujar, S. “Let Leaders Play Games: Improving Timing in Leader-Based Consensus.” IIIT Hyderabad. arXiv:2602.11147v1 [cs.GT] (Feb 11, 2026).

Core Problem

In leader-based blockchains (Ethereum PoS), proposers know who will propose the next slot. A fast proposer can delay block publication to capture more transactions/MEV from the window between the previous block and the attestation deadline. This is timing games — solved for Ethereum L1 via AdaptiveSwitch and PoT, but this paper takes a game-theoretic mechanism design approach.

Proposal: 2-Prop

2-Prop: select two proposers per slot, each proposes a block. Attestors sign the first valid block they receive within the attestation deadline. Block confirmed if ≥ K attestors attest. Reward-sharing policy incentivizes faster proposal.

The Latency Game

2-Prop creates a two-player game (Latency Game) where strategies are amounts of delay:

  • Each proposer wants to be first to reach enough attestors
  • Delaying captures more MEV from new transactions but risks the other proposer winning
  • Randomization via reward-sharing makes early publication the dominant strategy

Equilibrium Results

Homogeneous setting (both proposers have same network parameters):

  • Nash Equilibrium: both propose without delay
  • The competition to be first dominates the incentive to delay

Heterogeneous setting (different network parameters):

  • Slower proposer: never delays (can’t afford to lose the race)
  • Faster proposer: delays only if the slower proposer’s expected propagation time is close to the attestation deadline (i.e., no effective competition)
  • In practice, heterogeneity rarely creates extreme timing-game incentives

Comparison to Other Approaches

ApproachMechanismTradeoff
AdaptiveSwitchValidators switch between strategies based on network conditionsRelies on voluntary adoption
Proof of Time (PoT)Physics-based delay proofs; can’t game without hardwareHardware dependency
2-PropCompetition between proposersAdds consensus complexity
ePBSBuilder holds the block; proposer gets reveal right onlyChanges who controls timing

2-Prop is elegant but requires consensus-level changes (selecting two proposers per slot and managing attestation competition). This is more invasive than AdaptiveSwitch.

Limitations

  • Two proposers per slot increases network complexity and potentially latency
  • Reward-sharing policy must be carefully designed to avoid edge-case incentive failures
  • In highly heterogeneous networks, the faster proposer may still strategically delay in edge cases