Solanas Ziel-Slotzeit im Mainnet soll sich in Epoch 1020 von 400 Millisekunden auf 350 Millisekunden verschieben, nach einer Verzögerung um eine Epoch, nachdem das Feature zu Beginn von Epoch 1019 aktiviert wurde. Die wirksame Änderung ist für Epoch 1020 vorgesehen.

Solanas Engineering-Changelog vom 6. August bestätigt, dass das Feature-Gate zur Senkung der Slot-Zeit von 400 ms auf 350 ms auf Devnet und Testnet live war. Der Changelog verweist außerdem auf einen kommenden Feature-Gate-Zeitplan und listet Releases sowie Engineering-Arbeiten im gesamten Solana-Ökosystem auf.

Die Zielzeit ist nicht dasselbe wie beobachtete Blockproduktion, Latenz bei der Transaktionsbestätigung oder wirtschaftliche Finalität. Die Änderung verkürzt das Ziel-Produktionsintervall, ohne das Rechenbudget pro Sekunde zu erhöhen.

EXPLORE: Best Memecoins Presales to Watch in 2026

Was sich mit dem 350-ms-Ziel ändert

Die Verringerung des Zielintervalls von 400 ms auf 350 ms verkürzt es um 50 Millisekunden. Der theoretische Anstieg der Planungsfrequenz beträgt rund 14,3 %, berechnet als 400 geteilt durch 350 minus 1. Diese Berechnung beschreibt nur den Zielrhythmus und ist keine Prognose für Transaktionsdurchsatz oder Bestätigungsgeschwindigkeit.

Die gestufte Reduzierung bezieht sich auf den Draft-Vorschlag SIMD-0525. Laut der Beschreibung des Vorschlags im Bericht wurde das Mainnet-Feature-Konto in Epoch 1019 aktiviert, während das wirksame 350-ms-Ziel bis Epoch 1020 verzögert ist.

we're activating 1st slot time reduction on mainnet

help ensure devs are ready because the transition period is wonky…

1. We have NOT updated some sdk constants like DEFAULT_MS_PER_SLOT to reflect new values. Note we will push a release with updated values post activation… — Brennan Watt (@bw_solana) August 18, 2026

Der gleiche Bericht sagt, dass das beispielhafte maximale Rechenbudget pro Block sinkt, wenn die Ziel-Slots kürzer werden. Er nennt 100 Millionen Compute Units bei einem 400-ms-Ziel und 87,5 Millionen Compute Units bei 350 ms. Beide Werte entsprechen einem theoretischen Maximum von rund 250 Millionen Compute Units pro Sekunde: 100 Millionen geteilt durch 0,4 Sekunden und 87,5 Millionen geteilt durch 0,35 Sekunden.

Diese theoretische Obergrenze ist keine Prognose für den Transaktionsdurchsatz. Die tatsächliche Aktivität hängt von der Arbeitslast und den Netzwerkbedingungen ab, und ein maximales Block-Compute-Limit bedeutet nicht, dass jeder Block diese Menge an Arbeit enthält.

Solana würde weiterhin jedem Leader vier aufeinanderfolgende Slots zuweisen. Bei einem 400-ms-Ziel entspricht das einem nominalen Leader-Fenster von 1,6 Sekunden; bei 350 ms entspricht es 1,4 Sekunden. Der kürzere Zeitraum lässt Validatoren weniger Zeit, einen vorherigen Block zu empfangen, erneut auszuführen, darauf aufzubauen und ihre Stimmen einzureichen, bevor das Netzwerk zum nächsten Slot wechselt.

EXPLORE: Best Memecoins Presales to Watch in 2026

Der gestufte Weg zu 200 ms

Die vorgeschlagene Abfolge von Ziel-Slot-Reduzierungen führt von 400 ms auf 350 ms, dann auf 300 ms, 250 ms und 200 ms. Der Solana-News-Bericht sagt, dass Testnet mit einem wirksamen 200-ms-Ziel arbeitete, während Devnet bei 300 ms lag und ein 250-ms-Gate aktiviert hatte, das noch nicht wirksam war.

Die Änderung auf 350 ms im Mainnet sollte daher als eine Stufe innerhalb einer breiteren vorgeschlagenen Abfolge betrachtet werden und nicht als Bestätigung, dass jede spätere Zielvorgabe nach demselben Zeitplan wirksam wird. SIMD-0525 bleibt ein Draft, und die Aktivierung eines Features auf einem Cluster macht das vollständige 200-ms-Design nicht zu einem akzeptierten endgültigen Standard.

The first slot time reduction feature is now live on Solana testnet. SIMD-0525 is active on testnet, reducing slot time from 400ms to 350ms as the first of four feature-gated steps toward 200ms slot time. pic.twitter.com/8XnTu4Byqs — Solana Developers (@solana_devs) August 5, 2026

Der Changelog vom 6. August liefert außerdem zusätzlichen Kontext zur Arbeit an Validator-Clients. Er nennt Releases für Agave und Firedancer, beschreibt weitere Konformitätsarbeit an Agave und sagt, dass Mithril bezüglich Agaves Konformitätssuite auf dem Laufenden bleibt. Der Changelog sagt, dass Mithril eine neue, in Go geschriebene Validator-Implementierung ist, die bald am Konsens teilnehmen wird, und dass ihre Arbeit mit der Konformitätssuite dazu dienen soll, mit Agave Schritt zu halten.

Der Changelog beschreibt außerdem Verbesserungen am Turbine-Broadcasting-Cache des Leaders von Agave und am Neuaufbau der Routing-Tabelle. Laut dem Changelog erstellen Leader Blöcke aus von dem Netzwerk gesendeten Transaktionen, teilen Blöcke in Shards auf und verteilen sie über Turbine an Validatoren.

EXPLORE: Best Crypto Presales to Watch in 2026