Solana trat am 29. Juli 2026 in eine neue Kapazitätsphase ein, als SIMD-0286 zu Beginn der Epoche 1009 im Mainnet aktiviert wurde. Durch diese Änderung stieg der maximale Rechenaufwand pro Block von 60 Millionen auf 100 Millionen Compute Units, kurz CUs, was einer Erhöhung um rund 66 % entspricht. Für Krypto-Casinos, die SOL oder auf Solana ausgegebene Token akzeptieren, ist dieses Upgrade relevant, weil Ein- und Auszahlungen denselben Blockraum nutzen wie Handel, Zahlungen, DeFi-Anwendungen und alle anderen Transaktionen im Netzwerk. Ein höheres Blocklimit gibt Validatoren mehr Spielraum, um auch bei hoher Aktivität zusätzliche Transaktionen aufzunehmen. Das bedeutet jedoch nicht, dass eine einzelne Casino-Zahlung automatisch 66 % schneller wird. Ebenso entfallen dadurch weder interne Auszahlungsprüfungen noch wird eine Einzahlung zwangsläufig früher dem Spielerkonto gutgeschrieben. Der praktische Vorteil liegt vor allem darin, eine konkrete Ursache für Verzögerungen zu reduzieren: den Wettbewerb um begrenzte Blockkapazität in Phasen hoher Netzwerkauslastung.
SIMD-0286 erhöhte das maximale Compute-Limit eines Solana-Blocks von 60M auf 100M CUs. Compute Units lassen sich vereinfacht als Maß für den Rechenaufwand verstehen, den Transaktionen verursachen. Eine einfache SOL-Übertragung benötigt vergleichsweise wenig Rechenleistung, während Transaktionen mit Swaps, mehreren Programmanweisungen oder komplexeren On-Chain-Vorgängen deutlich mehr beanspruchen können. Das Blocklimit legt deshalb keine feste Zahl von Transaktionen pro Block fest. Stattdessen begrenzt es deren gesamten Rechenaufwand. Durch die Anhebung dieser Grenze kann ein Blockproduzent insgesamt mehr Arbeit verarbeiten, bevor ein Block als ausgelastet gilt. Das ist besonders relevant, wenn innerhalb kurzer Zeit sehr viele voneinander unabhängige Transaktionen eingehen.
Die Erhöhung wurde notwendig, weil das frühere Limit von 60M CUs nicht mehr nur theoretisch erreicht wurde. Daten der Solana Foundation zeigen, dass zwischen der Aktivierung des 60M-Limits am 22. Juli 2025 und der Umstellung auf 100M CUs im Juli 2026 rund 11,2 % der erzeugten Blöcke mindestens 56M CUs nutzten. Damit arbeitete ungefähr jeder neunte Block nahe an der bisherigen Obergrenze. Gleichzeitig war die Netzwerkauslastung nicht gleichmäßig verteilt, sondern stieg insbesondere in kurzen Phasen stark an, beispielsweise bei schnellen Marktbewegungen. Für Casino-Zahlungen ist dieses Muster relevant, weil eine gewöhnliche Einzahlung genau zu dem Zeitpunkt abgeschickt werden kann, an dem Handelsanwendungen eine deutlich größere Zahl von Transaktionen erzeugen. Unter dem alten Limit konkurrierten beide Arten von Aktivitäten um ein kleineres gemeinsames Rechenbudget.
SIMD-0286 änderte ausschließlich das gesamte Compute-Limit eines Blocks. Andere wichtige Beschränkungen blieben bestehen. Der maximale Rechenaufwand für Schreibzugriffe auf ein einzelnes Konto blieb bei 12M CUs, während die maximale Zunahme der Account-Daten pro Block weiterhin 100 MB beträgt. Solana beschrieb das Upgrade zudem als nicht inkompatibel und erklärte, dass keine Änderungen an den Indexierungsformaten notwendig seien. Vor der Aktivierung hatten mehr als 70 % des Mainnet-Stakes XDP-Netzwerktechnik aktiviert, damit Validatoren die zusätzliche Datenmenge größerer Blöcke besser verarbeiten können. Diese schrittweise Vorbereitung ist wichtig, weil eine höhere Kapazität nur dann sinnvoll ist, wenn Validatoren, RPC-Dienste und andere Infrastrukturbereiche die zusätzliche Last bewältigen können, ohne an anderer Stelle einen neuen Engpass zu erzeugen.
Eine Casino-Einzahlung in SOL oder einem Solana-Token erhält durch SIMD-0286 kein höheres individuelles Transaktionslimit. Die Verbesserung findet auf Blockebene statt. Eine Übertragung, die vor dem Upgrade nur wenig Rechenleistung benötigte, erfordert danach ungefähr dieselbe Menge. Geändert hat sich jedoch der gesamte Rechenaufwand, der zusammen mit dieser Transaktion in denselben Block aufgenommen werden kann. Wenn viele Nutzer gleichzeitig Vermögenswerte übertragen, Token handeln oder mit On-Chain-Anwendungen interagieren, verfügt das Netzwerk nun über mehr Spielraum, diese voneinander unabhängigen Vorgänge gemeinsam zu verarbeiten, anstatt einen größeren Teil auf spätere Blöcke verschieben zu müssen.
Diese Unterscheidung erklärt zugleich, weshalb 100M-CU-Blöcke nicht jede Form von Überlastung beseitigen. Solana behält Einschränkungen für einzelne beschreibbare Konten bei. Wenn sich sehr viele Aktivitäten auf dasselbe Konto konzentrieren, kann deshalb weiterhin eine lokale Begrenzung auftreten, selbst wenn im Block insgesamt noch Kapazität verfügbar ist. Für einen gewöhnlichen Casino-Nutzer, der Vermögenswerte von einer privaten Wallet an eine Einzahlungsadresse sendet, schafft die höhere Gesamtkapazität dennoch zusätzlichen Spielraum während netzwerkweiter Belastungsspitzen. Der Effekt ist besonders deutlich, wenn das bisherige Problem darin bestand, dass viele unabhängige Transaktionen gleichzeitig in Blöcke aufgenommen werden sollten, die sich bereits dem früheren 60M-CU-Limit näherten.
Die Blockchain bildet außerdem nur einen Teil des gesamten Zahlungsablaufs. Eine Einzahlung muss normalerweise von der Wallet des Nutzers signiert, an Solana gesendet, in einen Block aufgenommen, bis zu dem vom Casino verlangten Bestätigungsstatus verarbeitet und anschließend von der Zahlungsinfrastruktur des Casinos erkannt werden, bevor das Guthaben dem Konto zugeordnet wird. Bei einer Auszahlung gibt es zusätzliche Schritte, bevor die Blockchain überhaupt beteiligt ist, da das Casino die Zahlung zunächst prüfen und vorbereiten muss. SIMD-0286 kann den Teil verbessern, der die Aufnahme einer Transaktion ins Netzwerk betrifft, insbesondere in stark ausgelasteten Phasen. Eine interne Prüfung, eine Warteschlange für Auszahlungen, eine verzögerte Guthabenerfassung oder eine bestimmte Bestätigungsrichtlinie des Casinos werden dadurch jedoch nicht beschleunigt.
Bei Einzahlungen liegt der unmittelbarste Vorteil von SIMD-0286 darin, dass während hoher Netzwerkauslastung mehr Platz für die Aufnahme einer eingereichten Übertragung vorhanden ist. Bei einem knappen Blocklimit kann eine gültige Transaktion außerhalb des nächsten Blocks bleiben, weil Transaktionen mit höherer Priorität oder früher eingegangene Vorgänge das verfügbare Rechenbudget bereits ausgeschöpft haben. Wallet-Software kann anschließend versuchen, die Transaktion erneut zu übermitteln. In manchen Fällen muss sogar eine neue Transaktion erstellt werden, wenn die ursprüngliche Übertragung zu lange unbearbeitet bleibt. Durch die Erhöhung von 60M auf 100M CUs hat Solana den Umfang der Arbeit gesteigert, die gleichzeitig verarbeitet werden kann, bevor eine solche blockweite Kapazitätsgrenze relevant wird.
Frühe Daten nach der Aktivierung zeigen, dass der zusätzliche Spielraum tatsächlich genutzt wurde. Eine von Solana Compass veröffentlichte Analyse auf Basis von Daten von Pine Analytics untersuchte die ersten 48 Stunden nach der Umstellung auf 100M CUs. Demnach sank der Anteil der Blöcke, die nahe an ihrer effektiven Compute-Grenze lagen, von rund 12,5 % vor dem Upgrade auf ungefähr 0,5 % danach. Dieselbe Analyse ergab, dass innerhalb einzelner Stunden bereits 10 % bis 23 % der Blöcke das frühere Maximum von 60M CUs überschritten. Das zeigt, dass reale Transaktionen Kapazität nutzten, die zuvor nicht verfügbar gewesen wäre. Diese Zahlen beziehen sich auf das gesamte Solana-Netzwerk und nicht speziell auf Casino-Zahlungen. Sie verdeutlichen jedoch, weshalb eine gewöhnliche Einzahlung heute mehr Raum hat, parallel zu anderen Aktivitäten verarbeitet zu werden.
Der praktische Nutzen sollte deshalb eher als höhere Zuverlässigkeit während stark ausgelasteter Phasen verstanden werden und nicht als garantierte Verkürzung jeder Einzahlung. Eine Transaktion, die bei geringer Netzwerkauslastung gesendet wird, kann vor und nach SIMD-0286 nahezu gleich schnell verarbeitet werden, weil die Blockkapazität in diesem Fall ohnehin nicht der begrenzende Faktor war. Das Upgrade wird vor allem bei kurzfristigen Nachfragespitzen relevant. Selbst dann kann die im Casino angezeigte Bearbeitungszeit länger bleiben als die eigentliche Blockchain-Verarbeitung, weil der Anbieter zusätzliche Bestätigungen abwarten, Zieladresse und Token prüfen, interne Zahlungskontrollen durchführen und den Betrag erst nach der Verarbeitung durch das eigene Überwachungssystem dem Spielerkonto gutschreiben kann.
SIMD-0286 hat die im Solana-Protokoll festgelegte Basisgebühr nicht gesenkt. Die aktuelle Solana-Dokumentation nennt weiterhin eine Basisgebühr von 5.000 Lamports pro Signatur. Zusätzlich kann eine optionale Prioritätsgebühr verwendet werden, um die Position einer Transaktion bei der Verarbeitung zu verbessern. Mehr Blockkapazität kann dennoch beeinflussen, wie viel Nutzer tatsächlich zahlen, weil Prioritätsgebühren besonders dann relevant werden, wenn viele Transaktionen um knappen Ausführungsraum konkurrieren. Die frühe 48-Stunden-Analyse berichtete, dass die Transaktionsgebühr im 90. Perzentil nach der Aktivierung von 100M CUs von ungefähr 29.800 auf 20.800 Lamports sank, was einem Rückgang von rund 30 % entspricht. Der Median blieb dagegen in der Nähe von 5.600 Lamports. Dabei handelt es sich um eine frühe netzwerkweite Beobachtung und nicht um einen Nachweis dafür, dass diese Gebühren dauerhaft auf demselben Niveau bleiben.
Die Bestätigung einer Transaktion ist von der Blockkapazität getrennt zu betrachten. Solana unterscheidet zwischen den Zuständen processed, confirmed und finalized. Eine als processed gekennzeichnete Transaktion wurde von einem Validator verarbeitet, hat aber noch nicht die stärkere Abstimmungsschwelle des confirmed-Status erreicht. Finalized steht für den höchsten Grad an endgültiger Bestätigung. In der Solana-Dokumentation wird confirmed für viele Zahlungsszenarien als ausreichend beschrieben, während finalized sinnvoll sein kann, wenn eine stärkere Sicherheit der Abwicklung benötigt wird. Ein Krypto-Casino entscheidet selbst, welchen Status es vor der Gutschrift einer Einzahlung verlangt. Ein höheres Blocklimit kann einer Transaktion helfen, schneller in die Blockchain aufgenommen zu werden, wenn die Kapazität knapp ist. Es verändert jedoch weder die Bedeutung dieser Bestätigungsstufen noch zwingt es ein Casino dazu, Guthaben früher freizugeben.
Auch der Ablauf einer Transaktion kann die Nutzererfahrung beeinflussen. Eine gewöhnliche Solana-Transaktion verweist auf einen aktuellen Blockhash, der nur für einen begrenzten Zeitraum von 150 Slots gültig bleibt. Wird die Transaktion innerhalb dieses Zeitraums nicht erfolgreich verarbeitet, muss die Wallet oder das Zahlungssystem unter Umständen eine neue Übertragung erstellen und absenden. Zusätzlicher Blockspielraum kann das Risiko verringern, dass eine normale Zahlung ausschließlich wegen vollständig ausgelasteter Blöcke zu lange wartet. Andere Ursachen werden dadurch allerdings nicht beseitigt. Dazu gehören eine instabile RPC-Verbindung, eine fehlerhaft erstellte Transaktion, zu wenig SOL für Gebühren oder eine Wallet, die eine Transaktion nicht korrekt erneut übermittelt. Eine ausstehende Casino-Einzahlung sollte deshalb nicht automatisch als Folge einer Überlastung des Solana-Netzwerks betrachtet werden.

Bei Auszahlungen muss zwischen der internen Bearbeitung des Casinos und der eigentlichen Blockchain-Verarbeitung unterschieden werden. Bevor eine Auszahlung an Solana übermittelt wird, kann das Casino das Spielerkonto prüfen, die Verfügbarkeit des angeforderten Guthabens kontrollieren, Sicherheits- oder Compliance-Verfahren durchführen und die Zahlung in eine interne Warteschlange einordnen. Zusätzlich muss in der Wallet, aus der die Auszahlung gesendet wird, ausreichend Guthaben vorhanden sein. Keiner dieser Schritte wird durch SIMD-0286 beeinflusst. Wenn eine Auszahlung zwanzig Minuten auf eine interne Freigabe wartet, bleibt diese Wartezeit bestehen, selbst wenn die spätere Solana-Transaktion unmittelbar nach der Übermittlung in einen Block aufgenommen wird.
Sobald die Auszahlung an Solana gesendet wurde, wirkt sich das höhere Blocklimit grundsätzlich genauso aus wie bei Einzahlungen. Mehr verfügbare Gesamtkapazität bedeutet, dass eine gültige Auszahlung bessere Chancen hat, aufgenommen zu werden, ohne mit einem Block konkurrieren zu müssen, der bereits das frühere Limit von 60M CUs erreicht hat. Das kann besonders für Dienste relevant sein, die mehrere Auszahlungen gleichzeitig senden, während auch im übrigen Netzwerk hohe Aktivität herrscht. Eine wichtige Einschränkung bleibt jedoch bestehen: Das Limit von 12M CUs für Schreibzugriffe auf ein einzelnes Konto wurde nicht erhöht. Wenn viele Transaktionen wiederholt mit demselben beschreibbaren Konto interagieren, kann diese speziellere Grenze weiterhin eine Rolle spielen, obwohl die gesamte Blockkapazität deutlich größer ist.
Die tatsächliche Auszahlungsdauer hängt außerdem von RPC-Diensten, Transaktionsüberwachung und Indexierung ab. Solana erklärte, dass SIMD-0286 keine Änderung des Indexierungsformats erforderlich machte. Zahlungsdienste mussten daher nicht allein wegen der neuen 100M-CU-Blöcke ein neues Transaktionsformat einführen. Größere Blöcke können jedoch zusätzliche Belastung für Systeme verursachen, die Netzwerkdaten empfangen, speichern und verarbeiten. Solana wies im Zusammenhang mit dem Upgrade darauf hin, dass RPC-Anbieter, Indexer und Börsen ihre Systeme auf dauerhaft größere Blöcke vorbereiten sollten. Deshalb kann eine Auszahlung auf der Blockchain bereits vollständig bestätigt sein, während sie in der Benutzeroberfläche des Casinos noch als in Bearbeitung angezeigt wird, wenn das System zur Erfassung des Transaktionsstatus verzögert arbeitet.
Die sinnvollste Methode zur Bewertung des Upgrades besteht darin, jeden Teil des Zahlungsprozesses getrennt zu messen. Bei Einzahlungen kann zwischen der Zeit von der Übermittlung durch die Wallet bis zur Aufnahme in einen Block, dem Zeitraum von der Blockaufnahme bis zur vom Casino geforderten Bestätigungsstufe und der anschließenden Zeit bis zur tatsächlichen Gutschrift auf dem Spielerkonto unterschieden werden. Bei Auszahlungen sollte entsprechend die interne Bearbeitungszeit von der Phase zwischen der Übermittlung an die Blockchain und der Bestätigung getrennt betrachtet werden. Ohne diese Unterscheidung kann eine langsame Auszahlung schnell als Solana-Verzögerung wahrgenommen werden, obwohl die Transaktion möglicherweise erst nach einem Großteil der gesamten Wartezeit an das Netzwerk gesendet wurde.
Zahlungsanbieter sollten außerdem SOL-Transfers und Token-Transfers als unterschiedliche Zahlungswege überwachen, da dabei verschiedene Konten und interne Verarbeitungsschritte beteiligt sein können. Einstellungen für Prioritätsgebühren sollten an die aktuellen Netzwerkbedingungen angepasst und nicht dauerhaft auf einem Wert belassen werden, der während einer früheren Phase hoher Auslastung festgelegt wurde. Ebenso wichtig sind RPC-Antwortzeiten, fehlgeschlagene Übermittlungen, wiederholte Transaktionsversuche und verzögerte Indexierung, da ein höheres Blocklimit keine unzuverlässige Verbindung zum Netzwerk ausgleichen kann. Besonders wichtig werden diese Kontrollen bei starken Marktbewegungen, wenn sowohl die Blockchain-Aktivität als auch die Nachfrage nach Casino-Ein- und Auszahlungen gleichzeitig steigen können.
Stand September 2026 spricht die verfügbare Datenlage für eine nüchterne Bewertung von SIMD-0286. Solana verfügt heute über 66 % mehr maximale Compute-Kapazität pro Block als unter dem früheren 60M-CU-Limit. Frühe Messungen nach der Aktivierung zeigten außerdem deutlich weniger Blöcke nahe an der neuen Kapazitätsgrenze sowie niedrigere Gebühren im oberen Bereich der Gebührenverteilung. Dadurch entstehen bessere Bedingungen für Ein- und Auszahlungen während netzwerkweiter Belastungsspitzen. Eine sofortige Einzahlung, eine sofortige Auszahlung oder eine feste Transaktionsgebühr werden dadurch jedoch nicht garantiert. Für Nutzer von Krypto-Casinos liegt der wichtigste Vorteil in einer geringeren Abhängigkeit von blockweiter Kapazitätsknappheit. Die endgültige Bearbeitungszeit hängt weiterhin von Bestätigungsanforderungen, dem Verhalten der Wallet, der Leistung von RPC- und Indexierungsdiensten sowie den eigenen Ein- und Auszahlungsprozessen des Casinos ab.