Solana-Transaktion fehlgeschlagen: Woran du erkennst, ob dein Swap wirklich durch ist

Wenn dein Swap auf Solana im Explorer rot angezeigt wird, ist die kurze Antwort: Die Transaktion wurde in einen Block aufgenommen, aber ihre Anweisung wurde nicht ausgeführt. Dein Guthaben ist unverändert, die Gebühr ist trotzdem abgebucht, und ein zweiter Versuch ist erlaubt. Wie häufig das passiert, hat cryptoticker.io am 14. September 2026 selbst gemessen: In 36 aufeinanderfolgenden Blöcken der Solana-Mainnet-Kette scheiterte zwischen jeder achten und jeder zweiten Transaktion, je nach Block.

Das ist kein Ausnahmezustand und kein Netzwerkausfall. Es ist der Normalbetrieb einer Kette, auf der ein großer Teil des Verkehrs von automatisierten Handelsprogrammen stammt, die bewusst öfter verlieren als gewinnen. Für dich als Anleger hat das eine praktische Folge: Eine rote Zeile im Explorer bedeutet fast nie, dass etwas mit deinem Wallet nicht stimmt.

Solana-Transaktion fehlgeschlagen: Was der Status „failed" wirklich bedeutet

Eine Solana-Transaktion durchläuft zwei getrennte Hürden. Die erste ist die Aufnahme in einen Block: Ein Validator nimmt deine Transaktion entgegen, prüft die Signatur und schreibt sie in den nächsten Slot, für den er zuständig ist. Die zweite Hürde ist die Ausführung: Das angesprochene Programm rechnet die Anweisung durch und entscheidet, ob sie gültig ist.

Fehlgeschlagen heißt auf Solana immer, dass die erste Hürde genommen und die zweite gerissen wurde. Die Transaktion steht dauerhaft in der Kette, mit Zeitstempel, Signatur und Fehlerobjekt. Sie ist damit etwas anderes als eine Transaktion, die nie ankam: Die taucht im Explorer überhaupt nicht auf, weil sie verworfen wurde, bevor ein Validator sie in einen Block schrieb.

Dieser Unterschied ist wichtiger, als er klingt. Bei Bitcoin hängt eine Transaktion im Mempool fest und wartet auf Bestätigung, manchmal stundenlang. Auf Solana gibt es diesen Schwebezustand kaum: Nach wenigen Sekunden ist entschieden, ob deine Transaktion erfolgreich war, gescheitert ist oder gar nicht erst aufgenommen wurde.

Warum dein Guthaben nach einem Fehlschlag unverändert ist

Solana führt jede Transaktion atomar aus. Entweder alle Anweisungen darin gehen durch, oder keine. Bricht eine Anweisung mit einem Fehler ab, macht die Laufzeitumgebung sämtliche Kontoänderungen der Transaktion rückgängig. Der Tausch findet nicht statt, die Token bleiben, wo sie waren.

Was nicht zurückgenommen wird, ist die Gebühr. Sie ist der Preis dafür, dass Validatoren deine Transaktion geprüft und Rechenzeit aufgewendet haben, und dieser Aufwand ist unabhängig davon angefallen, ob die Anweisung am Ende gültig war.

Eigene Messung: Wie viele Solana-Transaktionen im Messfenster gescheitert sind

Für diesen Artikel haben wir am 14. September 2026 drei getrennte Zeitfenster der Solana-Mainnet-Kette ausgewertet, alle in Epoche 1034 rund um Slot 446.981.000. Abgefragt wurde der öffentliche RPC-Endpunkt des Netzwerks, ausgewertet wurde jede einzelne Transaktion der Blöcke auf ihr Fehlerobjekt.

Stimmrechts-Transaktionen der Validatoren haben wir dabei herausgerechnet. Sie machen auf Solana einen Großteil des Volumens aus, laufen vollautomatisch und scheitern praktisch nie. In unserem ersten Fenster waren es 9.390 Stück, von denen 36 fehlschlugen, eine Quote von 0,38 Prozent. Wer sie mitzählt, erhält eine Zahl, die für Nutzer bedeutungslos ist.

Übrig bleiben die Transaktionen, die Menschen und Handelsprogramme tatsächlich absenden. Davon haben wir 17.987 Stück in 36 Blöcken ausgewertet:

• Fenster 1, 14 Blöcke, 7.905 Transaktionen: 41,9 Prozent gescheitert
• Fenster 2, 10 Blöcke, 4.133 Transaktionen: 22,0 Prozent gescheitert
• Fenster 3, 12 Blöcke, 5.949 Transaktionen: 29,6 Prozent gescheitert

Über alle drei Fenster zusammen ergibt das 33,2 Prozent. Diese Zahl sollte man nicht als Konstante lesen. Einzelne Blöcke lagen bei 13,2 Prozent, andere bei 66,1 Prozent, und die Spanne zwischen den drei Fenstern zeigt, wie stark der Wert innerhalb weniger Minuten schwankt. Belastbar ist die Größenordnung: Grob jede dritte Nicht-Vote-Transaktion auf Solana kommt nicht durch.

Warum eine fehlgeschlagene Solana-Transaktion trotzdem Gebühren kostet

Die Grundgebühr auf Solana beträgt 5.000 Lamports je Signatur. Ein Lamport ist ein Milliardstel SOL, die Grundgebühr entspricht also 0,000005 SOL. Bei einem SOL-Kurs von 87,79 Euro am 14. September 2026 laut CoinGecko sind das rund 0,0004 Euro, also ein Bruchteil eines Cents.

In unserem dritten Fenster flossen insgesamt 0,1371 SOL an Gebühren. Davon entfielen 0,0416 SOL auf Transaktionen, die anschließend fehlschlugen, ein Anteil von 30,4 Prozent. Umgerechnet sind das etwa 3,65 Euro in zwölf Blöcken, hochgerechnet auf einen Tag eine Größenordnung, die für das Netzwerk zählt und für dich persönlich nicht.

Der wirtschaftliche Schaden eines Fehlschlags liegt deshalb woanders. Nicht die Gebühr tut weh, sondern der Kurs: Wenn dein Verkauf bei einem bestimmten Preis scheitert und du dreißig Sekunden später erneut sendest, handelst du zu dem Preis, der dann gilt. Wer in einem schnellen Markt mehrfach hintereinander scheitert, zahlt die Differenz.

Prioritätsgebühr und Fehlerquote: Was die Messung über den Aufschlag sagt

Die verbreitete Faustregel lautet, man solle bei Problemen einfach die Prioritätsgebühr erhöhen. Eine Prioritätsgebühr ist ein freiwilliger Aufschlag auf die Grundgebühr, mit dem du dem Validator signalisierst, deine Transaktion bevorzugt zu verarbeiten. Wir haben in unserem dritten Fenster für jede der 5.949 Transaktionen den Aufschlag über der Grundgebühr berechnet und die Fehlerquote je Preisklasse ausgewertet.

Das Ergebnis steht quer zur Faustregel. Transaktionen ganz ohne Aufschlag scheiterten in unserem Fenster am seltensten, Transaktionen mit kleinem Aufschlag am häufigsten. Innerhalb der zahlenden Gruppe sinkt die Fehlerquote mit steigendem Aufschlag, aber sie fällt nie auf das Niveau der Gruppe, die gar nichts zahlt.

Daraus folgt nicht, dass ein Aufschlag schadet. Wir messen hier keine Wirkung, sondern eine Zusammensetzung. Wer einen Aufschlag zahlt, hat meist einen Grund dazu: Er handelt gegen andere Programme um denselben Preis und nimmt in Kauf, dass er das Rennen oft verliert. Wer keinen zahlt, verschickt typischerweise eine einfache Überweisung, bei der es nichts zu verlieren gibt. Die beiden Gruppen tun unterschiedliche Dinge, und das erklärt den Unterschied besser als der Preis.

Praktisch heißt das: Ein höherer Aufschlag hilft dir dabei, überhaupt aufgenommen zu werden, wenn die Kette ausgelastet ist. Gegen eine Anweisung, die inhaltlich abgelehnt wird, hilft er nicht. Der Median-Aufschlag lag in unserem Fenster bei 163 Lamports, das neunzigste Perzentil bei 12.011 Lamports, und 31,0 Prozent aller Transaktionen zahlten gar keinen Aufschlag.

InstructionError lesen: Was Fehlerindex und Custom-Code verraten

Klickst du im Explorer auf eine gescheiterte Transaktion, siehst du ein Fehlerobjekt in einer festen Form, zum Beispiel InstructionError: [3, {"Custom": 6001}]. Es enthält zwei Angaben, und beide sind nützlich.

Die erste Zahl ist der Fehlerindex: die Position der Anweisung innerhalb deiner Transaktion, die abgebrochen ist, gezählt ab null. Eine Drei bedeutet, dass die ersten drei Anweisungen durchliefen und die vierte scheiterte. Bei einem Swap sind die ersten Anweisungen häufig Vorbereitungen, etwa das Setzen des Rechenbudgets, und die eigentliche Handelsanweisung steht weiter hinten.

Die zweite Angabe ist der Custom-Code: eine Fehlernummer, die nicht vom Netzwerk stammt, sondern von dem Programm, das die Anweisung abgelehnt hat. Dieselbe Nummer bedeutet in zwei verschiedenen Programmen zwei verschiedene Dinge. Die häufigsten Codes in unserem ersten Fenster waren 11 mit 631 Treffern, 6001 mit 394 Treffern über zwei Fehlerindizes, 1 mit 173 Treffern und 7 mit 124 Treffern.

Anchor-Fehlercodes ab 6000: Warum die Zahl allein nichts erklärt

Ein Teil dieser Codes lässt sich einordnen, ohne das jeweilige Programm zu kennen. Viele Solana-Programme sind mit dem Entwicklungsrahmen Anchor gebaut, und der vergibt Nummernbereiche nach einem festen Schema: Ab 100 stehen Anweisungsfehler, ab 2000 Bedingungsfehler, ab 3000 Kontofehler, und ab 6000 beginnen die selbst definierten Fehler des jeweiligen Programms.

Ein Code wie 6001 stammt also aus dem Bereich, den das Programm selbst belegt hat. Was er konkret bedeutet, steht in der Schnittstellenbeschreibung dieses Programms, die der Explorer bei bekannten Programmen mit anzeigt. Niedrige Codes wie 1 oder 11 kommen dagegen meist von Programmen außerhalb dieses Rahmens, etwa der Token-Verwaltung des Netzwerks.

Für dich bedeutet das: Notiere dir den Fehlerindex und den Code, aber leite aus der Zahl allein keine Ursache ab. Die Zuordnung liefert der Explorer, nicht die Nummer.

Transaktionsstatus selbst prüfen: Signatur, Explorer und getSignatureStatuses

Bevor du eine Transaktion wiederholst, solltest du ihren Status feststellen. Ein zweiter Versuch, während der erste noch läuft, führt im schlechtesten Fall dazu, dass beide durchgehen und du doppelt tauschst.

Der einfache Weg führt über die Signatur, die eindeutige Kennung deiner Transaktion. Jedes Wallet zeigt sie nach dem Absenden an, meist als lange Zeichenkette mit einem Link zum Explorer. Findest du die Signatur dort mit grünem Haken, ist der Vorgang erfolgt. Steht sie dort als fehlgeschlagen, ist er endgültig gescheitert und du kannst gefahrlos erneut senden.

Findest du die Signatur überhaupt nicht, wurde deine Transaktion nie in einen Block aufgenommen. Auch dann ist ein zweiter Versuch sicher, denn jede Solana-Transaktion enthält einen aktuellen Blockhash und verfällt, sobald dieser zu alt ist. Das Zeitfenster dafür ist kurz und liegt im Bereich von etwa anderthalb Minuten.

Wer es genauer braucht, fragt den Status direkt beim Netzwerk ab. Die RPC-Methode getSignatureStatuses der Solana-Dokumentation liefert zu einer Signatur den Bestätigungsgrad und, falls vorhanden, das Fehlerobjekt. Das ist derselbe Datensatz, aus dem auch unsere Messung stammt.

Welche Ansicht dir dein Wallet dabei anbietet, unterscheidet sich erheblich. Manche Programme zeigen nur „erfolgreich" oder „fehlgeschlagen", andere blenden den Fehlercode und den betroffenen Anweisungsschritt direkt ein. Ein Blick in den Vergleich der Software-Wallets lohnt sich deshalb auch unter diesem Gesichtspunkt.

Slippage, Blockhash und Kontodeckung: Die häufigsten Ursachen im Alltag

Drei Ursachen decken einen Großteil der Fehlschläge ab, die Privatanleger tatsächlich erleben.

Die erste ist die Slippage-Grenze: der Preisbereich, den du beim Tausch noch akzeptierst. Handelsprogramme auf Solana prüfen diese Grenze am Ende der Berechnung. Hat sich der Kurs zwischen Absenden und Ausführung weiter bewegt als erlaubt, bricht die Anweisung ab. Das ist eine Schutzfunktion und kein Defekt. Eine sehr enge Grenze schützt dich vor schlechten Kursen und erhöht zugleich die Zahl der Fehlschläge.

Die zweite ist der abgelaufene Blockhash. Jede Transaktion verweist auf einen kürzlich erzeugten Block und ist nur für eine begrenzte Zahl von Blöcken danach gültig. Bestätigst du in deinem Wallet mit Verzögerung, weil du zwischendurch das Gerät weglegst, kann sie verfallen, bevor sie ankommt. In diesem Fall erscheint sie gar nicht erst im Explorer.

Die dritte ist die fehlende Kontodeckung, und zwar nicht beim gehandelten Token, sondern bei SOL selbst. Jede Transaktion braucht SOL für die Gebühr, und das Anlegen eines neuen Token-Kontos erfordert zusätzlich eine Mindesteinlage. Wer sein gesamtes SOL tauscht, kann anschließend keine einzige Transaktion mehr senden. Eine kleine Reserve auf dem Konto zu lassen, erspart diesen Zustand.

Kommt dein Kapital von einer Handelsplattform, lohnt vor dem ersten Tausch der Blick darauf, welche Auszahlungswege dein Anbieter überhaupt anbietet und welche Gebühr er dafür nimmt. Unser Vergleich der Krypto-Börsen ordnet die gängigen Anbieter nach diesen Punkten.

Transaktionsformat v1: Was das Solana-Upgrade daran ändert und was nicht

Seit dem 9. September 2026 ist auf Solana ein neues Transaktionsformat aktiv, das die maximale Größe einer Transaktion von 1.232 auf 4.096 Bytes anhebt. Wir haben die Umstellung und ihre Folgen vorab ausführlich beschrieben. Unsere Messung liegt fünf Tage danach und zeigt eine Kette im Normalbetrieb.

An der Fehlerquote ändert das Format wenig, und das ist zu erwarten. Eine größere Transaktion darf mehr Anweisungen enthalten, sie wird dadurch aber nicht eher angenommen. Ob ein Programm deinen Tausch ablehnt, weil der Preis weggelaufen ist, hängt nicht davon ab, wie viele Bytes die Anweisung belegt.

Der nächste größere Eingriff ist das Konsensverfahren Alpenglow, das für Oktober 2026 angekündigt ist und die Zeit bis zur Endgültigkeit einer Transaktion deutlich verkürzen soll. Betreiber eines eigenen Knotens müssen sich darauf vorbereiten, für dich als Nutzer ändert sich der Ablauf nicht. Auch hier gilt: Eine schnellere Endgültigkeit verkürzt die Wartezeit, sie macht aus einer abgelehnten Anweisung keine gültige.

Grenzen der Messung: Was diese Auswertung nicht zeigt

Unsere Erhebung umfasst 36 Blöcke aus drei Zeitfenstern eines einzigen Tages. Das genügt, um die Größenordnung zu belegen, und es genügt nicht für eine Aussage über einen Wochen- oder Monatsdurchschnitt. Die Spanne von 13,2 bis 66,1 Prozent zwischen einzelnen Blöcken zeigt, wie schnell sich der Wert bewegt.

Wir konnten außerdem nicht bestimmen, welcher Anteil der gescheiterten Transaktionen von Privatpersonen stammt und welcher von automatisierten Handelsprogrammen. Diese Unterscheidung lässt sich aus den Blockdaten nicht sauber ziehen, weil beide dieselben Programme ansprechen. Die verbreitete Einschätzung, dass der überwiegende Teil auf automatisierte Arbitrage entfällt, deckt sich mit dem Muster unserer Daten, belegen können wir sie mit dieser Methode nicht.

Die reale Fehlerquote für einen Menschen, der gelegentlich einen Swap auslöst, dürfte daher deutlich unter unserem Gesamtwert liegen. Wie weit darunter, ist offen.

Unverändert bleibt dagegen der Mechanismus, und der ist der eigentliche Inhalt dieses Artikels: Aufnahme und Ausführung sind zwei Schritte, nur der zweite entscheidet über deinen Tausch, und der Explorer sagt dir eindeutig, welcher der beiden gerissen ist.

Diese Auswertung hat cryptoticker.io am 14. September 2026 selbst erhoben.

Solana-Fehlerquote prüfen: Was du daraus mitnimmst

1. Prüfe die Signatur, bevor du erneut sendest. Grüner Haken heißt erfolgt, rote Markierung heißt endgültig gescheitert, gar kein Eintrag heißt nie angekommen. In allen drei Fällen weißt du, ob ein zweiter Versuch doppelt tauschen würde. Welches Wallet dir Fehlercode und Anweisungsschritt dabei überhaupt anzeigt, steht im Software-Wallet-Vergleich.
2. Behandle die Slippage-Grenze als Stellschraube, nicht als Fehlerquelle. Scheitert dein Tausch mehrfach an derselben Stelle, ist die Grenze für die aktuelle Marktbewegung zu eng. Weiter stellen bedeutet mehr Preisrisiko, enger stellen bedeutet mehr Fehlschläge. Wer regelmäßig größere Beträge tauscht, prüft die Konditionen der Handelsplätze im Börsenvergleich.
3. Halte eine SOL-Reserve auf dem Konto. Ohne SOL für Gebühr und Kontoeinlage kommt keine Transaktion durch, auch nicht die, mit der du das Problem beheben willst. Wer seine Tauschvorgänge automatisiert laufen lässt, sollte diesen Puffer fest einplanen; welche Werkzeuge das unterstützen, zeigt der Vergleich der Trading-Bots.

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