Reduce Slot Times

Summary

Reduce Solana's target slot time from 400ms to 200ms in four feature-gated steps:

1. 350ms slots
2. 300ms slots
3. 250ms slots
4. 200ms slots

Each step keeps ticks_per_slot fixed at 64, keeps leader windows fixed at 4 slots, and keeps epochs fixed at 432,000 slots. Per-slot work limits are reduced in proportion to the target slot time so the corresponding wall-clock rate remains approximately unchanged. slots_per_year is increased by the inverse ratio so inflation remains unchanged from a wall-clock perspective. Precise values are called out below.

For Alpenglow validators, each effective slot-time stage also scales the Validator Admission Ticket (VAT) so the admission cost remains approximately 0.8 SOL per day: 1.6 SOL at 400ms, 1.4 SOL at 350ms, 1.2 SOL at 300ms, 1.0 SOL at 250ms, and 0.8 SOL at 200ms.

Each feature gate becomes effective one epoch after activation. For example, a feature that gets applied during transition from epoch N to N+1 takes effect for slots starting in epoch N+2. This is so Turbine can cleanly apply the reduced shred limits.

Motivation

Shorter slots reduce confirmation and finalization latency for users. Any consensus or commitment threshold measured in slots takes less wall-clock time as slot time decreases.

Keeping the leader span at 4 slots also shortens the wall-clock duration of a single leader window. A leader currently controls a nominal 1.6s window. At 200ms slots that window is 800ms. This improves market structure by reducing the worst-case time a leader can delay, reorder, or selectively include transactions before the next leader has an opportunity to produce a block.

Shorter slots also provide a finer-grained on-chain understanding of time. Applications that interpret freshness in slots, such as oracle consumers and propAMM-style market makers, can make decisions with a smaller slot-time quantization error.

The staged rollout is intended to discover timing, implementation, and operational problems at 350ms, 300ms, and 250ms before reaching 200ms. This lets client teams verify that the slot, leader-window, and epoch timing assumptions continue to close without changing the leader schedule or epoch schedule at the same time.

Because epochs remain fixed at 432,000 slots, each faster slot-time stage also shortens epoch wall-clock duration. SIMD-0357 charges VAT per admitted validator per epoch. Scaling VAT with the effective slot-time stage preserves the SIMD-0326 target of roughly 0.8 SOL per day instead of increasing the daily Alpenglow validator admission cost during the staged rollout.

New Terminology

No new protocol terminology is introduced.

This proposal refers to the following placeholder feature gates. Final feature IDs are TBD:

• reduce_slot_time_to_350ms
• reduce_slot_time_to_300ms
• reduce_slot_time_to_250ms
• reduce_slot_time_to_200ms

This proposal also uses the existing Validator Admission Ticket (VAT) term from SIMD-0326 and SIMD-0357.

Detailed Design

Each feature gate selects a new target slot duration. Implementations MUST use the effective target slot duration for the bank being produced or verified. If multiple slot-time feature gates are effective, implementations MUST select the lowest effective target slot duration.

Feature Activation Delay

Feature activation and feature effectiveness are separate for this proposal. A slot-time feature gate MUST take effect on a one-epoch delay. If a gate first becomes active in epoch E, all slots in epoch E MUST continue using the previous effective slot-time parameters, and the new target slot duration and derived limits MUST first apply at the first slot of epoch E + 1.

This delay is required because these gates reduce the maximum data and coding shreds per slot. Turbine and shred-fetch filtering can enforce shred limits outside the bank execution path, so they cannot rely on an execution-time feature transition being perfectly synchronized with block production and validation. The one-epoch delay gives validators an epoch of advance notice before network shred filtering starts enforcing the reduced limits.

The feature gates SHOULD be activated in order. Activating them in order is not required for value derivation, however. Integer limits are normative table values and MUST be assigned directly or derived from the original 400ms baseline values. Implementations MUST NOT repeatedly scale already-rounded values from a previous stage, because that can accumulate rounding error.

Timing Values

The slots_per_year values below use the Mainnet-Beta bank value of 78_892_314.984, as the 400ms baseline. Implementations MUST scale the bank's stored slots_per_year value according to the table below at each effective slot-time transition. rent_collector.slots_per_year MUST be updated with the same value.

Target	Feature gate
400ms	current
350ms	reduce_slot_time_to_350ms
300ms	reduce_slot_time_to_300ms
250ms	reduce_slot_time_to_250ms
200ms	reduce_slot_time_to_200ms

Target	ns/slot	tick ns	span	epoch	slots/year
400ms	400000000	6250000	1.6s	48h	78892314.984
350ms	350000000	5468750	1.4s	42h	90162645.696
300ms	300000000	4687500	1.2s	36h	105189753.312
250ms	250000000	3906250	1.0s	30h	126227703.974
200ms	200000000	3125000	0.8s	24h	157784629.968

Note that none of the above table values (except for slots_per_year for inflation) are explicitly in protocol and may deviate from reality, but they are expected to be useful for ensuring expected timing is understood.

Validator Admission Ticket Scaling

When the Alpenglow VAT mechanism specified by SIMD-0357 is active, implementations MUST burn the VAT amount for the slot-time stage effective at the slot where the burn is executed. Said differently, the VAT amount for feature activated during epoch E -> E+1 transition is used on the E+1 -> E+2 transition for admission into E+3. Before Alpenglow VAT is active, this section has no effect.

Effective target	Epoch	VAT
400ms	48h	1.6 SOL
350ms	42h	1.4 SOL
300ms	36h	1.2 SOL
250ms	30h	1.0 SOL
200ms	24h	0.8 SOL

SIMD-0357 performs VAT collection when a bank crosses an epoch boundary and computes the validator set for the next epoch. The VAT amount MUST be derived from the effective slot-time stage of the epoch being admitted, not merely from the current bank's slot-time stage.

For each vote account considered during the SIMD-0357 admission procedure, implementations MUST:

1. Determine the epoch being admitted.
2. Determine the slot-time stage effective for that admitted epoch.
3. Select the VAT amount from the table above.
4. Require the vote account to hold at least the selected VAT amount plus the required rent-exempt balance.
5. Subtract the selected VAT amount from every admitted vote account.
6. Record the subtraction in the bank and transfer the lamports to the incinerator account, as specified by SIMD-0357.

The SIMD-0357 maximum admitted validator count, sort order, tie handling, BLS public key requirement, vote-account funding source, and burn destination are unchanged.

Scaled Per-Slot Values

Integer values are scaled by trunc(current_400ms_value * target_slot_ms / 400). Truncating is used whenever the proportional value is fractional so the new value does not exceed the intended wall-clock budget.

Limit	400ms	350ms	300ms
Hashes/tick	62500	54687	46875
Max block CUs	60000000	52500000	45000000
Max writable acct CUs	24000000	21000000	18000000
Max vote CUs	36000000	31500000	27000000
Max data delta	100000000	87500000	75000000
Max data shreds	32768	28672	24576
Max coding shreds	32768	28672	24576
PER stake writes	4096	3584	3072

Limit	250ms	200ms
Hashes/tick	39062	31250
Max block CUs	37500000	30000000
Max writable acct CUs	15000000	12000000
Max vote CUs	22500000	18000000
Max data delta	62500000	50000000
Max data shreds	20480	16384
Max coding shreds	20480	16384
PER stake writes	2560	2048

The hashes_per_tick value MUST NOT be reduced by these feature gates when Alpenglow is active. Alpenglow's low-power PoH path should keep its active hashing behavior unchanged, currently expected to be one hash per tick.

If another feature gate changes one of the 400ms baseline limits before this SIMD activates, the slot-time feature implementation MUST compose with that feature by applying the same ratios to the active 400ms baseline. For example, if a future block-limit feature changes MAX_BLOCK_UNITS, the slot-time stages must use the new block limit multiplied by the target slot-time ratio.

For 100M CUs feature (SIMD-0286), the limits would look like so (anything not mentioned below would match the tables above): | Limit | 400ms | 350ms | 300ms | |-------|-------|-------|-------| | Max block CUs | 100000000 | 87500000 | 75000000 | | Max writable acct CUs | 40000000 | 35000000 | 30000000 |

Limit	250ms	200ms
Max block CUs	62500000	50000000
Max writable acct CUs	25000000	20000000

Runtime Changes

When a slot-time feature gate becomes effective for a bank after the one-epoch delay, the bank and its descendants MUST use the target values above for:

• ns_per_slot
• slots_per_year
• rent_collector.slots_per_year
• non-Alpenglow hashes_per_tick
• cost tracker block limits
• block accounts data size delta
• broadcast and shred-fetch shred limits
• partitioned epoch rewards stake-account stores per block
• Alpenglow VAT amount, if Alpenglow VAT is active

Snapshot restore and bank deserialization MUST reconstruct all non-persisted runtime values from the effective slot-time stage and the bank's slot. A validator restarting after activation or after an effective transition must produce and validate the same limits as a validator that remained online across the transition.

Snapshot serialization MUST also persist the effective timing values in the snapshot manifest. This proposal does not add new manifest fields, but the existing ns_per_slot, hashes_per_tick, and slots_per_year manifest values MUST change in snapshots taken at or after a slot-time feature's effective slot. Snapshots taken before the effective slot, including during the one-epoch delay after activation, MUST keep the previous effective values. For non-Alpenglow banks, snapshot manifests MUST serialize the following values:

Effective target	ns_per_slot	hashes_per_tick
400ms	400000000	62500
350ms	350000000	54687
300ms	300000000	46875
250ms	250000000	39062
200ms	200000000	31250

Effective target	slots_per_year
400ms	78892314.984
350ms	90162645.696
300ms	105189753.312
250ms	126227703.974
200ms	157784629.968

When Alpenglow is active, the hashes_per_tick manifest value MUST retain Alpenglow's active hashing behavior (set to None) instead of using the reduced table value.

Inflation calculations MUST account for slot ranges that cross one or more effective slot-time transitions. Historical slots before an effective transition use the previous slots_per_year; slots at or after the effective transition use the new slots_per_year. This preserves issuance from a wall-clock perspective even though the number of slots per epoch remains unchanged.

Shred validation MUST be slot-aware. Shreds for slots before a feature's effective slot are validated with the previous shred limit, including shreds in the one-epoch delay period after activation. Shreds for slots at or after the effective slot are validated with the newly effective limit.

Notable Non-Changes

This proposal intentionally does not change:

• Leader span: still 4 slots.
• Ticks per slot: still 64.
• Epoch length: still 432,000 slots.
• solana-clock and SDK constant values. Agave may dynamically scale bank values, but solana-sdk constants remain unchanged initially.
• Grace ticks.
• Timely Vote Credits grace.
• Repair delay, including the 250ms repair defer threshold.
• Non-Alpenglow vote transaction costs.
• fee_rate_governor.target_signatures_per_slot.
• Blockhash queue and status cache max entries.
• Gossip DEFAULT_MS_PER_SLOT heuristics, including the CRDS entry eviction/retention window, the freshness threshold for accepting pull responses, and the scoring policy for which CRDS values to include in pull responses.

Note that some of these are out of protocol (Agave client defaults), but are included here for completeness.

Edge Cases

Implementations should pay special attention to:

• Feature gates activated at genesis, where the feature is active from slot 0 but the reduced target slot time is not effective until epoch 1 unless genesis explicitly defines the reduced target as the baseline.
• Feature gates activated after snapshots, where runtime-only values must be rebuilt during restore.
• Multiple active slot-time gates, where the lowest target slot time whose one-epoch delay has elapsed wins.
• The activation epoch for each slot-time gate, where bank execution, block packing, broadcast, shred-fetch, and shred validation must continue using the previously effective limits.
• Alpenglow activation, where hashes_per_tick must not be reduced by these feature gates.
• Integer rounding, especially the 350ms and 250ms hashes_per_tick values.
• Inflation calculations for epochs and rewards that span effective transition slots.
• Alpenglow VAT calculations for admitted epochs that cross feature activation and effective-transition boundaries.
• Shreds received around activation and effective-transition boundaries, which must be validated using the effective slot-time stage for the shred's slot.

Validator Components Affected

• Transaction Execution (Runtime): Bank timing fields, inflation slot-to-time conversion, cost tracker, block data size limits, PER distribution limits, and Alpenglow VAT amounts change by feature gate.
• Virtual Machine: No direct VM semantic change. Programs may observe finer slot-time granularity through sysvars and RPC-derived timing.
• Block Packing: Leaders must pack smaller per-slot CU, account CU, vote CU, accounts-data, shred, and PER write budgets.
• Consensus: Feature-gated slot duration changes are consensus critical. Leader windows remain 4 slots but become shorter in wall-clock time.
• Gossip: Vote and epoch-slot traffic increase per wall-clock time as slots get faster. Gossip uses of DEFAULT_MS_PER_SLOT to derive epoch duration for CRDS entry retention, pull-response freshness, and pull-response value scoring continue to use 400ms for the slot time portion of these calculations.
• Turbine: The per-slot data and coding shred limits are reduced proportionally after the one-epoch effectiveness delay, so shred filtering and bank execution enforce the same slot-aware limits.
• Snapshots: Snapshot manifests must persist the effective ns_per_slot, hashes_per_tick, and slots_per_year values, and snapshot restore must reconstruct effective runtime limits. Snapshot interval policy is not changed by this proposal.
• On-Chain Core BPF Programs: No direct program interface change. Programs that interpret slot distance as wall-clock time may need updates.
• Other: SDKs, RPC clients, explorers, and off-chain systems that use static slot-time constants will temporarily disagree with chain reality.

Alternatives Considered

Change Slots Per Leader Span

One alternative is to increase the number of slots in each leader span as slot time decreases, keeping the leader window close to the current 1.6s wall-clock duration. For example, a 200ms slot time would use 8 slots per leader span.

This preserves leader-window duration but requires the leader schedule to become dynamic across feature activations. It affects code that computes leader-window boundaries, leader schedule offsets, next-leader routing, replay propagation, Alpenglow parent-ready behavior, and related client assumptions. The experimental Agave implementation that changes leader span and epoch length shows this introduces significant code complexity and therefore higher risk of mistakes.

This proposal keeps the leader span at 4 slots and instead steps the slot time down gradually. That approach directly tests whether the shorter slot and leader-window timings close without introducing a simultaneous leader schedule change.

Increase Slots Per Epoch

Another alternative is to increase slots_per_epoch as slots get faster so an epoch remains approximately two days. At 200ms slots this would require 864,000 slots per epoch.

This preserves epoch wall-clock duration, but requires dynamic epoch schedule handling and increases client implementation risk. Existing code commonly uses epoch boundaries to derive leader schedules, epoch stakes, rewards, and wall-clock estimates. Changing epoch length at the same time as slot time increases the blast radius.

This proposal keeps epochs at 432,000 slots. Epochs therefore become shorter in wall-clock time, reaching approximately one day at 200ms slots. That tradeoff is acceptable for a staged rollout and gives the network faster feature activation cadence.

This alternative would also preserve the original VAT amount per epoch, because epoch wall-clock duration would remain approximately unchanged. Since this proposal keeps epochs fixed at 432,000 slots, it instead scales VAT per epoch to preserve the same wall-clock admission cost.

Leave VAT At 1.6 SOL Per Epoch

VAT could remain fixed at 1.6 SOL per admitted validator per epoch. This would require no change to the SIMD-0357 VAT amount, but it would increase the daily Alpenglow validator admission cost as epochs get shorter.

At the 200ms stage, epochs last roughly 24 hours, so a fixed 1.6 SOL VAT would double the original SIMD-0326 daily VAT target. This proposal scales VAT at each stage instead.

Scale VAT Only At 200ms

VAT could remain fixed through the 350ms, 300ms, and 250ms stages, then drop from 1.6 SOL to 0.8 SOL only once 200ms slots become effective. This would preserve the original daily VAT target at the final stage, but not during the intermediate stages. Those stages may run long enough that the temporary increase in daily VAT cost becomes meaningful for operators.

Reduce Slots Per Leader Span While Keeping 400ms Slots

A third alternative is to keep 400ms slots and reduce the leader span, for example from 4 slots to 2 slots. This gets some of the shorter-leader-window market-structure benefit without changing slot time.

The downside is that it does not provide finer-grained slot time for market makers, oracle freshness checks, or applications that reason about time in slots. It also spends implementation and operational risk on leader rotation without moving the chain toward shorter slots. If a 2-slot leader span exposes leader-rotation problems at 400ms slots, the network may be stuck with 400ms slots for a while before it can safely attempt 200ms slots, where a 2-slot leader span would imply 400ms leader rotation.

Impact

Dapp developers and off-chain services get faster slot-level feedback and lower latency, but should stop assuming 400ms * slots is a stable wall-clock conversion. SDK and RPC consumers that need wall-clock estimates should prefer cluster-provided parameters once available.

Validators get shorter leader windows and less time to receive, replay, and build on the previous leader's block. The proportional per-slot reductions keep execution, account writes, allocation, and Turbine data budgets close to the current wall-clock rate, but voting and gossip activity increase because there are more slots per wall-clock interval.

Alpenglow validators get a lower VAT per admitted epoch as each slot-time stage becomes effective. From a wall-clock perspective, the target remains roughly 0.8 SOL per day throughout the staged rollout. Validator operators should update vote-account funding alerts at each effective slot-time stage.

Core contributors need to remove or audit static slot-time assumptions in runtime, consensus, Turbine, gossip, repair, RPC, CLI, tests, and client heuristics. Core contributors also need to update Alpenglow VAT collection tests so the VAT amount composes with the one-epoch slot-time effectiveness delay. Over time, these parameters should move on chain so SDK constants do not need to encode cluster reality.

Security Considerations

This is a consensus-breaking change and MUST be feature-gated. Validators that do not implement the effective slot-time stage, including the one-epoch delay, may produce or accept blocks, shreds, or rewards using the wrong limits.

Shorter slots reduce the time available for leader handoff, block propagation, replay, and vote landing. The staged rollout is part of the safety mechanism: each stage should be observed under production conditions before activating the next.

The proportional reductions are required to avoid accidentally increasing per-second execution, write, allocation, and shred budgets. Without these reductions, shorter slots would increase validator resource requirements and could harm liveness.

Inflation code must use wall-clock-equivalent slot accounting. Failing to scale slots_per_year, or mishandling effective-transition boundaries, could change issuance.

Alpenglow VAT collection must use the effective slot-time stage of the epoch being admitted. Applying a lower VAT amount too early could admit validators that should still be excluded under the previous funding requirement. Applying it too late could exclude validators that should be admitted under the lower funding requirement.

Validators must not enforce a reduced shred limit during a feature's one-epoch delay period. Doing so could cause Turbine or shred-fetch filtering to drop valid shreds before execution and block validation have switched to the new limits.

Drawbacks

Faster leader spans make it harder for clients and searchers to target the right leader. Fanout can compensate, but it may reduce transaction privacy and increase network load.

Non-Alpenglow vote transaction costs are not changed. Validators therefore pay more vote fees per wall-clock time as slots get faster, doubling at 200ms slots. Alpenglow VAT is scaled by this proposal, but this does not reduce non-Alpenglow vote transaction fees.

Gossip traffic for votes and epoch slots increases with slot rate, also doubling at 200ms slots.

Because blockhash and status cache max entries are not changed, any user-facing or client-facing behavior measured in number of slots may become shorter in wall-clock time. This is accepted as part of the smaller initial change surface.

Backwards Compatibility

This proposal is not backwards compatible for validators. New feature gates change consensus-critical bank, block, shred, and Alpenglow VAT limits.

The SDK constants will be out of sync with chain reality until the SDK is updated or the parameters are made available on chain. In particular, static constants for default slot duration, ticks per second, slots per year, and slot-to-time conversion may continue to describe the old 400ms assumption while the running cluster uses 350ms, 300ms, 250ms, or 200ms banks. Some short-term light breakage in clients that use these constants is tolerable in order to ship the staged reduction sooner.

A longer-term compatibility solution is to expose the effective timing and limit parameters on chain or through a stable RPC surface, allowing SDKs and clients to query cluster reality instead of depending on compile-time constants.

Conformance

Each validator implementation MUST include tests or fixtures that demonstrate:

• Activation of each feature gate from a 400ms baseline, including the one-epoch delay before the gate becomes effective.
• Correct bank values for ns_per_slot, slots_per_year, rent_collector.slots_per_year, and non-Alpenglow hashes_per_tick.
• Correct block, writable-account, vote, accounts-data, shred, and PER limits for every target slot time in the tables above.
• Correct Alpenglow VAT amount for every target slot time in the tables above, using the effective slot-time stage of the epoch being admitted.
• Correct snapshot restore behavior after each feature gate is active and after each gate becomes effective.
• Correct snapshot manifest serialization before activation, during the one-epoch delay, and after the effective transition for ns_per_slot, hashes_per_tick, and slots_per_year.
• Correct shred validation before activation, during the one-epoch delay, and after the effective transition.
• Correct inflation behavior for slot ranges and epochs that span effective transitions.
• Correct Alpenglow VAT admission behavior for vote accounts funded with the new VAT amount plus rent, but less than the previous VAT amount plus rent, around each effective transition.
• Correct Alpenglow interaction, specifically that Alpenglow hashing behavior is not reduced by these feature gates.

The change should be accompanied by localnet ledgers that cross all four feature activations and their delayed effective-transition boundaries.

References

1. Agave exploratory implementation for halving slot times: https://github.com/anza-xyz/agave/pull/10740
2. SIMD discussion #469 in the SIMD repository: https://github.com/solana-foundation/solana-improvement-documents
3. Agave exploratory implementation for changing leader span and epoch length: https://github.com/anza-xyz/agave/pull/12154