# The Case for ⚡️🎰 Quick Slots in Hegota ## TL;DR We are proposing shorter slots for Hegota as it will significantly improve the UX of Ethereum. 6 second-slots is possibly too much alongside FOCIL, so we are proposing to go as low as possible given our available resources. ## Why it matters Slot time is the heartbeat of Ethereum's user experience. Every second we shave off directly translates to faster transaction landings, faster CEX deposits, and faster IRL payments. Depending on how far we can push it, this could be the single biggest UX upgrade in Ethereum's history, a step-change in how it *feels* to use the network. Beyond UX, shorter slots improve protocol economics in meaningful ways: - **Users get tighter DEX pricing** because arbitrage loss scales with $\sqrt{slot\_time}$ ([Milionis et al.](https://ethresear.ch/t/cex-dex-arbitrage-transaction-fees-block-times-and-lp-profits/19444)), so shorter slots mean less value lost to arbitrageurs. - **Less MEV surplus per slot** because MEV extraction is non-linear in slot time, reducing the value available to searchers and builders. - **Fewer empty blocks from ePBS** because [the free option problem](https://arxiv.org/pdf/2509.24849v1) is mitigated: shorter slots shrink the window for market movements between bid and execution, making option exercise less frequent. - **Based rollups get faster sequencing for free** since they inherit L1 slot timing directly. No rollup-side changes needed. - **Preconfirmations become less urgent** as a design priority. Much of the preconf design space exists to work around the slow UX created by 12-second slots. Reducing slot times at the protocol level addresses this directly. Finally, the performance engineering required to safely shorten slots is independently valuable. The CL has never had the kind of systematic bottleneck analysis that the EL received through bloat-nets, perf-nets, and benchmarks. Doing this work benefits client robustness regardless of where we land on slot duration. ## How we got here Due to strong client support thus far, it seems likely that [FOCIL](https://ethereum-magicians.org/t/hegota-headliner-proposal-focil-eip-7805/27604) will be selected as the CL headliner. Given the decision to limit each layer to one headliner per fork, and that 6-second slots was previously proposed as a headliner for Glamsterdam, it is very unlikely that a full 6-second slot proposal will make it into Hegota as-is. But there's a middle path. ## The proposal Rather than targeting a specific slot duration as a headliner, we propose shipping *quick slots* as a non-headliner: build the infrastructure to support slot times other than 12 seconds, do the empirical work to understand where the limits are, and set the target duration based on real data. This breaks down into three phases: ### Phase 1: Variable slot timing infrastructure The first lift is removing the assumption that slots are 12 seconds. This assumption is baked into many aspects of all clients: background task scheduling, numerous constants, `compute_time_at_slot(...)`, and more. This phase also needs to handle the fork transition gracefully so the switch is clean. ### Phase 2: CL performance characterization We simply don't know where all the CL bottlenecks are or how close we are to them. The EL went through this process with bloat-nets, perf-nets, and benchmarks. It's time to do the same for the CL. The same applies to the networking and p2p stack. We've long operated on assumptions about the limits of blob propagation, attestation aggregation, local building, and more. [Xatu](https://lab.ethpandaops.io/ethereum/live) gives us some insight, but we don't have the full picture yet. ### Phase 3: Iterative slot time reduction Once we've characterized the hot-spots, we can begin reducing slot duration by cutting out the slack. From there, we iterate: address client bottlenecks, then reduce slot times further when there's headroom again.  ## Considerations ### What about the EL? The EL remains largely unaffected. The block gas limit (and related constants) would be adjusted proportionally so that overall gas/second stays the same. For example, 8-second slots would carry 2/3 the gas of a 12-second slot. This keeps EL resource consumption and state growth rates unchanged and should require minimal EL-side work beyond the parameter adjustment. The EL is being scaled via orthogonal efforts. ### How short should we go? We don't have enough data to commit to a number yet, that's the point of Phase 2. Six seconds would be ideal, but given this is a non-headliner alongside FOCIL, eight seconds may be more realistic. Even ten seconds would be a meaningful improvement and worth shipping. The scope here also depends on how FOCIL development plays out. FOCIL proponents have characterized it as moderate in complexity (it was even considered as a non-headliner at one point) but the true cost will become clearer as implementation progresses. The variable slot timing infrastructure work is largely orthogonal to FOCIL, so both can advance in parallel. ### What if we can't safely go below 12 seconds? Then we ship the variable slot timing infrastructure anyway and don't change the parameter for Hegota. The worst case is the status quo, plus a CL that's been properly performance-characterized and an infrastructure that makes future slot time reductions straightforward. There's no downside risk to including this work. ## Laying the groundwork Even if we only achieve a modest reduction in Hegota, this proposal sets up two important things for the future: Once variable slot timing infrastructure exists, changing the slot duration in subsequent forks becomes a configuration change rather than a structural one. The hard part, untangling 12-second assumptions from every client, only needs to happen once. And once we've begun systematic performance engineering on the CL, client teams will have clear visibility into what needs optimization, what technical debt needs to be addressed, and where the real headroom is. This knowledge compounds across future upgrades.