Solana-Upgrade am 9. September: Was das neue Transaktionsformat ändert

Am 9. September 2026 schaltet Solana ein neues Transaktionsformat scharf. Für dich als Halter von SOL ist die wichtigste Antwort gleich vorweg die beruhigende: Du musst nichts tun. Kein Umtausch, kein Wallet-Wechsel, keine Frist, die dir Geld kostet. Was sich ändert, liegt eine Ebene tiefer im Protokoll, und genau dort kann es in den Tagen um den 9. September dazu führen, dass sich einzelne Wallets und Anwendungen unterschiedlich verhalten, ohne dass an deiner Seite etwas kaputt ist.

Dieser Text erklärt, was am 9. September wirklich passiert, wer den Termin genannt hat, warum er ein paar Stunden Spielraum in beide Richtungen trägt, und woran du selbst erkennst, dass die Umstellung durch ist. Auf Deutsch steht dazu bisher praktisch nichts: Der Sachbegriff ist unbesetzt, während die Suchergebnisse zu „Solana Upgrade September 2026" fast ausschließlich Kurs- und ETF-Meldungen tragen.

Was am 9. September auf Solana passiert — und was nicht

Solana hebt die maximale Größe einer einzelnen Transaktion an: von 1.232 auf 4.096 Bytes, also um gut das Dreifache. Möglich wird das durch das Netzwerkprotokoll QUIC, das anders als die alte IPv6-Grenze von 1.280 Bytes keine feste Obergrenze für einen Datenstrom vorschreibt.

Die neue Größe gilt aber nicht für alles, was über die Kette läuft. Ausschlaggebend ist ein neues Transaktionsformat mit der Bezeichnung v1, und nur dort greift das höhere Limit. Die beiden bisherigen Formate, legacy und v0, bleiben unverändert gültig und behalten ihre alte Grenze. Entwickler müssen aktiv auf v1 umstellen; von allein wandert keine Anwendung dorthin.

Damit ist auch klar, was am 9. September nicht passiert: Es gibt keinen Hardfork, keine Kettenteilung, keine Migration deiner Guthaben und keinen Stillstand des Netzwerks. Deine SOL, deine Token und deine Stakes liegen nach dem Schalttag exakt dort, wo sie vorher lagen.

Wer den Termin genannt hat — und warum die offizielle Upgrade-Seite kein Datum trägt

Das Datum stammt nicht aus einem Dokument der Solana Foundation, sondern von einer namentlich zugeschriebenen Aussage. Jacob Creech, Vice President of Technology bei der Solana Foundation, hat den 9. September am 29. August auf X genannt; das Fachmedium crypto.news hat die Ansage am 30. August aufgegriffen (crypto.news).

Die offizielle Upgrade-Seite der Solana Foundation führt das Vorhaben dagegen ohne Datum. Dort stehen die Zahlen (4.096 statt 1.232 Bytes, das 3,3-Fache) und der Status „Pending Feature Activation", also ausstehende Aktivierung. Für die drei Netze steht dort: Testnet aktiv, Devnet nicht aktiviert, Mainnet nicht aktiviert.

Diese Lücke zwischen Ansage und Dokument ist kein Widerspruch, sondern die Regel bei Solana. Termine für einzelne Funktionen entstehen aus dem Release-Plan der Entwicklerfirma Anza und werden von Menschen kommuniziert, bevor sie irgendwo als gesetztes Datum stehen. Wer es hart haben will, prüft die Kette selbst — dazu weiter unten mehr.

Transaktionsgröße: Was mit 4.096 Bytes erstmals in einen Vorgang passt

Eine Transaktion ist der Umschlag, in dem eine Anweisung an die Blockchain steckt: Absender, Empfänger, Signaturen, betroffene Konten, Programmaufruf. Bisher passten in diesen Umschlag 1.232 Bytes. Alles, was größer war, musste in mehrere Transaktionen zerlegt und nacheinander verkettet werden, mit dem Risiko, dass ein Teil durchgeht und der nächste scheitert.

Mit 4.096 Bytes passen laut der offiziellen Upgrade-Seite erstmals in einen einzigen Vorgang: Zero-Knowledge-Beweise (kryptografische Nachweise, die etwas belegen, ohne die zugrunde liegenden Daten preiszugeben), komplexe Multisignatur-Anweisungen und gebündelte Operationen, die heute mehrere verkettete Transaktionen brauchen. Für Anwendungen mit hoher Taktung (Liquidations-Engines, Orderbücher, Abwicklungsschichten im DeFi-Bereich) ist das der eigentliche Gewinn: weniger Teilschritte, weniger Zwischenzustände, weniger Fehlerquellen.

Das Limit von 64 Konten je Transaktion bleibt dabei unverändert. Mehr Platz bedeutet also mehr Daten je Beteiligtem, nicht mehr Beteiligte.

Was ein Feature-Gate ist und warum es nur an Epochengrenzen springt

Ein Feature-Gate ist ein Schalter im Validator-Code, der eine fertig ausgelieferte Funktion so lange ausgeschaltet lässt, bis eine Mehrheit der Validatoren sie gemeinsam einschaltet. Solana legt seine Neuerungen seit Jahren hinter solche Gates, statt sie an einen Hardfork zu binden. Der Vorteil liegt in der Entkopplung: Die Änderungen aus einem Release sind technisch unabhängig voneinander und können einzeln und nacheinander scharfgeschaltet werden, jede erst nach ihrem eigenen Test. Dieses Netzwerk-Upgrade ist damit Teil eines laufenden Rollouts und kein einmaliges Ereignis.

Der Preis dafür ist, dass sich das Netzwerk im September gleich mehrfach ändert, ohne dass es je eine große Ankündigung mit Countdown gibt. Für das größere Transaktionsformat trägt das Gate die on-chain nachprüfbare Adresse txv1aq4pp281K9um3tnPgkfX8UqtFT6wcVW3hNezGLL.

Wichtig für das Verständnis des Termins: Ein Gate fällt an einer Epochengrenze, nicht zu einer Uhrzeit. Eine Epoche ist der Abrechnungszeitraum von Solana und umfasst fest 432.000 Slots; ein Slot ist das Zeitfenster, in dem ein Validator einen Block produzieren darf. Erst wenn eine Epoche endet, übernimmt die Kette die neu aktivierten Funktionen.

Eigene Messung: Wo die Kette am 2. September stand

Wir haben am 2. September 2026 gegen 12:40 UTC direkt bei einem öffentlichen Mainnet-Knoten nachgefragt, statt uns auf Angaben Dritter zu verlassen. Drei Werte kamen in Echtzeit zurück:

• Das Konto des Feature-Gates txv1aq4pp… ist auf Mainnet-beta leer. Das Gate ist zu diesem Zeitpunkt nicht aktiviert; die Ansage für den 9. September ist also noch offen, nicht bereits vollzogen.
• Die Kette lief in Epoche 1027, bei Slot 35.113 von 432.000, also rund acht Prozent der Epoche.
• Die befragten Knoten meldeten die Client-Version 4.2.1. Der Release, der das neue Format ausliefert, läuft also bereits.

Aus zwei Blockzeiten im Abstand von 10.000 Slots ergibt sich eine gemessene Slot-Zeit von rund 314 Millisekunden. Damit dauert eine volle Epoche derzeit etwa 37,7 Stunden. Rechnet man das fort, endet Epoche 1027 am Abend des 3. September, und bis zum 9. September liegen noch etwa drei weitere Epochengrenzen. Die letzte davor fällt auf den Abend des 8. September, die nächste danach auf den 10. September.

Praktisch heißt das: Der 9. September ist ein Datum mit ein paar Stunden Spielraum in beide Richtungen, keine Uhrzeit. Wer am 9. September morgens nachsieht und noch nichts bemerkt, hat nicht zwangsläufig etwas verpasst.

Address Lookup Tables fallen im Format v1 weg

Hier sitzt der eigentliche Haken, und er ist der Grund, warum Entwickler das neue Format nicht einfach überall einschalten. Eine Address Lookup Table (ALT) ist ein on-chain gespeichertes Nachschlageverzeichnis für Kontoadressen: Statt jede Adresse mit vollen 32 Bytes in die Transaktion zu schreiben, verweist die Anwendung mit einem kurzen Index auf einen Eintrag in dieser Tabelle. Genau so haben Anwendungen bisher Platz gespart, um überhaupt unter die 1.232-Byte-Grenze zu kommen.

Das Format v1 unterstützt diese Tabellen nicht. Wer v1 nutzt, muss alle beteiligten Konten als vollständige 32-Byte-Adressen direkt in die Anweisung schreiben. Der zusätzliche Platz finanziert also zu einem Teil seinen eigenen Mehrverbrauch.

Für Entwickler wird daraus eine Abwägung je Transaktion: Bringt der größere Umschlag mehr, als die eingesparte Adressliste gekostet hat? Bei einem Zero-Knowledge-Beweis lautet die Antwort klar ja. Bei einem Swap über viele Pools, der heute mit einer gut gepflegten Lookup-Tabelle arbeitet, kann das alte Format weiterhin die bessere Wahl sein.

Was das für Wallets und dApps in den Tagen um den 9. September heißt

Weil jede Anwendung diese Abwägung selbst trifft, wird die Umstellung ungleichmäßig verlaufen. Manche Teams schalten früh auf v1 um, andere lassen es monatelang bleiben, wieder andere nutzen beide Formate parallel je nach Vorgang. Für dich als Nutzer kann das so aussehen:

• Eine dApp meldet nach dem Schalttag geringfügig andere Gebühren für denselben Vorgang, weil sich die Größe der Transaktion verändert hat.
• Ein Wallet zeigt eine Transaktion in der Vorschau anders an als vorher.
• Eine Anwendung bleibt vorerst beim alten Verhalten, während eine andere sich sichtbar ändert.

Keine dieser Beobachtungen ist ein Fehler an deinem Konto. Wenn du deine Schlüssel selbst hältst, ändert das Upgrade an deiner Verwahrung nichts — ein Blick in den Vergleich der Hardware-Wallets lohnt aus anderen Gründen, aber nicht wegen dieses Termins. Umgekehrt gilt: Wenn dir eine Nachricht, eine E-Mail oder ein Anruf in diesen Tagen erzählt, du müsstest wegen des Solana-Upgrades deine Wallet „migrieren" oder eine Seed Phrase eingeben, ist das ein Betrugsversuch. Netzwerk-Upgrades dieser Art verlangen niemals eine Handlung von Endnutzern.

Muss ich als SOL-Halter etwas tun?

Nein. Die Antwort ist belastbar, und sie hat drei Gründe:

1. Bestehende Formate bleiben gültig. legacy- und v0-Transaktionen laufen nach dem 9. September genauso wie vorher.
2. Die Umstellung ist freiwillig und liegt beim Engineering-Team der jeweiligen Anwendung. Weder Wallet-Nutzer noch Halter treffen hier eine Entscheidung.
3. Es gibt keine Frist, an der etwas verfällt. Anders als bei einem Token-Swap oder einer Handelseinstellung an einer Börse steht am Ende dieses Termins kein Verlust.

Wer trotzdem etwas tun will, tut das Sinnvollste: In den Tagen um den 9. September größere Nutzer-Transaktionen nicht auf die letzte Minute legen und bei einer auffälligen Fehlermeldung erst die Statusseite der jeweiligen Anwendung prüfen, bevor er sie mehrfach wiederholt.

Der September-Fahrplan: drei Änderungen, drei Termine

Das größere Transaktionsformat ist die mittlere von drei Änderungen, die Solana in wenigen Wochen nacheinander scharfschaltet. Der Fahrplan, wie ihn Jacob Creech Ende August umrissen hat:

1. Senkung der Speichergebühren (nach der Governance-Abstimmung über den Vorschlag SIMD-0437), erste von fünf geplanten Stufen in der Woche ab dem 31. August. Gemeint ist die Miete, die Konten auf Solana für ihren Speicherplatz hinterlegen müssen — sinkt sie, wird das Anlegen neuer Konten billiger.
2. Transaktionsformat v1 mit 4.096 Bytes, angesetzt auf den 9. September.
3. Alpenglow, das große Konsens-Upgrade, das mit dem Release Agave 4.3 kommt und laut Foundation auf den Oktober zielt.

Zum letzten Punkt gibt es zwei Datumsangaben, die sich auf den ersten Blick widersprechen und die wir deshalb nebeneinanderstellen: Der Release-Plan für Agave 4.3 nennt den 28. September als Beginn der Feature-Aktivierung auf dem Mainnet, während die Foundation für Alpenglow selbst den Oktober als Ziel angibt. Beides passt zusammen, sobald man Release und Gate trennt: Der Release bringt den Code, das Gate entscheidet über den Zeitpunkt; diese Roadmap ist kein starrer Kalender. Was Alpenglow für Staker bedeutet, haben wir in unserem Beitrag zum Alpenglow-Upgrade und dem Staking ausführlich aufgeschrieben.

Wie schnell die Kette wirklich läuft — und was Alpenglow daran ändern soll

Bei der Slot-Zeit gehen die veröffentlichten Angaben auseinander. Die offizielle Upgrade-Seite nennt für den Release Agave 4.2 das Ziel 200 Millisekunden gegenüber zuvor 400; crypto.news berichtete am 30. August von aktuell 350 Millisekunden mit den Zwischenzielen 300, 250 und 200. Unsere eigene Messung am 2. September ergab 314 Millisekunden. Die Absenkung der Blockproduktion läuft also in Stufen, die ebenfalls hinter einzelnen Gates liegen.

Finalität (englisch transaction finality) ist davon zu unterscheiden und bezeichnet den Moment, ab dem eine Transaktion praktisch nicht mehr rückgängig gemacht werden kann. Genau hier setzt Alpenglow an. Das Upgrade ersetzt die bisherige Konsens-Architektur TowerBFT durch zwei neue Bausteine, Votor für die Abstimmung der Validatoren und Rotor für die Blockverteilung (block propagation), und zielt auf eine Finalität von rund 100 bis 150 Millisekunden statt der bisher üblichen 12,8 Sekunden. Ein Teil des Gewinns entsteht dadurch, dass die Vote-Transaktionen der Validatoren off chain abgewickelt werden statt regulär über die Kette zu laufen, was zugleich die Validator-Kosten senkt. Proof of History, die Zeitquelle der Kette, bleibt davon unberührt.

Für den Alltag heißt Sub-Sekunden-Finalität vor allem: Börsen und Zahlungsdienste können Einzahlungen früher gutschreiben, weil die Abwicklungssicherheit früher feststeht. Damit wird Solana als Abwicklungsschicht (Settlement Layer) für Anwendungen interessanter, bei denen es auf schnelle Finalität ankommt. Für die Kursseite ist das kein Automatismus.

Was Validatoren und Staker jetzt beobachten sollten

Wer selbst einen Validator betreibt, hat den Termin ohnehin im Kalender. Wer nur delegiert, also seine SOL bei einem fremden Validator hinterlegt hat, muss nichts vorbereiten — sollte aber wissen, worauf es in den kommenden Wochen ankommt.

Entscheidend ist die Client-Vielfalt: Solana wird heute von mehreren unabhängigen Validator-Programmen betrieben. Wenn eine Funktion nur in einem davon fertig ist, verzögert sich das Gate für alle; erprobt werden solche Änderungen vorher auf Testnetzen und in der Praxis der Validatoren. Für dich als Staker ist deshalb weniger der einzelne Termin interessant als die Frage, ob dein Validator die aktuellen Releases zeitnah einspielt und wie zuverlässig er Blöcke produziert. Wer seine Delegation ohnehin überprüfen wollte, achtet auf die Ausfallzeiten seines Validators, auf dessen Provision und darauf, ob er die aktuellen Releases mitgeht.

Ein Punkt, der oft untergeht: Die Höhe deiner Staking-Rendite hängt an der Inflationsrate des Protokolls und an den Gebühreneinnahmen der Validatoren, nicht am Transaktionsformat. Dass die Rendite zuletzt gesunken ist, hat andere Gründe.

Woran du erkennst, dass das Gate gefallen ist

Du brauchst dafür keinen eigenen Knoten. Es gibt drei Wege, vom einfachsten zum genauesten:

1. Die offizielle Upgrade-Seite. Dort steht der Status je Netz. Springt der Eintrag für das Mainnet von „nicht aktiviert" auf aktiv, ist die Sache durch.
2. Der Epochenzähler. Öffentliche Solana-Explorer zeigen die laufende Epoche und ihren Fortschritt. Ein Gate fällt immer beim Übergang zur nächsten Epoche.
3. Das Feature-Konto selbst. Wer mag, fragt einen öffentlichen Knoten nach dem Konto txv1aq4pp281K9um3tnPgkfX8UqtFT6wcVW3hNezGLL. Solange dort nichts steht, ist die Funktion aus; sobald das Konto Daten trägt, ist sie an. Genau diesen Weg haben wir für diesen Artikel benutzt.

Und wenn der 9. September verstreicht, ohne dass etwas geschieht? Dann ist das kein Alarmzeichen. Feature-Gates verschieben sich regelmäßig um eine oder zwei Epochen, wenn ein Test noch läuft oder ein Client hinterherhinkt. Das Datum ist eine Absicht, kein Vertrag.

Solana-Upgrade: Was du daraus mitnimmst

1. Ruhig bleiben und nichts umstellen. Für Halter und Nutzer gibt es an diesem Termin keine Handlung, keine Frist und kein Risiko. Wenn du deine SOL langfristig hältst, ändert sich für dich nichts — wo du sie kaufst, entscheidest du weiterhin nach Gebühren und Handelspaaren, etwa mit dem Vergleich der Krypto-Börsen.
2. Bei Ungereimtheiten zuerst die Anwendung prüfen, nicht das Netzwerk. Weicht eine dApp in diesen Tagen von ihrem gewohnten Verhalten ab, liegt das mit hoher Wahrscheinlichkeit an ihrer eigenen Umstellung auf das neue Format. Jede Aufforderung, deswegen Schlüssel einzugeben oder Guthaben zu verschieben, ist Betrug; welche Software-Wallets deine Schlüssel wie verwahren, zeigt der Software-Wallet-Vergleich.
3. Den Oktober-Termin im Blick behalten. Alpenglow ist die Änderung mit echten Folgen für Staker und für die Geschwindigkeit der Kette. Wenn du delegierst, prüfe vorher, wie zuverlässig dein Validator arbeitet; die Vergleichsgrößen dafür stehen im Überblick zu den Staking-Plattformen.

(Stand: 2. September 2026. Dieser Beitrag ist keine Anlageberatung. Kurse und Gebührenmodelle ändern sich; prüfe die Konditionen vor jedem Kauf beim Anbieter selbst.)