Die Wallet meldet bestätigt. Die Explorer-Seite zeigt ein grünes Häkchen. Und die Token sind nicht im Konto. Nichts hängt fest und nichts muss erneut gesendet werden: Das Statusfeld hat eine engere Frage beantwortet als die, die du stellst. Hier steht, was dieses Feld bescheinigt, was es auslässt und wo die Antwort steht, nach der du tatsächlich suchst.
Was ein Erfolgsstatus tatsächlich bescheinigt
EIP-658 hat einen Statuscode in den Transaktionsbeleg gesetzt und seine beiden Werte in einer Zeile definiert: 0 steht für Fehlschlag, verursacht durch jede Operation, die die Transaktion oder den Aufruf auf oberster Ebene zurücksetzen kann, und 1 steht für Erfolg. Ein Block-Explorer macht aus dieser 1 ein Häkchen.
Entscheidend ist die Reichweite dieser Definition. Der Code beschreibt den Aufruf auf oberster Ebene. Er meldet, dass der äußerste Teil der Ausführung ohne Zurücksetzen beendet wurde, und er meldet nichts darüber hinaus: nicht, dass sich ein bestimmtes Token-Guthaben geändert hat, nicht, dass sich der Betrag bewegt hat, den du gemeint hast, und nicht, dass der aufgerufene Vertrag getan hat, worum du ihn gebeten hast. Ein Beleg mit Status 0 ist das, was ein Explorer als reverted kennzeichnet. Ein Beleg mit Status 1 schließt genau das aus und hört dort auf.
Jeder Fall weiter unten wohnt in dieser Lücke. Die Kette hat vollständig festgehalten, was geschehen ist. Die Zusammenfassung aus einem Wort oben auf der Seite hat eine andere Frage beantwortet.
| Die Frage, die du stellst | Wo die Antwort festgehalten ist |
|---|---|
| Hat sie einen Block erreicht | Die Blocknummer auf dem Beleg |
| Hat der äußerste Aufruf ein Zurücksetzen vermieden | Der Statuscode auf dem Beleg |
| Hat sich dieses Token-Guthaben geändert | Die Transfer-Ereignisse in den Protokollen |
| Hat meine User Operation ihre Arbeit erledigt | Das Erfolgs-Flag in ihrem eigenen Ereignis |
Warum ein Token-Transfer ohne Zurücksetzen fehlschlagen kann
Der Standard für den ERC-20-Token deklariert transfer als Funktion, die einen booleschen Wert zurückgibt, und wird bei der Konsequenz deutlich: Aufrufer müssen false aus returns bool success behandeln, und Aufrufer dürfen nicht annehmen, dass false nie zurückgegeben wird. Ein Fehlschlag darf als Rückgabewert eintreffen statt als Zurücksetzen.
Meldet ein Token den Fehlschlag auf diese Weise, hängt das Ergebnis am Vertrag, der ihn aufgerufen hat. Ein Aufrufer, der den booleschen Wert prüft, kann bei false zurücksetzen, und der Beleg kommt mit Status 0 zurück. Ein Aufrufer, der den Wert verwirft, läuft weiter, der äußerste Aufruf wird beendet, der Beleg meldet Erfolg, und das Guthaben hat sich nie bewegt.
Die Rückgabewerte unterscheiden sich noch auf eine zweite Weise. Die Bibliothek SafeERC20 von OpenZeppelin beschreibt sich selbst als Wrapper um ERC-20-Operationen, die bei Fehlschlag eine Ausnahme werfen, wenn der Token-Vertrag false zurückgibt, und ergänzt, dass Token, die gar keinen Wert zurückgeben, ebenfalls unterstützt werden und Aufrufe ohne Zurücksetzen als erfolgreich angenommen werden. Eine Bibliothek, die geschrieben wurde, um diese Rückgabewerte zu vereinheitlichen, ist ein direkter Beleg dafür, dass sie nicht einheitlich sind.
Fehlschläge, die ein Vertrag absichtlich schluckt
Ein Vertrag kann einen anderen Vertrag aufrufen und vorab entscheiden, nicht gemeinsam mit ihm zu scheitern. Das try-und-catch-Konstrukt in Solidity und der Low-Level-Aufruf, der ein Erfolgs-Flag zurückgibt, statt ein Zurücksetzen nach oben weiterzureichen, existieren genau dafür, dass die Ausführung über einen inneren Fehlschlag hinweg weiterlaufen kann. Router, Batcher und Relayer nutzen das absichtlich: Ein Bein eines Stapels schlägt fehl, die übrigen Beine werden abgewickelt, und die Transaktion als Ganzes ist ein Erfolg.
Vom Beleg aus gesehen ist das vom vorherigen Fall nicht zu unterscheiden. Ein innerer Aufruf ist fehlgeschlagen, der äußere Aufruf hat den Fehlschlag aufgefangen, und das Statusfeld hält das äußere Ergebnis fest. Der innere Fehlschlag steht weiterhin in der Kette, aber er sitzt in der Ausführungsspur und in dem, was die Protokolle nicht enthalten, nicht im Statusfeld.
Ein zu kleines Ausgabelimit ist ein Weg in diese Form. Ein Vertrag, der deine Token per transferFrom bewegt, gibt innerhalb des Limits aus, das du mit einer Token-Genehmigung gesetzt hast. Ist das Limit kleiner als der abgerufene Betrag, schlägt der innere Aufruf fehl, und ob die ganze Transaktion mit ihm fehlschlägt, entscheidet der Aufrufer und nicht der Token.
Wenn weniger ankommt, als gesendet wurde
Im dritten Fall schlägt gar nichts fehl, und die Rechnung geht trotzdem nicht auf. Ein Token-Vertrag kann in seiner eigenen transfer-Funktion etwas einbehalten und dem Empfänger weniger gutschreiben, als der Absender übergeben hat. Sende 5.000 Einheiten eines Tokens, der 3% bei jedem Transfer nimmt, und es kommen 4.850 an. Der Beleg meldet Erfolg, das Transfer-Ereignis ist da, und die Zahl darin ist nicht die Zahl, die eingetippt wurde.
Rebasing-Token erzeugen eine verwandte Abweichung von der anderen Seite. Ihre Guthaben werden vom Vertrag umgeschrieben statt durch einen Transfer bewegt, sodass sich ein Guthaben ohne jedes Transfer-Ereignis dahinter ändern kann. Die Anzeige einer Wallet mit den Beträgen im Transaktionsverlauf abzugleichen, geht bei einem solchen Token nicht auf, und keine der beiden Lesarten ist falsch.
Was eine fehlgeschlagene Paymaster-Transaktion bedeutet
Unter Account Abstraction ist das, was du einreichst, keine Transaktion. ERC-4337 definiert ein UserOperation-Objekt mit einem eigenen Mempool und einen Bundler, der solche Objekte in eine gewöhnliche Transaktion an einen EntryPoint-Vertrag packt. Ein Paymaster ist ein Vertrag, der zustimmt, die Transaktion anstelle des Senders zu bezahlen. Eine Fehlermeldung, die den Paymaster nennt, deckt zwei Situationen ab, die außer dem Wort fehlgeschlagen nichts gemeinsam haben.
Die erste ist eine Ablehnung während der Validierung. ERC-4337 verlangt, dass handleOps die Ausführung mindestens dieser User Operation überspringen muss, wenn ein validateUserOp-Aufruf fehlschlägt, und verlangt von Bundlern, ungültige Operationen aus ihrem Mempool abzulehnen, statt sie auf die Kette zu bringen. Ein Paymaster, der den Aufruf nicht sponsern will, dessen Einlage zu klein ist oder der seine eigene Validierung nicht besteht, schickt die Operation in diesen Zweig. Nichts wurde aufgenommen, nichts wurde abgerechnet, und es gibt keinen Hash zum Nachschlagen, weil der Fehlschlag geschah, bevor die Kette die Operation gesehen hat.
Die zweite geschieht nach der Aufnahme, und sie ist es, die das Häkchen erzeugt. Sobald die Validierung bestanden ist, hält die Spezifikation fest, dass die Ausführung stattfinden wird und nur einmal stattfindet, und garantiert außerdem die Gebührenzahlung. Der EntryPoint gibt danach für jede User Operation ein Ereignis mit einem Erfolgs-Flag aus, dokumentiert als true, wenn die Transaktion des Senders erfolgreich war, und false, wenn sie zurückgesetzt wurde, neben dem tatsächlich vom Konto oder vom Paymaster gezahlten Betrag. Die Bündel-Transaktion ist erfolgreich, dem Paymaster wird abgerechnet, und das Flag deiner Operation ist false. Alle drei Aussagen gelten gleichzeitig.
| Wo es fehlschlug | Hat einen Block erreicht | Wer gezahlt hat | Was es nachzuschlagen gibt |
|---|---|---|---|
| Validierung, vor der Aufnahme | Nein | Niemand | Ein Fehler vom Bundler oder von der Wallet und kein Eintrag auf der Kette |
| Ausführung, nach der Aufnahme | Ja | Das Konto oder der Paymaster | Eine erfolgreiche Transaktion, deren User-Operation-Ereignis ein Erfolgs-Flag mit false trägt |
Wohin man statt auf das Statusfeld schaut
Token-Bewegungen werden als Ereignisse in den Protokollen festgehalten. Die Token-Transfer-Ansicht eines Explorers ist eine Darstellung dieser Ereignisse: Taucht deine Adresse in keinem davon auf, hat sich dieser Token nicht bewegt, was der Status auch sagt. Geprüft werden die Protokolle; der Status ist die Zusammenfassung.
Drei Fragen erledigen die Arbeit. Gibt es überhaupt ein Transfer-Ereignis mit deiner Adresse, oder ist dieser Abschnitt der Seite leer? Wenn es eines gibt, ist sein Betrag der Betrag, der gesendet wurde? Und ist der Vertrag, der es ausgibt, der Token-Vertrag, den du gemeint hast, im Netzwerk, das du gemeint hast?
Eine vierte Möglichkeit überlebt alle drei Prüfungen: Der Transfer ist genau wie angewiesen geschehen, und es wird an der falschen Stelle gesucht. Eine zweite Adresse aus derselben Wiederherstellungsphrase, dieselbe Adresse in einem anderen Netzwerk und ein Token, den eine Wallet erst anzeigt, wenn sein Vertrag von Hand hinzugefügt wird, erzeugen jeweils einen leeren Bildschirm neben einem völlig einwandfreien Beleg.
Fazit
Ein Belegstatus ist eine Aussage über den äußersten Aufruf und über nichts sonst. Erfolg heißt, dass die Transaktion nicht zurückgesetzt wurde. Er hat nie geheißen, dass sich ein Token bewegt hat, dass sich der richtige Betrag bewegt hat oder dass der Vertrag damit getan hat, was gewollt war. Diese Tatsachen wohnen in den Ereignisprotokollen und unter ERC-4337 in einem Erfolgs-Flag, das getrennt vom Status der tragenden Transaktion geführt wird.
Wenn ein Transfer hinter einem grünen Häkchen verschwindet, arbeite die Schichten der Reihe nach ab: erst ein Transfer-Ereignis, dann sein Betrag, dann der Token-Vertrag und das Netzwerk. 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
- Globale Liquidität, M2 und Bitcoin: ein Leitfaden zur Messung
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 Improvement Proposals, EIP-20: Token Standard (die Funktion transfer und ihr boolescher Rückgabewert) eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-658: Embedding transaction status code in receipts (das Statusfeld im Transaktionsbeleg) eips.ethereum.org
[3] Ethereum Improvement Proposals, ERC-4337: Account Abstraction Using Alt Mempool (Validierung, Bundler und Paymaster) eips.ethereum.org
[4] eth-infinitism, account-abstraction, contracts/interfaces/IEntryPoint.sol, Tag v0.7.0 (die Deklaration von UserOperationEvent) raw.githubusercontent.com
[5] OpenZeppelin, openzeppelin-contracts, contracts/token/ERC20/utils/SafeERC20.sol, Tag v5.1.0 (der Dokumentationskommentar der Bibliothek) raw.githubusercontent.com
