Zuzusehen, wie ein Swap rot wird, gehört zu den frustrierenderen Erfahrungen auf Solana, besonders in einem Netzwerk, das als schnell und fast kostenlos beworben wird. Die angezeigte Fehlermeldung erklärt selten, was tatsächlich schiefgelaufen ist, und zwar so, dass jemand außerhalb der Protokollentwicklung darauf reagieren könnte.

Das Ermutigende daran: Diese Fehler folgen sehr vorhersehbaren Mustern. Sobald Sie eine vom Netzwerk abgelehnte Transaktion von einer unterscheiden können, die gar nicht erst angekommen ist, liegt die richtige Lösung fast immer in einer einzigen bestimmten Einstellung und nicht darin, noch einmal zu klicken und zu hoffen. 👇

Was ist eine fehlgeschlagene Solana-Transaktion?

Eine fehlgeschlagene Solana-Transaktion ist eine, die erfolgreich einen Validator erreichte, in einen Block aufgenommen und dann bei der Ausführung abgelehnt wurde, weil eine Bedingung, von der sie abhing, nicht mehr erfüllt war. Sie wird dennoch dauerhaft onchain gespeichert, mit einem Fehlercode und Programmprotokollen.

Wallets zeigen dies meist als roten Banner oder einfaches Label „fehlgeschlagen“ ohne weitere Details an. Um den eigentlichen Grund zu finden, fügen Sie die Transaktionssignatur in einen Explorer wie Solscan ein und lesen die Programmprotokolle, die die genaue Anweisung nennen, die zurückgesetzt wurde, und den Grund dafür.

Entscheidend ist, dass die Ausführung auf Solana atomar ist. Wenn eine einzelne Anweisung innerhalb der Transaktion einen Fehler auslöst, werden alle Zustandsänderungen dieser Transaktion vollständig verworfen, sodass Ihre Token-Bestände genau so bleiben wie zuvor. Verloren geht nur die kleine Gebühr für den Versuch.

Diese Atomarität ist ein bewusstes Sicherheitsmerkmal und kein Konstruktionsfehler. Sie stellt sicher, dass Sie nie halb getauscht dastehen, mit auf der einen Seite abgezogenen Token, aber ohne Erhalt auf der anderen, was ein deutlich schlechteres Ergebnis wäre als eine saubere, vollständig rückabgewickelte Ablehnung.

Verworfene vs. fehlgeschlagene Solana-Transaktionen

Diese beiden Ergebnisse sehen innerhalb einer Wallet-Oberfläche nahezu identisch aus, haben aber gegensätzliche Ursachen und erfordern gegensätzliche Lösungen. Sie zu unterscheiden, ist der nützlichste Diagnoseschritt für jeden Solana-Nutzer und kostet nichts als Aufmerksamkeit.

Eine fehlgeschlagene Transaktion gelangte in einen Block und wurde dann von der Programmlogik abgelehnt, wodurch ein dauerhafter Eintrag zurückblieb. Eine verworfene Transaktion erreichte dagegen nie einen Block-Leader, meist weil sie unterwegs abgelaufen ist oder der empfangende RPC-Node überlastet war, und kostet Sie nichts.

Der Mechanismus hinter den meisten verworfenen Transaktionen ist der Ablauf des Blockhash. Jede Solana-Transaktion verweist auf einen aktuellen Blockhash, der für etwa 150 Blöcke oder in Echtzeit etwa 60 bis 90 Sekunden gültig bleibt. Verpasst man dieses enge Zeitfenster, lehnen Validatoren die Transaktion direkt ab. Diese Regel soll Replay-Angriffe verhindern.

Beispiel A (fehlgeschlagen): Sie tauschen USDC per Swap gegen SOL auf Meteora, doch der Preis überschreitet Ihre eingestellte Slippage-Toleranz, während die Transaktion ausgeführt wird, sodass das Programm sie rückgängig macht. Der Versuch erscheint onchain mit einem expliziten Slippage-Fehler und kostet Sie nur die Netzwerkgebühr.

Beispiel B (verworfen): Sie kaufen während eines Launch-Rummels einen Token auf Pump.fun, doch Ihr RPC-Endpunkt hinkt mehrere Slots hinter der Chain-Spitze her und der Blockhash läuft ab, bevor ein Leader die Transaktion sieht. Auf keinem Explorer erscheint etwas, und es wird keine Gebühr berechnet.

Wie viele Solana-Transaktionen schlagen tatsächlich fehl?

Schlagzeilen, wonach die Hälfte aller Solana-Transaktionen fehlschlägt, sind zugleich zutreffend und in der Praxis fast bedeutungslos, da sie enorme Mengen automatisierten Arbitrage-Spams mit den gewöhnlichen Wallet-Aktivitäten zusammenwerfen, die echte Menschen täglich erzeugen.

Wissenschaftliche Forschung aus dem Jahr 2025 beantwortete die Frage schließlich mit harten Zahlen statt Schätzungen. Eine begutachtete Studie zu 1,5 Milliarden fehlgeschlagenen Transaktionen in 72 Millionen Blöcken ergab, dass Bot-Konten zu 58,43 % scheiterten, während von Menschen betriebene Konten mit 6,22 % deutlich seltener scheiterten.

Diese menschliche Zahl ist für den Kontext enorm wichtig. Sie liegt recht nah an der typischen Spanne von 1 bis 3 % bei Ethereum und deutlich unter den Fehlerraten von 21 % und 15,4 %, die auf Base und Arbitrum beobachtet wurden. Damit erscheint Solanas Ruf der Unzuverlässigkeit weitgehend als durch Bots verursachtes statistisches Artefakt und nicht als Problem der Nutzererfahrung.

Die Konzentration unterstreicht denselben Punkt. Die zehn Programme mit den meisten Fehlschlägen machen 77,95 % des Gesamtvolumens aus, wobei allein Raydium Liquidity-Pool V4 für 21,69 % verantwortlich ist, da Sniper-Bots darum wetteifern, neu erstellte Pools zu handeln, bevor die Initialisierung überhaupt abgeschlossen ist.

Überlastung macht sich in Spitzenzeiten dennoch stark bemerkbar. Wenn die Volatilität bei Memecoins sprunghaft ansteigt, sind die gemessenen Erfolgsraten bei Nicht-Vote-Transaktionen auf etwa 76 % gefallen. Das bedeutet, dass etwa jede vierte echte Nutzertransaktion fehlschlägt, trotz der ermutigenden langfristigen Durchschnittswerte, die die akademischen Daten liefern.

Was die Daten über die Gründe für fehlgeschlagene Transaktionen zeigen

Fehlerprotokolle sind deutlich aufschlussreicher, als die meisten Nutzer annehmen, und dieselbe Studie ordnete jeden beobachteten Fehler zehn verschiedenen Kategorien zu. Die resultierende Verteilung ist stark schief, was eine gute Nachricht ist, denn eine kleine Handvoll gezielter Korrekturen behebt den Großteil der Probleme.

Die Fehlerarten hinter fehlgeschlagenen Solana-Transaktionen verteilen sich wie folgt:

• Preis oder Gewinn nicht erreicht (47,99 %): Die Slippage-Toleranz wurde überschritten oder eine Arbitrage-Route war zwischen Übermittlung und Ausführung nicht mehr profitabel, was den Schutz-Revert auslöste, den DEX-Aggregatoren einbauen.
• Ungültiger Status (19,19 %): Die Transaktion richtete sich an ein Konto oder einen Liquidity-Pool in einem Zustand, der die Operation nicht zuließ, häufig ein nicht initialisierter Pool oder ein eingefrorenes Token-Konto.
• Ablauf der Gültigkeit (17,72 %): Der referenzierte Blockhash war veraltet, bevor ein Validator ihn verarbeitete. Das ist der Onchain-Fingerabdruck von Überlastung, verzögerten RPC-Endpunkten oder langsamem clientseitigem Signieren.
• Ungültiges Eingabekonto (3,27 %): Erforderliche Kontoadressen fehlten, waren falsch angeordnet oder nicht autorisiert, ein häufiges Problem bei komplexen Routen, die viele Programme gleichzeitig berühren.
• Ungültige Eingabeparameter (2,55 %): Ein Argument lag außerhalb des Bereichs, den ein Programm akzeptiert, etwa ein auf null gesetzter Mindestausgabebetrag bei einer Raydium-Swap-Anweisung.
• Fehlendes Guthaben (2,16 %): Im Wallet fehlte genug SOL, um die Überweisung sowie Gebühren und Rent zu decken. Dieser Fehler betraf überproportional menschliche Nutzer statt Bots.
• Out of resource (0,49 %): Die Transaktion hat ihr Rechenbudget erschöpft oder Laufzeitgrenzen für den Heap-Speicher überschritten, typisch für Multi-Hop-Routen, die Dutzende Konten berühren.

Eine Erkenntnis verdient besondere Aufmerksamkeit von allen, die versucht sind, einfach mehr zu zahlen. Fehlgeschlagene Transaktionen zahlen tatsächlich höhere Gebühren als erfolgreiche, verbrauchen dabei aber weniger Compute Units und landen dennoch tiefer in den Blöcken. Dem Problem mit Geld zu begegnen, ohne die Compute-Menge richtig zu bemessen, funktioniert nachweislich nicht.

Häufige Gründe für fehlgeschlagene Solana-Transaktionen

Übersetzt in die Praxis häufen sich Fehler bei einigen wenigen Konfigurations- und Timing-Fehlern, die als Nutzer fast vollständig in Ihrer Hand liegen.

Dies sind die häufigsten Ursachen für fehlgeschlagene Solana-Transaktionen:

• Zu enge Slippage: Eine Toleranz unterhalb dessen, was die aktuelle Volatilität erfordert, führt bei Token mit geringer Liquidität garantiert zu Reverts, da sich Preise zwischen Signierung und Ausführung um mehrere Prozent bewegen können.
• Niedrige Prioritätsgebühren: Validatoren ordnen Transaktionen nach dem Preis pro Compute Unit, sodass eine zu niedrig angesetzte Transaktion verdrängt und in Phasen hoher Nachfrage weit nach hinten in die Blöcke geschoben wird.
• Abgelaufener Blockhash: Langsames Signieren, ein verzögerter RPC oder bloßes Zögern bei der Bestätigungsaufforderung kann das Gültigkeitsfenster aufbrauchen, bevor die Transaktion überhaupt einen Leader erreicht.
• Überschreitung der Rechenlimits: Multi-Hop-Routen über mehrere Pools einer dezentralen Börse können die standardmäßige Zuteilung von 200.000 Compute-Einheiten pro Anweisung überschreiten und abbrechen.
• Überlastete RPC: Öffentliche Endpunkte werden von enorm vielen Nutzern gemeinsam genutzt und werden bei Launches stark beeinträchtigt, sodass Transaktionen verworfen werden, bevor sie überhaupt an Validatoren gesendet werden.
• Unzureichendes Guthaben: Gebühren, Rent für neue Token-Konten und Prioritätsgebote werden alle in SOL bezahlt, daher scheitern Wallets, die nur den zu tauschenden Token halten, sofort.
• Geringe Liquidität: Große Orders gegen flache Pools lassen sich zu keinem akzeptablen Preis ausführen und führen zu denselben insufficient liquidity-Reverts, die man von anderen Chains kennt.
• Eingefrorene Konten: Böswillige Token-Deployer können Transfers einfrieren, nachdem sie Käufer angelockt haben. Dieses Honeypot-Muster zeigt sich als Fehlermeldung über einen ungültigen Status, wenn Sie verkaufen möchten.

So beheben Sie fehlgeschlagene Solana-Transaktionen

Sobald Sie festgestellt haben, ob das Problem in der Ausführungslogik oder in der Netzwerkübertragung liegt, ist die Abhilfe meist eine bestimmte Einstellung und nicht die allgemeine Anweisung, es erneut zu versuchen.

Diese Anpassungen beheben die meisten fehlgeschlagenen Solana-Transaktionen:

• Slippage sinnvoll erhöhen: Setzen Sie die Toleranz bei volatilen Token auf 1 bis 3 % und nehmen Sie etwas schlechtere Preise in Kauf, damit die Order ausgeführt wird, statt eine weitere Gebühr zu verschwenden.
• Priority Fees dynamisch bieten: Unter normalen Bedingungen genügen 1.000 bis 5.000 Micro-Lamports pro Compute Unit, während Launches und Liquidationen 100.000 oder mehr erfordern können.
• Compute Units präzise dimensionieren: Simulieren Sie zuerst und setzen Sie das Limit dann nahe am tatsächlichen Verbrauch, denn der Preis kauft Priorität, während ein überhöhtes Limit nur Spielraum verschwendet.
• RPC-Anbieter wechseln: Dedizierte Endpunkte von Helius, Triton oder QuickNode übertragen bei Überlastung zuverlässig, wenn die öffentlichen Standard-Nodes bereits ausgelastet sind und Anfragen verwerfen.
• Vor dem erneuten Versuch aktualisieren: Holen Sie für jeden Versuch einen neuen Blockhash, statt den ursprünglichen erneut zu senden, der wahrscheinlich abgelaufen ist und erneut stillschweigend fehlschlägt.
• Halten Sie etwas SOL in Reserve: Solflare empfiehlt, mindestens 0,05 SOL unangetastet zu lassen, genug, um Grundgebühren, Prioritätsgebote und eventuelle Rent-Einlagen bequem abzudecken.
• Vorschau vor dem Signieren: Die Wallet-Simulation erkennt zum Scheitern verurteilte Transaktionen kostenlos, während ein Fehlschlag onchain dennoch die Basisgebühr und ein eventuell angehängtes Prioritätsgebot kostet.

Wie viel kostet eine fehlgeschlagene Solana-Transaktion?

Der finanzielle Schaden durch eine fehlgeschlagene Transaktion ist minimal, was einer der echten strukturellen Vorteile von Solana gegenüber Chains mit höheren Gebühren ist. Jede Transaktion trägt eine Grundgebühr von 0,000005 SOL pro Signatur, und diese fällt an, unabhängig davon, ob die Ausführung am Ende gelingt oder auf halbem Weg zurückgesetzt wird.

Zusätzliche Kosten fallen situationsabhängig und nicht generell an. Für die Eröffnung eines neuen Token-Kontos ist eine einmalige Rent-Einzahlung von rund 0,002 SOL erforderlich, während eine von Ihnen angehängte Priority Fee als Compute-Unit-Preis multipliziert mit dem Compute-Unit-Limit berechnet und anschließend durch eine Million geteilt wird.

Seit Februar 2025 gehen 100 % der Prioritätsgebühren direkt an Validatoren, statt dass die Hälfte davon verbrannt wird, nach der Aktivierung der Governance-Änderung SIMD-0096. Die Basisgebühr selbst wird weiterhin zu gleichen Teilen zwischen dem Verbrennen und dem Blockproduzenten aufgeteilt, der Sie aufnimmt.

Beispiel: Sie eröffnen über eine Perps-Plattform eine gehebelte SOL-Position, der Preis bewegt sich während der Übertragung über Ihre Toleranz hinaus, und die Transaktion wird zurückgesetzt. Ihre Sicherheiten bleiben unberührt, und Sie verlieren einen Bruchteil eines Cents. Eine ausführlichere Aufschlüsselung finden Sie in unserem Leitfaden zu Solana-Gas-Gebühren.

Wie Firedancer und Alpenglow das Bild verändern

Das Netzwerk selbst verändert sich in einer Weise, die gezielt die Überlastung angeht, die für verworfene Transaktionen verantwortlich ist. Dadurch unterscheidet sich der Handel 2026 deutlich vom Memecoin-Chaos Anfang 2024, das Solanas Ruf der Unzuverlässigkeit überhaupt erst prägte.

1. Firedancer

Firedancer, der unabhängige Validator-Client, den Jump Crypto von Grund auf in C und C++ geschrieben hat, ging im Dezember 2025 nach umfangreichen Tests im Mainnet live. Mitte 2026 liefen etwa 14 % des Netzwerk-Stakes auf dem vollständigen Firedancer, weitere 26 % auf der hybriden Variante Frankendancer.

Client-Vielfalt ist für die Zuverlässigkeit unmittelbar wichtig. Bis vor Kurzem nutzte jeder einzelne Validator Agave-basierte Software, sodass ein unentdeckter Fehler die gesamte Chain auf einmal zum Stillstand bringen konnte. Zwei wirklich unabhängige Implementierungen beseitigen diesen Single Point of Failure und schaffen wertvollen zusätzlichen Durchsatzspielraum bei Lastspitzen.

2. Alpenglow

Alpenglow ist die deutlich größere Änderung, die noch aussteht. Die Validatoren haben sie im September 2025 mit 98,27 % Zustimmung genehmigt. Sie ersetzt sowohl Tower BFT als auch Proof of History vollständig und zielt auf eine Transaktionsfinalität von etwa 150 Millisekunden ab, verglichen mit rund 12,8 Sekunden beim aktuellen Design.

Bei den Fehlerraten fällt ein Detail besonders auf, das über die Latenzwerte hinausgeht. Alpenglow entfernt die Validator-Vote-Transaktionen vollständig aus dem Blockspace, und da Votes den Großteil des rohen Netzwerkdurchsatzes beanspruchen, sollte die frei werdende Kapazität die Überlastung, die bei Spitzenlast zu Ausfällen führt, spürbar verringern.

Das Gebührendesign selbst bleibt jedoch ungeklärt. Die feste Basisgebühr pro Signatur bei Solana reagiert in keiner Weise auf die Nachfrage, und ein ressourcenbasiertes Redesign, das Rechenleistung und Kontozugriff einzeln bepreisen würde, wird 2026 durchgehend aktiv diskutiert, ohne dass eine finale Spezifikation vorliegt.

Bewährte Vorgehensweisen zur Vermeidung fehlgeschlagener Transaktionen auf Solana

Vorbeugung ist bei Solana immer besser als Fehlersuche, denn die Einstellungen, die Fehler verursachen, werden lange gewählt, bevor etwas bei einem Validator ankommt. Einige Gewohnheiten, die Sie vor dem Handelsstart etablieren, beseitigen die meisten Fehler, die Sie sonst mitten in der Sitzung unterbrechen und Sie Einstiegspreise kosten würden.

1. Halten Sie Ihr Setup aktuell

Veraltete Software und gemeinsam genutzte öffentliche Infrastruktur verursachen beide Ausfälle, die nichts mit Ihren gewählten Handelsparametern zu tun haben. Kümmern Sie sich zuerst um dieses Fundament:

• Aktualisieren Sie Wallets regelmäßig: Phantom, Solflare und Backpack liefern häufig Verbesserungen bei der Gebührenschätzung aus, und veraltete Versionen verpassen Kompatibilitätskorrekturen für Änderungen bei Runtime und Validator.
• Nutzen Sie einen privaten Endpunkt: Dedizierter RPC-Zugang kostet wenig und beseitigt die größte Einzelursache für verlorene Transaktionen bei Launches und anderen Ereignissen mit hohem Datenverkehr.
• Hängende Sitzungen beenden: Ein Neustart der Erweiterung oder des Browsers behebt zwischengespeicherte Verbindungszustände, die noch lange nach der Erholung der Netzwerkbedingungen unbemerkt wiederholte Fehler verursachen.

2. Vor der Bestätigung konfigurieren

Die meisten Reverts werden durch die Einstellungen bestimmt, die Sie vor dem Signieren wählen, und nicht dadurch, was in diesem Moment im Netzwerk selbst geschieht:

• Slippage an die Volatilität anpassen: Neu gestartete Token benötigen deutlich größere Toleranzen als etablierte Paare, bei denen enge Einstellungen Sie schützen, ohne die Ausführung nennenswert zu gefährden.
• Komplexe Routen simulieren: Lassen Sie sich Swaps, die mehrere Pools berühren, vorab anzeigen, denn die Simulation zeigt Rechenverbrauch und Probleme beim Kontostatus völlig kostenlos an.
• Gebührenpuffer aufstocken: Halten Sie SOL getrennt von Ihrer Trading-Position, damit Rent-Einzahlungen und Prioritätsgebote nie mit den Assets konkurrieren, die Sie handeln möchten.

3. Wählen Sie den richtigen Zeitpunkt für Ihre Transaktionen

Der Zeitpunkt, zu dem Sie eine Transaktion absenden, ist fast so wichtig wie ihre Konfiguration, da sich die Netzwerküberlastung stark auf einige vorhersehbare Zeitfenster konzentriert:

• Meiden Sie Launch-Zeitfenster: Starts von Memecoins, Airdrop-Claims und Liquidation-Kaskaden erzeugen den Bot-Spam, der gewöhnliche Nutzer am stärksten verdrängt.
• Große Vorgänge aufteilen: Wer mehrstufige DeFi-Aktionen in separate Transaktionen aufteilt, hält jede innerhalb der Rechenlimits und beschränkt einen Fehler auf eine einzelne Komponente.

Fazit

Fehlgeschlagene Solana-Transaktionen sind günstig, vollständig umkehrbar und größtenteils vermeidbar, sobald Sie sie verstehen. Nichts wird bewegt, nichts geht verloren außer einem Bruchteil eines Cents, und die jedem Versuch beigefügten Fehlerprotokolle zeigen genau, welche Bedingung nicht erfüllt war und warum.

Wichtig ist der Unterschied zwischen Ablehnung und Nichtzustellung. Eine fehlgeschlagene Transaktion bedeutet, dass Ihre Parameter falsch waren, während eine verworfene Transaktion nie angekommen ist. Wer beides verwechselt, erhöht die Gebühren, obwohl er eigentlich einen Blockhash aktualisieren sollte.

Da Firedancer bereits im Mainnet live ist und die Aktivierung von Alpenglow näher rückt, nehmen die netzwerkseitigen Ausfallursachen Jahr für Jahr stetig ab. Übrig bleibt die Konfiguration, und die lag schon immer vollständig in Ihrer eigenen Hand.