---
title: "Race Condition bei ERC-20-Genehmigungen"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Race Condition bei ERC-20-Genehmigungen
> 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.
## 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.
## Verwandte Themen
- [Kanonische und Wrapped Token unterscheiden](/de/crypto/canonical-vs-wrapped-token/)
- [Mempool](/de/crypto/mempool/)
- [Risiken von Permit2-Signaturen](/de/crypto/permit2-signature-risk/)
- [Reduce-only-Orders](/de/crypto/reduce-only-order/)
- [Wallet-Genehmigung](/de/crypto/wallet-approval/)
## Quellen
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (abgerufen: 2026-08-20)
- [ERC20 | OpenZeppelin Docs](https://docs.openzeppelin.com/contracts/4.x/api/token/erc20) - OpenZeppelin (abgerufen: 2026-08-20)
Source: https://wiki.fcontext.com/de/crypto/erc20-approval-race-condition/index.mdx