EIP-8198: Quick Slots

Introduce variable slot timing infrastructure and reduce slot duration.

Abstract

This EIP makes the slot duration a scheduled consensus-layer configuration — a SLOT_DURATION_SCHEDULE whose entries each activate a slot duration at an upgrade epoch — rather than a compile-time constant, then uses that infrastructure to reduce slot duration from twelve to ten seconds. Duration-dependent consensus quantities are rescaled by the exact slot-duration ratio, applied inline in each formula, so that issuance, penalties, and churn are unchanged per unit of wall-clock time, and the data column sidecar retention window is redefined in milliseconds so that it too is unchanged in wall-clock time. The execution layer is deliberately decoupled: it never consumes the slot duration, and gas and blob throughput per unit time are maintained through coordinated parameter updates around the transition.

Motivation

Slot time is the heartbeat of Ethereum’s user experience. Every second shaved off means faster transaction landings, faster exchange deposits, and faster real-world payments. But the benefits extend well beyond UX.

User experience

Twelve seconds is slow. It is perceptible in payments, exchange deposits, and every on-chain interaction. Reducing slot time brings Ethereum closer to the responsiveness users already expect from modern financial infrastructure as well as other chains including L2s.

DEX pricing and MEV

Arbitrage losses of AMM liquidity providers scale roughly with the square root of the inter-block time. Going from twelve to ten seconds cuts them by about 9%, tightening on-chain pricing and reducing value extracted from users. MEV extraction is also non-linear in slot time: shorter slots compress the surplus available per block.

Fast finality and fast confirmation rule

Faster slots pull forward time-to-finality and time-to-fast-confirmation. As further improvements roll out on these metrics, faster slots compound the decreases.

Censorship-resistance

More block proposers per unit of time increases censorship resistance, giving more opportunities for transactions to be included in the chain. In particular, economic censorship resistance increases too, i.e., the cost of bribing sequential block proposers to “turn off” access of a transaction or all transactions to the chain.

Preconfirmation complexity

Preconfirmation protocols exist to paper over twelve-second latency. Reducing slot time attacks the root cause, decreasing the need for additional trust assumptions and protocol complexity layered on top.

Rollups and interoperability

L2s inherit the L1’s slot duration for some of their interoperability. For instance, some L2s wait a certain number of blocks before processing user deposits, so L1 to L2 deposits and messages become faster in wall-clock time. Intent-based bridges also frequently wait for inclusion on L1 to fill a user order on a separate domain.

Based rollups inherit L1 block time as their sequencing interval. Faster L1 slots mean faster based rollups, with zero changes required on the rollup side.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

All arithmetic in this specification uses integer division (truncating toward zero) unless otherwise noted.

Parameters

The slot-duration ratio at an epoch is the rational number r = get_slot_duration_ms(epoch) / get_slot_duration_ms(GENESIS_EPOCH), 5/6 for the ten-second era. It is never evaluated on its own: a formula applying r or r² multiplies by the numerator and divides by the denominator last.

Slot duration schedule

SLOT_DURATION_SCHEDULE is a list of records, each holding only an activation epoch and a slot duration in milliseconds. It replaces the standalone SLOT_DURATION_MS; the helper get_slot_duration_ms(epoch) returns the duration in effect at epoch.

The schedule MUST satisfy the following:

• It MUST begin with an entry at GENESIS_EPOCH carrying the historical slot duration (12,000 ms). This entry is the baseline of the slot-duration ratio.
• Entries MUST be sorted by epoch in strictly ascending order.
• Every subsequent entry MUST activate at the epoch of a network upgrade, EIP8198_FORK_EPOCH or later. Slot duration changes between upgrades are not supported; the upgrade’s fork version separates the networking domains.
• The slot duration in each entry MUST be a positive multiple of 1,000 ms, so that every slot boundary has an exact integer-second timestamp.

On mainnet, this EIP adds an entry at EIP8198_FORK_EPOCH with a slot duration of 10,000 ms.

Intra-slot deadlines

Intra-slot deadlines keep their existing configuration as basis points of the slot duration: the attestation, aggregate, sync message, and contribution deadlines and the proposer reorg cutoff (ATTESTATION_DUE_BPS, PROPOSER_REORG_CUTOFF_BPS, and so on), and any further deadlines defined by the forks active at EIP8198_FORK_EPOCH, such as payload or inclusion list deadlines. The helper converting them to millisecond offsets, get_slot_component_duration_ms, applies them to the slot duration in effect at the fork, get_slot_duration_ms(EIP8198_FORK_EPOCH), rather than to the removed SLOT_DURATION_MS. Schedule entries carry no deadlines, and changing a deadline does not require a schedule entry. A later upgrade that changes the slot duration or the timing of duties MUST define its own deadline rule. Duty schedulers MUST keep millisecond precision, since deadlines are not generally whole seconds.

Wall-clock timeline

Slot boundaries after a duration change are no longer aligned to genesis at a fixed duration, so the mapping between wall-clock time and slot number becomes piecewise over the schedule’s slot duration eras: each era runs at its own slot duration, starting from the end of the previous era. All conversions between time and slot MUST be derived from this piecewise timeline, in particular:

• Execution payload timestamp validation (compute_time_at_slot).
• The fork choice store clock, which derives the current slot and the time into the slot from compute_slot_at_time_ms and compute_time_at_slot_ms, including store initialization from an anchor state past a duration change (e.g. checkpoint sync).
• Every intra-slot timeliness measurement (attestation timeliness recording, the proposer reorg cutoff, and any other intra-slot deadline checks defined by the forks active at EIP8198_FORK_EPOCH), which measures the time into the slot from the slot’s start time rather than as time % SLOT_DURATION_MS.
• The gossip slot-range validation gates, duty schedulers, expiry and gossip-scoring windows, and light-client local-clock slot derivation.

Consensus economics

No consensus constant changes value. Instead, the duration-dependent per-epoch rates are rescaled by r:

Rewards and penalties are priced at the slot duration of the epoch they pay for, not the epoch in which they are processed: attestation rewards and penalties for the previous epoch use the previous epoch’s duration, the inactivity penalty likewise, and the proposer reward for a newly included attestation is priced at the attestation’s target epoch so that the proposer’s share matches the attesters’ rewards for the same epoch.

For the churn limits, the minimum and maximum bounds are applied before scaling — so the bounds are scaled too — and the EFFECTIVE_BALANCE_INCREMENT rounding is applied once, after scaling. Exit and consolidation epochs assigned before a duration change keep their assigned epochs and consumed quota.

Epoch- and slot-denominated quantities — withdrawability and slashing windows, sync committee periods, SLOTS_PER_EPOCH, per-payload and per-epoch processing limits — keep their counts, so their wall-clock spans scale with the slot duration.

Data availability retention

Data column sidecars

The data column sidecar retention window is redefined in wall-clock time by MIN_BLOB_DATA_RETENTION_MS, set to the duration of the window it replaces: 4,096 epochs of twelve-second slots.

A new helper, compute_blob_data_retention_start_epoch(epoch), returns the epoch containing the instant MIN_BLOB_DATA_RETENTION_MS before the start of epoch, measured on the piecewise timeline. The retention window starts at max(compute_blob_data_retention_start_epoch(current_epoch), FULU_FORK_EPOCH), and this bound replaces the epoch-count bound in:

• Status v2, when determining earliest_available_slot;
• DataColumnSidecarsByRange v1 and DataColumnSidecarsByRoot v1, as the lower end of data_column_serve_range.

The blob sidecar Req/Resp messages are already deprecated as of FULU_FORK_EPOCH + MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, so their retention window needs no treatment.

Blocks and other epoch-denominated windows

The block retention window, compute_min_epochs_for_block_requests() (33,024 epochs on mainnet), and all other epoch-denominated windows keep their epoch counts, so every object is served for the same number of epochs whether it was created before or after a duration change.

Execution layer

The execution layer does not consume the slot duration (see Execution layer decoupling). A slot duration change is instead accompanied by the following execution-layer parameter updates.

Gas limit

Gas throughput per unit of wall-clock time is maintained by coordinating the gas limit ahead of the upgrade rather than by a consensus-enforced one-time scaling: the ordinary gas limit adjustment rule (±1/1024 per block) applies at and across the transition. The gas limit target is to be lowered in advance — using the advisory GAS_LIMIT_SCHEDULE and proposer target_gas_limit preferences — so that the per-block gas limit arrives at the value preserving gas-per-second throughput (× r, e.g. 100M → ~83.3M for 12 → 10s) by the time the new slot duration activates. Alternatively, when the transition ships alongside a planned gas limit increase, the post-transition target can simply be set to the planned per-second throughput expressed at the new slot duration.

Base fee responsiveness

The maximum per-block base fee change of 1/8 was calibrated for twelve-second blocks; left unchanged under ten-second slots, the base fee would react to congestion 20% faster per unit of wall-clock time. The base fee update rule therefore receives a one-time constant re-parameterization at the upgrade, hard-coded on the execution layer without reference to the slot duration: the maximum per-block change becomes the rational BASE_FEE_MAX_CHANGE_NUMERATOR / BASE_FEE_MAX_CHANGE_DENOMINATOR = 5/48 (an effective denominator of 9.6), with the multiplication performed before the division:

base_fee_per_gas_delta = (
    target_fee_gas_delta
    * BASE_FEE_MAX_CHANGE_NUMERATOR
    // BASE_FEE_MAX_CHANGE_DENOMINATOR
)

BASE_FEE_MAX_CHANGE_NUMERATOR is a new execution-layer constant, 1 before the upgrade, so the pre-upgrade rule is the existing one written in the same form. The max(..., 1) floor on increases and the gas target computation are unchanged.

The value 5/48 matches the reaction rate per unit of wall-clock time to first order, i.e. exactly for per-block changes that are small relative to the maximum. Because the update compounds per block, no single symmetric value preserves both extremes: at full blocks the base fee rises about 1.0% faster per second than before, and at empty blocks it falls about 1.1% slower. The compounded matches, 1.125^(5/6) − 1 (about 1/9.70) for increases and 1 − 0.875^(5/6) (about 1/9.50) for decreases, bracket 5/48.

Blob schedule

A slot duration change is accompanied by a BLOB_SCHEDULE entry (as defined in EIP-7892) at the upgrade, with blob targets and limits chosen jointly with the execution layer. Integer rounding does not in general preserve blob throughput per unit time exactly (for 12 → 10s the current target of 14 scales to 11.67 and the maximum of 21 to 17.5), and the target/maximum ratio interacts with execution-layer fee mechanics. The values are not final and may be folded into a concurrent blob capacity change. The provisional values are a target of 12, a maximum of 18, and a BLOB_BASE_FEE_UPDATE_FRACTION of 12018519.

At full blocks the excess blob gas grows by (max − target) × GAS_PER_BLOB per block, and at empty blocks it shrinks by target × GAS_PER_BLOB, so the fastest rise and the fastest fall of the blob base fee per second are proportional to (max − target) / (BLOB_BASE_FEE_UPDATE_FRACTION × slot duration) and target / (BLOB_BASE_FEE_UPDATE_FRACTION × slot duration). The provisional values keep both rates and the maximum/target ratio of 1.5 unchanged, with an update fraction of 11684671 × (12 / 14) × (12 / 10) ≈ 12018519. Blob throughput per second rises by about 2.9% at both the target (1.2 instead of 1.17 blobs per second) and the maximum (1.8 instead of 1.75).

The alternative candidate, a target of 12, a maximum of 17, and an update fraction of 11684671 × (5 / 7) × (12 / 10) ≈ 10015432, keeps the fastest rise per second but makes the fastest fall 20% faster per second. It lowers the maximum/target ratio to about 1.42 and gives about 2.9% more target and 2.9% less maximum throughput per second.

The excess blob gas carries over the upgrade unchanged, so changing BLOB_BASE_FEE_UPDATE_FRACTION from F to F' moves the blob base fee at the first block from p to p^(F / F') (in wei). With the provisional values this is a small decrease (p^0.972). With the alternative it would be an increase (p^(7/6)), which then decays.

System contracts

The EIP-4788 beacon roots contract and the EIP-2935 block hash history contract keep their 8,191-entry buffers; the buffer lengths are part of the deployed contracts and are deliberately not changed.

Networking

• Slot timing changes coincide with network upgrades, so topics re-key under the upgrade’s fork digest as usual; clients SHOULD subscribe to the new-digest topics ahead of the upgrade epoch.
• ATTESTATION_PROPAGATION_SLOT_RANGE remains 32 slots (one epoch plus margin); its wall-clock duration scales with the slot duration.
• EPOCHS_PER_SUBNET_SUBSCRIPTION remains 256 epochs, so long-lived attestation subnet subscriptions rotate more often in wall-clock time (every ~22.8 hours instead of ~27.3 hours for 12 → 10s).
• Absolute wall-clock allowances — MAXIMUM_GOSSIP_CLOCK_DISPARITY and the Req/Resp timeouts (TTFB_TIMEOUT, RESP_TIMEOUT) — MUST NOT be rescaled.
• The gossipsub seen_ttl parameter follows its defining formula (two epochs) computed on the piecewise timeline, so it remains correct when the window crosses a duration change.

Transition parameters

The ten-second transition consists of the following values. Values marked TBD are to be set before deployment.

Rationale

A phased approach to shorter slots

Nobody knows the safe minimum slot duration with today’s client implementations, and the bottleneck is not picking a number: it is the twelve-second assumption hardcoded across every consensus and execution client. Rather than stalling on the choice of a number, this EIP separates the work into three phases:

1. Variable slot timing infrastructure — Remove the assumption that slots are twelve seconds. Update background task scheduling, timing constants, functions such as compute_time_at_slot(...), and fork transition logic to derive timing from a scheduled configuration.
2. CL performance characterization — Systematically identify consensus layer bottlenecks through devnets and benchmarks, analogous to the execution layer’s bloat-nets and perf-nets. Current understanding of blob propagation limits, attestation aggregation capacity, and local block building times remains incomplete.
3. Iterative slot time reduction — Cut slack from the slot duration based on the results of phase 2. Address client constraints, reduce further as headroom emerges, iterate.

Phase 1 has value regardless of the final number. Delivering it as a fork forces client teams to audit and remove the hardcoded assumptions. Once that work is done, a future slot duration change becomes a new SLOT_DURATION_SCHEDULE entry and a rule for intra-slot deadlines rather than an invasive refactor, much as blob throughput changes became BLOB_SCHEDULE entries. Fallback describes what the upgrade delivers if ten seconds proves infeasible.

Why ten seconds

This EIP pairs the variable slot timing infrastructure with a conservative reduction, as a non-headliner change. Ten seconds is a reasonable placeholder that provides a real UX win, before future reductions compound the benefits. The exact target follows from preliminary phase 2 performance characterization and may be revised before deployment.

Why upgrades only

The schedule deliberately does not support BPO-like slot duration changes between upgrades: the strong assumption is that slot time reductions always ship with a network upgrade. Contracts, tooling, and L2s with dependencies on the slot time adapt on upgrade cadence, not on shorter notice; and tying changes to upgrades means the fork version already separates the networking domains, so the fork digest need not be bound to the active slot duration. The schedule remains the data structure of record because timeline computations must accumulate over all historical durations — for example, deriving the current slot from a timestamp.

Exact ratios instead of rescaled constants

Duration-dependent rates are rescaled by applying the slot-duration ratio inline in each formula, with the division deferred, rather than by pre-computing rounded replacement constants. This keeps SLOT_DURATION_SCHEDULE the single source of truth — no shadow set of per-duration constants to keep consistent — and it applies the exact ratio: the effective base reward factor for the intended change is exactly 64 × 5/6 = 53.33, not a rounded 53, so there is no systematic issuance drift (the residual truncation error is at most one Gwei per computation).

Pricing rewards and penalties at the epoch they pay for avoids a hole in the issuance schedule at the boundary: without it, the first epoch after a reduction would pay the previous (longer) epoch’s attestations at the new (lower) rate — ~17% less than earned for 12 → 10s — and the inactivity penalty for that epoch would come out ~31% too small.

Constant scaling

The general principle is: do not adjust a quantity unless there is a concrete security or economic failure from leaving it unchanged. Most epoch- and slot-denominated constants have generous margins: EPOCHS_PER_SLASHINGS_VECTOR shrinks from ~36 to ~30 days but remains far longer than any plausible attack window; MIN_VALIDATOR_WITHDRAWABILITY_DELAY shrinks from ~27.3 to ~22.8 hours but slashing detection takes minutes. SLOTS_PER_EPOCH remains 32; the resulting ~5.3 minute epochs mean finality improves from ~13 to ~10.7 minutes for free. Three per-epoch rates are rescaled by the slot-duration ratio, and one window is redefined in wall-clock time.

Issuance. The base reward scales linearly with epoch duration to preserve annualized issuance.

Inactivity leak. The cumulative penalty is quadratic in epoch count (K^2), so the penalty scales by the square of the epoch ratio, folded into the penalty denominator. As a divisor, a larger denominator produces a smaller per-epoch penalty, compensating for the faster epoch cadence. INACTIVITY_SCORE_BIAS cancels algebraically between the score numerator and penalty denominator and needs no adjustment. INACTIVITY_SCORE_RECOVERY_RATE governs post-leak decay; modestly faster recovery is benign.

Churn limits. Preserve the wall-clock weak subjectivity period (see Weak subjectivity period). Scaling after the quotient division and the min/max bounds leaves the quotients and Gwei-denominated bound constants unchanged.

Data availability retention. External consumers, such as optimistic rollups with ~7-day challenge periods, depend on blob data remaining available for a period of wall-clock time, not a number of epochs. Blob data throughput per unit time is kept constant across the change, so keeping the window constant in wall-clock time also keeps a node’s blob storage load constant, whereas keeping the epoch count would silently shorten the window. The window is defined directly in milliseconds, with its start computed on the piecewise timeline, rather than by rescaling an epoch count: this is exact across any number of duration changes. Before any change, the window covers exactly the 4,096 epochs it covered before. After a change to ten-second slots, the number of epochs it covers rises one epoch at a time to about 4,916, and its start never moves backwards. A node retaining the inherited window when a change activates is therefore never asked for data it may already have pruned, and never serves a shorter wall-clock history, so it needs neither over-retention before the change nor backfill after it.

The block retention window is deliberately left in epochs. At ten-second slots, it remains comfortably above the weak subjectivity period, which is derived independently from the churn limits and must stay below the block retention window. The block retention window wall-clock span shrinks gradually as more of its epochs fall in the shorter era, from ~146.8 to ~122.3 days for 12 → 10s.

Deadlines in basis points, pinned to the fork

Intra-slot deadlines stay in basis points of the slot duration, as they are today, and are not carried in the schedule. Basis points were introduced precisely so that the slot duration could change without restating each deadline, and keeping them avoids a parallel set of millisecond configuration values. The schedule stays a pure record of historical slot durations, which is what the timeline computations need.

Deadlines are applied to the slot duration at the fork epoch of this EIP rather than to whichever duration is in effect. Not every slot component scales linearly with the slot duration: propagation, aggregation, and block building carry fixed overheads, so each deadline may need individual tuning when the duration changes. Pinning the deadlines to the fork means a later duration change cannot silently rescale them; that upgrade must state its own deadline rule. For this upgrade, if phase 2 testing shows that a deadline should not be the same fraction of a ten-second slot as of a twelve-second one, its basis-point value is changed as an ordinary configuration update.

Gas limit

An earlier design enforced a one-time gas limit rescale in consensus at the transition. This was dropped: it forced bids to a specific gas limit regardless of proposer preferences, and doing it precisely on the execution layer would leak the slot duration into execution specs. Coordinating the gas limit down ahead of the upgrade achieves the same throughput continuity with no new consensus rule — the ordinary ±1/1024 adjustment reaches the ~17% lower target in a few hours of advance voting — and validator sovereignty over the gas limit is untouched. If coordination fails, the downside is bounded (see Throughput at the transition).

Execution layer decoupling

The execution layer is kept unaware of the slot duration. Its diff for a slot duration change is a one-time base fee constant update and a blob schedule entry, both ordinary fork-activated parameter changes. This preserves the separation of concerns between the layers, avoids introducing a consensus-timing dependency into execution clients, and keeps the EIP’s execution-layer footprint minimal.

Fallback

If phase 2 shows that ten seconds is not yet feasible, the slot duration of the entry at EIP8198_FORK_EPOCH can be raised, up to twelve seconds, without changing the rest of this EIP. At twelve seconds r is 1 and every rescaled quantity keeps its current value, so the upgrade still delivers a properly characterized consensus layer, client code free of hardcoded timing assumptions, and the readiness to reduce the slot duration in a later upgrade.

Backwards Compatibility

Clients

This EIP requires a hard fork. The consensus layer bears most of the change: clients must replace genesis-anchored twelve-second timing derivations with the piecewise timeline, including in the fork choice store clock, duty scheduling, and retention timers. The execution layer impact is limited to the parameter updates in Execution layer.

Clients commonly implement retention with wall-clock timers. A timer computed for an object before a duration change and left unchanged keeps the object longer than required. This is compliant, but a client that wants the exact window must compute the expiry on the piecewise timeline: the remaining epochs of the current era at that era’s epoch duration, plus the remaining epochs at the new era’s epoch duration.

Applications and tooling

Anything that converts between block counts and wall-clock time under a twelve-second assumption changes behavior at the transition. Logic based on block.timestamp is unaffected. For 12 → 10s, a period of N blocks lasts about 17% less time, and a per-block quantity is spent about 20% faster. In particular:

• System contracts. The EIP-4788 and EIP-2935 buffers keep 8,191 entries, so their wall-clock lookback shrinks from ~27.3 to ~22.8 hours. A contract that assumes at least a day of beacon roots or block hashes is available no longer has it. Across the upgrade, the mixed twelve- and ten-second spacing lets two timestamps 2 × 8,191 seconds apart share an EIP-4788 buffer index, so about a third of the last 8,191 pre-upgrade beacon roots are overwritten early, the earliest after about 4.6 hours. Lookups for them revert rather than return a wrong root.
• Durations counted in blocks. Timelocks, vesting schedules, governance voting and delay periods, and cooldowns expressed in block numbers end sooner in wall-clock time.
• Rates per block. Interest, rewards, or emissions accrued per block, and rate limits enforced per block, increase per unit of time.
• Oracle windows counted in blocks. A TWAP or similar average over a fixed number of blocks covers a shorter period, so it smooths over less time.
• Off-chain tooling. Tools that compute slot times as genesis_time + 12 × slot, estimate confirmation times, or schedule jobs by block number must switch to the piecewise timeline or to block timestamps.
• L2s and bridges. Finality delays, challenge periods, and timeouts measured in L1 blocks shrink in wall-clock time; those measured in seconds are unaffected.

Security Considerations

Network propagation

Tighter slots shrink the window for block propagation, validation, and attestation aggregation. The intra-slot deadlines for a shorter slot duration are its basis-point values applied to that duration, and must be chosen such that the resulting durations remain feasible for real-world network conditions. Phase 2 (CL performance characterization) is explicitly designed to surface these bottlenecks.

Validator hardware requirements

Faster blocks raise per-second computational and bandwidth demands, all else equal, so validator hardware distribution should be considered when choosing the slot duration. Load per block falls, however: gas and blobs per block decrease in proportion to the slot duration.

Weak subjectivity period

The weak subjectivity period depends on the rate at which the validator set can turn over. Without churn limit adjustment, per-epoch churn rates applied over more epochs per year would allow the validator set to change faster in wall-clock time, shrinking the safe window for weak subjectivity checkpoints. This EIP scales churn limits to preserve the current wall-clock churn rate, approximately maintaining the existing weak subjectivity period: only its MIN_VALIDATOR_WITHDRAWABILITY_DELAY component, a fixed epoch count, shrinks in wall-clock time (at current stake, from ~7.0 to ~6.8 days for 12 → 10s). It remains far below the 33,024-epoch block retention window.

Throughput at the transition

Because the gas limit transition relies on advance coordination rather than a consensus rule, a failure to coordinate results in a temporary gas-per-second overshoot of up to 20% (for 12 → 10s) while ordinary gas limit voting converges. The overshoot is bounded, self-correcting, and does not affect consensus validity.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Carl Beekhuizen (@carlbeek), "EIP-8198: Quick Slots [DRAFT]," Ethereum Improvement Proposals, no. 8198, March 2026. Available: https://eips.ethereum.org/EIPS/eip-8198.