Deine Wallet zeigt eine Vorschau des Swaps, nennt den Betrag, den du erhalten wirst, und meldet kein Problem. Du signierst, und die Transaktion landet als Fehlschlag in der Kette und kostet trotzdem Gas. Die Vorschau hat dich nicht belogen. Sie hat eine Frage über einen Moment beantwortet, und deine Transaktion wurde in einem anderen ausgeführt.
Was eine Simulation tatsächlich ausführt
Eine Wallet-Vorschau ist ein Trockenlauf. Ein Knoten führt deinen Aufruf gegen eine Kopie des Kettenzustands aus, meldet, was passieren würde, und wirft das Ergebnis anschließend weg. Die Entwicklerdokumentation von Ethereum beschreibt die dahinterliegende Methode als eine, die einen neuen Nachrichtenaufruf sofort ausführt, ohne eine Transaktion in der Blockchain zu erzeugen, und die zugehörige Gas-Methode als eine, die eine Schätzung zurückgibt, während die Transaktion der Blockchain nicht hinzugefügt wird.
Aus dieser Beschreibung folgen zwei Eigenschaften, und beide werden später wichtig. Der Trockenlauf wird gegen einen ausgewählten Block ausgeführt, seine Antwort ist also an den Zustand in diesem Block geheftet. Und er läuft allein: Zwischen Aufruf und Ergebnis wird nichts anderes ausgeführt.
Der Zustand, gegen den du simuliert hast, ist nicht der Zustand, in dem du landest
Zwischen Vorschau und Ausführung muss deine Transaktion eine Strecke zurücklegen. Sie wird signiert, verbreitet, in einem Mempool gehalten, von einem Blockproduzenten ausgewählt und erst dann nach den Regeln des Blocks ausgeführt, der sie enthält. Jeder Schritt dieser Strecke braucht Zeit, und die Kette hält währenddessen nicht an.
Vertragscode liest den Zustand zum Ausführungszeitpunkt, niemals zum Simulationszeitpunkt. Poolreserven, eine Orakelantwort, ein erteiltes Ausgabelimit, ein Whitelist-Eintrag, ein Pausen-Flag, eine Obergrenze pro Adresse, eine beendete Auktion: Jeder dieser Werte kann einen Wert haben, wenn die Vorschau läuft, und einen anderen, wenn der Block gebaut wird. Ein Vertrag, der einen solchen Wert prüft und anhält, wenn die Bedingung nicht erfüllt ist, verhält sich in beiden Momenten identisch. Verändert hat sich die Eingabe.
Mindestausgabe und Frist: die Prüfungen, die absichtlich fehlschlagen
Ein Swap-Aufruf kann zwei Schutzvorrichtungen im Aufruf selbst tragen. Die eine ist eine Untergrenze für das, was du erhalten musst, abgeleitet aus deiner Slippage-Toleranz. Die andere ist ein Zeitstempel, nach dem der Aufruf nicht mehr gültig ist. Beide sind Argumente, die du signierst, also sind beide auf den Werten eingefroren, die die Vorschau berechnet hat.
Angenommen, die Vorschau nennt 10.000 USDC für die Token, die du verkaufst, und deine Toleranz steht auf 0,5 %. Dann trägt der Aufruf eine Untergrenze von 9.950 USDC, und der Vertrag erhält die Anweisung, die gesamte Interaktion aufzugeben, statt weniger zu liefern. Wenn sich der Preis weiter bewegt als deine Toleranz, während die Transaktion unterwegs ist, tut die Schutzvorrichtung genau das, worum du sie gebeten hast. Die Frist verhält sich genauso: Ein Aufruf, der länger unbestätigt hängt als sein eigener Zeitstempel, wird bei Ankunft abgewiesen, obwohl derselbe Aufruf Minuten früher durchgegangen wäre.
Das ist der Fall, in dem der Fehlschlag der funktionierende Schutz ist. Eine Schutzvorrichtung, die nie auslöst, würde die Interaktion zu jedem Preis abschließen lassen, zu dem der Markt bis zum Bau des Blocks abgedriftet ist.
Reihenfolge: dieselbe Transaktion an einer anderen Stelle
Ein Block ist eine Abfolge, und die Transaktionsreihenfolge entscheidet, welche Interaktion welchen Zustand sieht. Deine Vorschau hat den Aufruf an den Anfang einer leeren Warteschlange gestellt. Der Block stellt ihn hinter alles andere, was der Produzent dort platziert hat, und diese Nachbarn können genau die Liquidität, genau das Ausgabelimit oder genau den Restbestand verbrauchen, mit denen dein Aufruf gerechnet hat.
Ein Mint mit harter Obergrenze zeigt das deutlich. Zehn Wallets können jeweils das letzte verfügbare Stück erfolgreich simulieren, weil jede Vorschau gegen einen Zustand läuft, in dem dieses Stück noch frei ist. Eine davon landet zuerst, die anderen neun treffen auf einen ausverkauften Vertrag. An den neun Vorschauen war nichts falsch. Sie haben eine Frage beantwortet, die vor dem Entstehen des Blocks eine Antwort hatte und danach eine andere.
Gas: eine Schätzung ist keine Reservierung
Eine Gasschätzung entsteht auf demselben Weg wie die Vorschau, indem der Aufruf einmal ausgeführt und gemessen wird. Dieselbe Dokumentation warnt, dass die Schätzung erheblich höher ausfallen kann als die Gasmenge, die die Transaktion tatsächlich verbraucht, und wehtun tut die Gegenrichtung: Eine Schätzung, die auf einem billigen Pfad gemessen wurde, kann für den Pfad zu knapp sein, den die Transaktion am Ende nimmt.
An den Verzweigungen der Ausführung öffnet sich diese Lücke. Ein Swap, der in der Vorschau über einen Pool geleitet wird, kann bei der Ausführung über zwei laufen; der erste Schreibvorgang in einen Speicherslot kostet mehr als ein späterer in denselben Slot; eine Schleife, die drei Positionen berührt hat, kann neun berühren. Wenn das von dir signierte Limit mitten in der Ausführung ausgeht, wird die geleistete Arbeit rückgängig gemacht, und das Gas ist trotzdem verbraucht, was dieselbe Rechnung ist wie bei jeder fehlgeschlagenen Transaktion. Puffer über der Schätzung erhöht die Gebühr nicht, wenn er ungenutzt bleibt, denn wie Gas bepreist wird trennt die Menge an Arbeit vom Preis pro Arbeitseinheit.
Wenn die Simulation nicht die Transaktion simuliert hat, die du gesendet hast
Manchmal sind Vorschau und Ausführung gar nicht derselbe Aufruf. Eine Simulation wird gegen einen Endpunkt in einem Netzwerk ausgeführt, eine Wallet also, die auf eine andere Kette oder auf einen Knoten mit veraltetem Zustand zeigt, antwortet über eine andere Welt als jene, in die deine Signatur verbreitet wird.
Deine eigene Warteschlange ausstehender Transaktionen ist eine zweite Quelle dieser Abweichung. Transaktionen eines Kontos werden in Nonce-Reihenfolge ausgeführt, ein früherer ausstehender Aufruf aus derselben Wallet läuft also zuerst und kann den Zustand ändern, von dem ein späterer Aufruf abhängt. Wenn dieser frühere Aufruf eine noch nicht bestätigte Genehmigung ist, wird die dahinter eingereihte Interaktion gegen das Limit simuliert, das du erwartest, und gegen das Limit ausgeführt, das du tatsächlich hast.
| Was die Vorschau zeigte | Was sich bis zur Ausführung geändert hat | Wo du nachsiehst |
|---|---|---|
| Einen genannten Ausgabebetrag | Reserven oder die Orakelantwort haben sich bewegt | Das Mindestausgabe-Argument im signierten Aufruf |
| Einen gültigen Aufruf | Der signierte Zeitstempel ist abgelaufen | Das Fristargument und die Wartezeit als ausstehend |
| Verfügbaren Bestand oder Liquidität | Eine andere Transaktion im Block war zuerst dran | Die Position deiner Transaktion in ihrem Block |
| Eine Gasschätzung | Die Ausführung nahm einen längeren Zweig | Verbrauchtes Gas gegen das Gaslimit auf dem Beleg |
| Einen sauberen Trockenlauf | Die Wallet war in einem anderen Netz oder Knoten | Kennung der Kette und Endpunkt beim Signieren |
Wie der Fehlschlag hinterher aussieht
Eine Interaktion, die auf diese Weise anhält, wird aufgezeichnet. Sie belegt eine Position in einem Block, sie verbraucht Gas, und ihr Beleg trägt ein Statusfeld: EIP-658 hat die Zwischenzustandswurzel des Belegs durch einen Statuscode ersetzt, in dem null Fehlschlag und eins Erfolg bedeutet. Explorer machen aus diesem Feld die Bezeichnung zurückgesetzt.
Die Bezeichnung benennt das Ergebnis und nicht die Ursache. Manche Verträge hängen beim Anhalten eine Begründungszeichenkette an, und ein Explorer oder ein Trace kann sie sichtbar machen; andere hängen nichts an. Die fehlgeschlagene Transaktion zusammen mit den Argumenten zu lesen, die du tatsächlich signiert hast, macht aus einem Statuscode eine Diagnose, denn genau diese Argumente kann der Beleg für dich nicht rekonstruieren.
Was die Fehlerquote tatsächlich senkt
Verkürze die Lücke. Eine Vorschau, die kurz vor dem Signieren genommen wird, beschreibt einen Zustand, der dem des Blocks näher ist, und eine schnell bestätigte Transaktion hat weniger Zeit, überholt zu werden.
Bemiss die Schutzvorrichtungen am Wert selbst statt an der Gewohnheit. Eine Untergrenze, die eng genug ist, um eine gewöhnliche Minute Bewegung in einem dünnen Markt abzulehnen, wird deine Interaktionen fortlaufend anhalten, während eine Untergrenze, die locker genug ist, alles zu akzeptieren, den Schutz aufgibt, für den du sie gesetzt hast. Dieselbe Abwägung gilt für die Frist, die lang genug sein muss, um eine Phase der Überlastung zu überstehen.
Behandle einen wiederholten Fehlschlag als Information. Wenn dieselbe Interaktion mit denselben Argumenten mehrfach anhält, meldet der Vertrag eine Bedingung, die derzeit nicht erfüllbar ist, und das erneute Senden desselben Aufrufs gibt Gas für dieselbe Antwort aus.
Fazit
Eine Simulation beantwortet, was passieren würde, wenn dieser Aufruf jetzt, allein, gegen diesen Block liefe. Eine Ausführung in der Kette beantwortet, was passiert ist, als der Aufruf später, zwischen anderen Transaktionen, gegen einen anderen Block lief. Ein Fehlschlag nach einer sauberen Vorschau ist der Abstand zwischen diesen beiden Fragen, und die von dir signierten Schutzvorrichtungen verwandeln diesen Abstand in ein Anhalten statt in eine schlechte Ausführung. Prüfe die Argumente im signierten Aufruf, die Position der Transaktion in ihrem Block und das verbrauchte Gas gegen das Gaslimit, dann liegt der Grund in einem dieser drei. Um weiter die Grundlagen zu lernen, folge weiteren Inhalten der Bitbase Academy.
Weiterführende Artikel
Weitere Bitbase-Artikel zu diesem Thema:
- Wie du RPC-Endpunkte sicher wechselst
- Maximale Transaktionsgebühr überschritten: Was diese Wallet-Warnung bedeutet
- RPC-Ratenlimit überschritten und was dagegen hilft
- FIFO und LIFO bei der Krypto-Kostenbasis
- Memetische Prämie: Warum Memes Preise bewegen
Haftungsausschluss: Dieser Artikel ist Bildungsinhalt der Bitbase Academy, nur zu Informationszwecken. Er ist keine Anlage-, Handels-, Steuer- oder Finanzberatung. Krypto-Assets sind volatil — schätze dein Risiko selbst ein. Stand September 2026; maßgeblich sind die aktuellen offiziellen Informationen.
Quellen
[1] Ethereum.org-Entwicklerdokumentation, JSON-RPC API (eth_call, eth_estimateGas) ethereum.org
[2] Ethereum Improvement Proposals, EIP-658: Embedding transaction status code in receipts eips.ethereum.org
[3] Ethereum.org-Entwicklerdokumentation, „Transaktionen“ (Transactions) ethereum.org
