Anza hat Transaction V1 am 1. September auf dem Solana-Testnet aktiviert und dem Netzwerk damit eine letzte Generalprobe des Upgrades vor dem geplanten Mainnet-Start am 9. September ermöglicht. Laut Solana Compass erlaubt die Änderung, kryptografische und DeFi-Workloads, die zuvor auf mehrere Transaktionen aufgeteilt werden mussten, in einer einzigen atomaren Transaktion zu verarbeiten.

Getrennte Aufgaben passen jetzt in einen Aufruf

Die auffälligste Veränderung ist die Größenzunahme. Die maximale Größe einer serialisierten Solana-Transaktion ist von 1.232 Bytes auf 4.096 Bytes gestiegen – eine Erhöhung um das 3,3-Fache – und trat mit dem Testnet-Epoch 1025 in Kraft. Die Grenze von 1.232 Bytes stammte noch aus Solanas frühester Protokollgestaltung, und V1 ist das erste Mal, dass das Limit auf Ebene des Nachrichtenformats angehoben wurde, seit V0 Address Lookup Tables als teilweise Behelfslösung für den Größendruck einführte.

Gemäß der Seite der Solana Foundation zum Update für große Transaktionen ermöglicht die größere Datenmenge die Implementierung von Zero-Knowledge-Beweisen, großen Multisig-Transaktionen und verschiedenen Signaturverfahren, die zuvor nicht in eine einzelne Transaktion passten. Das Ergebnis: weniger zu verarbeitende Transaktionen, geringere Kosten für Signaturen und kein Warten auf eine Kette von Bestätigungen. BLS-Signaturverfahren, vertrauliche Transaktionen und Multisig-Setups sollen von dem Upgrade profitieren.

Zwei Vorschläge stehen im Mittelpunkt der Verbesserung: SIMD-0296 hebt das Transaktionsgrößenlimit von 1.232 auf 4.096 Bytes an, während SIMD-0385 das V1-Nachrichtenformat definiert und die Transaktionskonfiguration in die Nachricht selbst verlagert.

Weniger als einen Tag nach der Aktivierung wies Anza-CEO Brennan Watt auf X auf eine große Transaktion im Testnet-Explorer hin, mit der Botschaft: "ATTENTION: large transactions have hit the testnet."

Warum eine Transaktion besser ist als ein Bundle

Die Atomarität ist wichtig, weil Entwickler das alte Größenlimit von Solana mitunter über Jito-Bundles umgangen haben. SIMD-0296 dokumentiert diese Behelfslösung ausdrücklich und weist darauf hin, dass Bundles – anders als eine einzelne native Transaktion – keine Atomarität auf Protokollebene bieten.

Laut der Dokumentation von Jito können Bundles bis zu fünf Transaktionen enthalten, die sequenziell nach dem Alles-oder-Nichts-Prinzip verarbeitet werden. Bundles laufen jedoch innerhalb der Block-Engine von Jito und konkurrieren über Validator-Tips. Eine V1-Transaktion ist demgegenüber eine einzelne native Solana-Transaktion mit der eigenen transaktionsbezogenen Atomaritätsgarantie von Solana.

Für DeFi-Entwickler vereinfacht dies den Aufbau von Swap-Routen, Beweisen und anderen mehrstufigen Operationen: Passt die gesamte Operation in eine V1-Transaktion, schlägt sie entweder komplett fehl oder komplett erfolgreich als eine native Transaktion, statt auf ein Transaktions-Bundle zurückgreifen zu müssen.

Was DeFi über die zusätzlichen Bytes hinaus bekommt

V1 verändert auch die Transaktionsstruktur selbst. Während Legacy- und V0-Transaktionen Priority Fees und Ressourcenanfragen über ComputeBudget-Instruktionen abwickeln, verlagert SIMD-0385 diese Einstellungen in die Transaktionskonfiguration von V1. So können Validatoren den Ressourcenbedarf einfacher erkennen, ohne die Instruktionenliste durchsuchen zu müssen.

V1 entfernt zudem Address Lookup Tables (ALTs), die V0 zur Verkürzung von Kontoadressen nutzte. Laut der Analyse der Stiftung zum ALT-Kompromiss von V1 platziert V1 Adressen stattdessen inline, was die Eingabe für Validatoren im Vergleich zum V0-Ansatz vereinfacht, der bei adressenintensiven Anwendungen beim Konvertieren mehr Bytes verbrauchte.

Der praktische Nutzen für Router und DEX-Aggregatoren ist mehr Spielraum für komplexe atomare Routen. Die Verbesserung ist jedoch nicht grenzenlos: Solanas Obergrenze von 64 verschiedenen Konten pro Transaktion bleibt unverändert, sodass adressenintensive Anwendungen weiterhin an diese Grenze stoßen können, auch wenn die Byte-Kapazität keine Hürde mehr darstellt.

Das Upgrade kommt, während Solana tiefer in die On-Chain-Finanzwirtschaft vordringt. Galaxys Solana-Bericht für Q2 2026 zeigt wachsende Aktivität bei Stablecoins, tokenisierten Aktien und Real-World-Assets. Laut Galaxy wird Solanas künftiges Potenzial maßgeblich davon abhängen, ob sich diese Assets in Krediten, als Besicherung, in Margen und für Rendite nutzen lassen – nicht nur für Emission oder Handel. Die Daten von DeFiLlama zu Solana deuten auf eine starke DeFi-Präsenz der Plattform hin.

Der Zeitpunkt fällt zudem mit der Phase des Agave-4.2-Upgrades zusammen. Wie Cryptopolitan zuvor berichtete, sollte der schrittweise Kostenreduzierungsplan Einsparungen von rund 90 % bringen und die Verarbeitungszeit von 500 auf 200 Millisekunden senken – ein Vorteil für Stablecoin-Emittenten, Wallet-Anbieter und Zahlungssysteme.

RPC-Betreiber haben eine Woche zum Aktualisieren

V1 ist optional, sodass Legacy- und V0-Transaktionen weiterhin funktionieren. Die offene Frage ist, ob die Infrastruktur, die V1-Datenverkehr liest, bereit ist.

Anza hat RPC-Anbieter verpflichtet, auf Agave v4.2.2 oder v4.3.0-beta.3 zu aktualisieren. Die Helius-Checkliste zur Agave-4.2-Migration warnt, dass RPC-Clients ohne deklarierte V1-Kompatibilität Fehler bei Aufrufen wie getBlock erleiden können, wenn eine V1-Transaktion betroffen ist.

Der Rollout begann mit lokalen Tests von V1 am 24. August, gefolgt von der Bestätigung des Mainnet-Datums am 29. August. V1 wurde am 1. September mit Epoch 1025 auf dem Testnet aktiviert, die Mainnet-Aktivierung ist für den 9. September geplant.

Der jüngste Testnet-Durchlauf dient als letzte Vorbereitungsmaßnahme für RPC-Anbieter, Indexer, Wallets, SDKs und Analyseplattformen vor dem Mainnet-Start.