Race Condition bei ERC-20-Genehmigungen

Ein ERC-20-Spender kann eine alte Allowance nutzen, bevor eine ersetzende Genehmigung bestätigt wird, und anschließend die neue Allowance verwenden. Erfahren Sie, wie diese Race Condition funktioniert und wie sich Genehmigungen sicherer ändern oder widerrufen lassen.

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Die Race Condition bei ERC-20-Genehmigungen kann auftreten, wenn ein Eigentümer eine Allowance ungleich null durch eine andere ersetzt, indem er approve(spender, newAmount) aufruft. Ein Spender kann die ausstehende Änderung sehen, zunächst die alte Allowance mit transferFrom ausgeben und nach deren Bestätigung auch die neue Allowance nutzen.

Die ERC-20-Spezifikation empfiehlt deshalb, dass Client-Oberflächen die Allowance zunächst auf 0 setzen, bevor sie für denselben Spender einen neuen Wert festlegen. Jede Transaktion muss der Reihe nach bestätigt werden. Sofern ein Token sie unterstützt, vermeiden atomare Aufrufe von increaseAllowance oder decreaseAllowance, dass eine Allowance ungleich null direkt ersetzt wird.

Ketten-ID und Prüfvertrag stimmen mit der beabsichtigten Anwendung übereinFunktion, Spender, Token, Betrag, Nonce und Frist sind dekodiertVorhandene Zulagen- und Ersetzungssemantiken wurden überprüftBalance- und Genehmigungsänderungen wurden simuliertUnerwartete Contract Calls, Delegationen oder Wertübertragungen führen zur Ablehnung

0 / 5

0 Artikel überprüft; 5 noch ungelöste Punkte

Der Abschluss dieser Überprüfung beweist nicht, dass ein Vermögenswert, eine Transaktion oder ein System sicher ist.

Wie es funktioniert

ERC-20 definiert approve als Überschreiben: Ein erfolgreicher Aufruf von approve(spender, amount) setzt die Allowance des Spenders auf amount. Unabhängig davon kann dieser Spender mit transferFrom(owner, recipient, amount) Token des Eigentümers übertragen, wobei sich die verbleibende Allowance normalerweise verringert. Ausstehende Transaktionen reservieren keine Ausführungsreihenfolge. Daher kann ein Spender eine Übertragung einreichen, die vor der Genehmigungsänderung des Eigentümers ausgeführt wird.

Der riskante Übergang ist N -> M, wobei sowohl N > 0 als auch M > 0 gilt. Verbraucht der Spender N, bevor die ersetzende Genehmigung ausgeführt wird, richtet die spätere Genehmigung eine neue Allowance von M ein. Über diese Abfolge können daher höchstens N + M ausgegeben werden, abhängig vom Token-Guthaben des Eigentümers und von der Implementierung des Tokens.

Beispiel

Alice hat einem Protokoll erlaubt, 100 Token auszugeben. Sie reicht approve(protocol, 50) ein, um die verbleibende Allowance auf 50 zu senken. Bevor diese Transaktion bestätigt wird, reicht der Spender des Protokolls transferFrom(Alice, recipient, 100) ein und lässt den Aufruf zuerst ausführen. Alices Genehmigung setzt die Allowance anschließend auf 50, die der Spender für eine weitere Übertragung nutzen kann. Zusammen belaufen sich die beiden Übertragungen auf 150 Token.

Ein sichererer Ablauf für den Ersatz ist: approve(protocol, 0) einreichen, die Bestätigung abwarten, anschließend die resultierende Allowance und das Guthaben prüfen und erst dann approve(protocol, 50) einreichen, falls die neue Genehmigung weiterhin angemessen ist. Verwendet der Spender die alte Allowance, bevor die Nullsetzung bestätigt wird, kann Alice das veränderte Guthaben erkennen und abbrechen, bevor sie die neuen 50 gewährt.

Risiken

Das Setzen der Allowance auf 0 macht bereits ausgeführte Ausgaben nicht rückgängig und verhindert nicht, dass die alte Allowance vor Bestätigung der Nullsetzung genutzt wird.
Werden die Nullsetzung und die ersetzende Genehmigung zusammen versendet, ohne die erste Bestätigung abzuwarten, entsteht erneut ein Risiko durch die Ausführungsreihenfolge.
increaseAllowance und decreaseAllowance gehören nicht zum grundlegenden ERC-20-Standard. Verwenden Sie sie nur, wenn der verifizierte Token-Vertrag sie unterstützt.
Eine unbegrenzte Allowance kann das gesamte Token-Guthaben des Eigentümers gefährden, solange sie aktiv ist. Prüfen Sie vor dem Signieren die Chain, den Token-Vertrag, den Spender und den Betrag.
Manche Token verhalten sich bei Genehmigungen nicht standardkonform. Lesen Sie die Wallet-Simulation und die Transaktions-Calldata und bestätigen Sie nach jedem Schritt die On-Chain-Allowance.

Häufige Irrtümer

„Die neueste Genehmigungstransaktion ersetzt die alte sofort.“ Sie ändert den Zustand erst, wenn sie on-chain ausgeführt wird.
„Das Senken einer Allowance begrenzt alle künftigen Ausgaben auf den neuen Betrag.“ Ein Spender kann die alte Allowance verwenden, bevor die Änderung ausgeführt wird.
„Die Nullsetzung zuerst garantiert, dass keine weiteren Token abfließen.“ Die alte Allowance bleibt nutzbar, bis die Nullsetzung bestätigt ist.
„Jeder ERC-20 besitzt increaseAllowance und decreaseAllowance.“ Dies sind optionale Erweiterungen und keine ERC-20-Anforderungen.
„Das Trennen der Website-Verbindung widerruft die Token-Genehmigung.“ Der Verbindungsstatus der Wallet und die On-Chain-Allowance im Token-Vertrag sind voneinander getrennt.

Quellen

ERC-20: Token Standard - Ethereum Improvement Proposals (abgerufen: 2026-08-20)
ERC20 | OpenZeppelin Docs - OpenZeppelin (abgerufen: 2026-08-20)