EIP-8198 Quick Slots: slot time from 12 seconds to 10 seconds (Quick Slots)

Declined for Inclusion · Consensus & staking · EIP status Draft · created 2026-03-17

Replaces the slot time, currently a constant fixed in code, with a per-epoch schedule (SLOT_DURATION_SCHEDULE), and uses that mechanism to cut the block interval from 12 seconds to 10 seconds. Rewards, penalties and the blob retention period stay the same in real time.

Why it is needed

Today Ethereum produces one block every 12 seconds. Users feel those 12 seconds on every transfer, exchange deposit and payment. The source splits the problem into several parts. The loss that liquidity providers on decentralized exchanges (DEXs) suffer to arbitrage is proportional to the square root of the block interval, so cutting 12 seconds to 10 seconds reduces it by about 9%. Shorter slots also bring final confirmation sooner, and more block proposers take part in the same span of time, which makes censoring transactions harder. The need for preconfirmation mechanisms, built up to hide the 12-second delay, also shrinks. The time an L2 waits for several L1 blocks before processing a deposit gets shorter as well. The real bottleneck, though, is not choosing the number. The assumption that a slot is 12 seconds is embedded throughout every consensus client and execution client. This EIP does two things together: it first removes that assumption so that slot time becomes a configuration value, and then it conservatively reduces it to 10 seconds.

What changes

Today

After EIP-8198

Who is affected

In depth

Slot time schedule (SLOT_DURATION_SCHEDULE)

The SLOT_DURATION_MS constant is removed and replaced with a SLOT_DURATION_SCHEDULE list. Each entry has just two values: the activation epoch and the slot time (ms). get_slot_duration_ms(epoch) returns the value that applies to that epoch. The schedule must satisfy four conditions. The first entry must be 12,000ms at GENESIS_EPOCH, and this is the baseline for ratio calculations. Entries must be in ascending epoch order. Later entries can only be activated at network upgrade epochs at or after HEZE_FORK_EPOCH. Changes between upgrades (the BPO approach) are not supported. The slot time must be a positive multiple of 1,000ms, so the timestamp of every slot boundary is a whole number of seconds. On mainnet, a 10,000ms entry is added at HEZE_FORK_EPOCH. The slot time ratio r is get_slot_duration_ms(epoch) / get_slot_duration_ms(GENESIS_EPOCH), which is 5/6 in the 10-second era. r is not computed separately; each formula multiplies by the numerator first and divides by the denominator at the end. All arithmetic is integer division.

Intra-slot deadlines and the wall-clock timeline

Intra-slot deadlines such as attestation, aggregation, sync messages and the proposer reorg cutoff stay as bps (basis points) values of the slot time (ATTESTATION_DUE_BPS, PROPOSER_REORG_CUTOFF_BPS and so on), as they are today. get_slot_component_duration_ms, which converts them to milliseconds, applies the bps to the slot time at the fork, get_slot_duration_ms(HEZE_FORK_EPOCH), instead of the value currently in effect. The schedule carries no deadline information, so any later upgrade that changes the slot time again must define its own deadline rules. This is because propagation, aggregation and block building have fixed overhead, so not every component shrinks in proportion to the slot time. The mapping between time and slot number also changes. It must come from a piecewise timeline that runs from genesis through each era's own slot time, not from multiplying by 12 seconds from genesis. This covers execution payload timestamp validation through compute_time_at_slot, the fork choice store clock (compute_slot_at_time_ms and compute_time_at_slot_ms, including checkpoint sync initialization), intra-slot timeliness measurement (based on the slot start time instead of time % SLOT_DURATION_MS), gossip slot range validation, expiry and scoring windows, and light client clock derivation. The duty scheduler must keep millisecond precision.

Consensus economics: constants stay, rescaled by the ratio r

No consensus constant value changes. Instead, the three time-dependent per-epoch quantities are rescaled by r. The base reward per increment is multiplied by r, so a BASE_REWARD_FACTOR of 64 becomes an effective 64 × 5/6 = 53.33. Because it is the exact ratio and not a rounded 53, issuance does not drift systematically (truncation error is at most 1 Gwei per computation). The inactivity penalty accumulates as the square of the epoch count, so it is multiplied by r² and folded into the penalty denominator, making the effective denominator 36/25 times larger. INACTIVITY_SCORE_BIAS cancels between numerator and denominator and is left untouched. The activation, exit and consolidation churn limits are multiplied by r; the minimum and maximum bounds are applied first, then the ratio is multiplied, and the EFFECTIVE_BALANCE_INCREMENT rounding is done only once at the end. Exit and consolidation epochs that are already assigned are left as they are. Rewards and penalties are computed using the slot time of the epoch being paid for, not the epoch being processed. Otherwise the first epoch right after the transition would price 12-second attestations at the 10-second rate, paying about 17% less and making the inactivity penalty about 31% smaller. Values counted in epochs or slots, such as the withdrawable delay, the slashing window, the sync committee period and SLOTS_PER_EPOCH (32), keep their counts, so their real time gets shorter. An epoch becomes about 5.3 minutes, and finality goes from about 13 minutes to about 10.7 minutes.

Data availability retention period

The data column sidecar retention window is defined in real time as MIN_BLOB_DATA_RETENTION_MS instead of an epoch count (MIN_EPOCHS_FOR_DATA_COLUMN_SIDECARS_REQUESTS). The value is 1,572,864,000ms (about 18.2 days), equal to 4,096 epochs of 12-second slots. A new helper, compute_blob_data_retention_start_epoch(epoch), returns the epoch containing the point that far back on the piecewise timeline. The retention window start is max(that value, FULU_FORK_EPOCH), and the lower bound of earliest_available_slot in Status v2 and of data_column_serve_range in DataColumnSidecarsByRange v1 and DataColumnSidecarsByRoot v1 uses this value. This is because external consumers, such as optimistic rollups with a challenge period of about 7 days, expect data in real time, not in epoch counts. After the 10-second transition, the number of epochs the window covers grows one epoch at a time up to about 4,916, and the start point never moves backward. So nodes do not need to store more in advance or re-download later. By contrast, the block retention window compute_min_epochs_for_block_requests() (33,024 epochs on mainnet) and other epoch-denominated windows keep their epoch counts, so their real time shrinks gradually from about 146.8 days to about 122.3 days. The blob sidecar Req/Resp is already deprecated and is left untouched.

Execution layer: gas limit and base fee

The execution layer does not read the slot time. Gas throughput is protected by prior coordination, not by a consensus rule. If the target is lowered by × r (for example, from 100M to about 83.3M) before the upgrade using GAS_LIMIT_SCHEDULE and the proposer's target_gas_limit, the usual ±1/1024 adjustment alone reaches it within a few hours. If coordination fails, gas per second briefly overshoots by at most 20%, and consensus validity is not affected. The base fee's maximum change of 1/8 per block is calibrated to 12 seconds, so if left as is, it would react 20% faster per unit of real time. So instead of changing the constant, the gap to the parent is measured using the header's timestamp and slot_number (EIP-7843). The denominator is BASE_FEE_MAX_CHANGE_DENOMINATOR × BASE_FEE_REFERENCE_SLOT_SECONDS × slots_elapsed, and seconds_elapsed is capped at BASE_FEE_REFERENCE_SLOT_SECONDS × slots_elapsed. BASE_FEE_REFERENCE_SLOT_SECONDS is a new constant, 12, and BASE_FEE_MAX_CHANGE_DENOMINATOR stays at 8. The maximum change becomes min(slot_duration, 12) / 96, which is exactly 1/8 at 12 seconds and exactly 5/48 at 10 seconds. From the upgrade on, a block is invalid unless header.slot_number > parent_header.slot_number, and EIP-7843 must already be active. Empty slots do not change the rate. Because of compounding it is not perfectly identical: at 10 seconds, a full block raises the fee about 1.0% faster per second, and an empty block lowers it about 1.1% slower.

Blob schedule, system contracts and networking

This EIP does not change blob parameters. A slot time change comes with an EIP-7892-style blob-only fork, that is, a BLOB_SCHEDULE entry activated in the same epoch, which matches the blob target, maximum and BLOB_BASE_FEE_UPDATE_FRACTION to the new slot time. A network that does not change its slot time simply adds no entry. The 8,191-slot buffers of the EIP-4788 beacon root contract and the EIP-2935 block hash history contract are part of the deployed contracts, so they are deliberately left unchanged. In networking, topics are re-keyed with the upgrade fork digest as usual, and clients should subscribe to the new topics before the upgrade epoch. ATTESTATION_PROPAGATION_SLOT_RANGE stays at 32 slots and EPOCHS_PER_SUBNET_SUBSCRIPTION at 256 epochs, so only their real time shrinks (subnet subscription rotation goes from about 27.3 hours to about 22.8 hours). Absolute time tolerances such as MAXIMUM_GOSSIP_CLOCK_DISPARITY, TTFB_TIMEOUT and RESP_TIMEOUT must not be rescaled. For gossipsub, seen_ttl, defined as two epochs, is computed from the piecewise timeline.

Impact on apps and tooling

Every piece of logic that converts block counts into real time changes at the transition. Logic based on block.timestamp is unaffected. Going from 12 seconds to 10, a period of N blocks becomes about 17% shorter and a per-block quantity is consumed about 20% faster. The EIP-4788 and EIP-2935 buffers stay at 8,191 slots, so the lookback window shrinks from about 27.3 hours to about 22.8 hours, and contracts that assumed a full day of history no longer get it. Across the upgrade boundary, 12-second and 10-second intervals are mixed, so two timestamps 2 × 8,191 seconds apart can use the same EIP-4788 buffer slot. About one third of the 8,191 beacon roots present just before the upgrade are overwritten early (the earliest after about 4.6 hours). A lookup reverts rather than returning a wrong root. Timelocks, vesting, governance voting and delay periods, and cooldowns counted in block numbers end early. Per-block interest, rewards, issuance, and rate limits grow per hour, and TWAP windows defined in block counts average over a shorter period. Off-chain tools that compute genesis_time + 12 × slot must switch to a per-interval schedule or to block timestamps. L2 and bridge finality delays, challenge periods, and timeouts measured in L1 block counts become shorter, while those in seconds stay the same. If a client implements retention with real-time timers, timers computed before the transition only keep data longer than needed, which still conforms to the spec.

Phased approach, alternatives, and progress

The source splits the work into three phases. Phase 1 is variable slot time infrastructure: removing the 12-second assumption and replacing functions such as compute_time_at_slot and the fork transition logic with a schedule-based design. Phase 2 is CL performance characterization, using devnets and benchmarks to measure consensus layer bottlenecks (blob propagation, proof aggregation, local block production time). Phase 3 is reducing the slot time iteratively based on those results. Ten seconds is a conservative placeholder and may change before deployment depending on the Phase 2 results. If Phase 2 shows that 10 seconds is still too hard, the slot time in the HEZE_FORK_EPOCH entry can be raised up to 12 seconds, in which case r = 1 and all rescaled values and the base fee rules become exactly the same as today. The source status is Draft, so the content may still change. In the core developer call records, it was accepted as a Hegotá candidate (PFI) at 08.06 ACDC #184, and it was settled that when the slot time is reduced, the per-block gas limit and blob count are reduced too so that per-second throughput is maintained. At 10.01 ACDC #188 it moved to Considered for Inclusion (CFI) for Hegotá, and the actual reduction from 12 to 10 seconds must go through further validation before inclusion is confirmed. At 10.12 ACDT #100 it was settled that EIP-8198 would be included in heze-devnet-2 together with EIP-7805 (FOCIL), EIP-8015, and EIP-8365, while the slot length stays at 12 seconds. This means the feature goes in, while the actual reduction waits on more client readiness.

Original EIP · ← EIPs