---
title: "Warum müssen manche Token-Genehmigungen zuerst auf null gesetzt werden?"
description: "Manche ERC-20-Token lehnen den direkten Wechsel von einem Allowance-Wert ungleich null zu einem anderen ab. Erfahren Sie, wann Zero-first nötig ist, warum zwei Transaktionen nacheinander bestätigt werden müssen und welche Risiken bleiben."
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.
# Warum müssen manche Token-Genehmigungen zuerst auf null gesetzt werden?
> Nur zu Bildungszwecken; keine Anlageberatung. Anlagen können zu Verlusten führen.
## Direkte Antwort
Manche ERC-20-Implementierungen lehnen `approve(spender, newAmount)` ab, wenn sowohl die bestehende Allowance als auch `newAmount` ungleich null sind. Bei solchen Token reichen Sie zuerst `approve(spender, 0)` ein, warten auf die Bestätigung und reichen erst danach die neue Genehmigung ungleich null ein.
Diese Einschränkung ist nicht für jeden ERC-20-Token vorgeschrieben. ERC-20 definiert `approve` als Ersatz der aktuellen Allowance und empfiehlt Benutzeroberflächen, diese zuerst auf null zu setzen, um ein Wettrennen bei Genehmigungsänderungen abzumildern. Zugleich sollen Token-Verträge dies aus Kompatibilitätsgründen nicht erzwingen. Einige bereitgestellte Token tun es dennoch. Zero-first ist deshalb sowohl ein Kompatibilitätsverfahren als auch ein nützlicher Kontrollpunkt, aber keine Garantie, dass die alte Allowance vor Bestätigung der Nullsetzung nicht ausgegeben wird.
## Funktionsweise
1. Prüfen Sie Chain, Token-Vertrag, Eigentümer, Spender und beabsichtigten Betrag. Lesen Sie `allowance(owner, spender)` direkt aus dem Token-Vertrag, statt sich nur auf eine Wallet-Bezeichnung zu verlassen.
2. Ist die Allowance bereits `0`, reichen Sie die gewünschte Genehmigung einmal ein. Ist sie ungleich null, kann ein direkter Ersatz durch einen Wert ungleich null bei einer Standardimplementierung gelingen oder bei einem Zero-first-Token zurückgesetzt werden.
3. Reichen Sie für den Zero-first-Ablauf `approve(spender, 0)` ein und warten Sie auf einen erfolgreichen Beleg. Lesen Sie anschließend dieselbe Eigentümer-Spender-Allowance erneut und bestätigen Sie den Wert `0`.
4. Prüfen Sie Token-Saldo, Spender und Zweck erneut. Reichen Sie erst dann `approve(spender, newAmount)` ein und betrachten Sie die neue Allowance erst nach Bestätigung als aktiv.
5. Prüfen Sie die endgültige Allowance sowie zwischenzeitliche `Transfer`- und `Approval`-Ereignisse. Ein erfolgreicher Transaktionsbeleg weist die Ausführung nach; der aktuelle Vertragszustand zeigt die verbleibende Berechtigung.
OpenZeppelins `SafeERC20.forceApprove` bietet Verträgen einen Kompatibilitäts-Fallback: Die Funktion versucht den gewünschten Wert und bei einem Fehlschlag nacheinander `0` und den gewünschten Wert. Der Helfer ändert die eigene Allowance des aufrufenden Vertrags. Er korrigiert nicht automatisch die Genehmigung einer Benutzer-Wallet und ersetzt weder die Prüfung der Transaktionsreihenfolge noch die des Endzustands.
## Beispiel
Ein Eigentümer hat einem Spender eine Allowance von `1000` Token erteilt und möchte sie auf `100` senken. Bei einem Zero-first-Token wird `approve(spender, 100)` zurückgesetzt, sodass die Onchain-Allowance `1000` bleibt. Ein zurückgesetzter Aufruf aktualisiert den Zustand nicht teilweise.
Stattdessen reicht der Eigentümer `approve(spender, 0)` ein. Vor dessen Bestätigung gibt der Spender `400` aus, sodass `600` verbleiben. Die danach bestätigte Nullsetzung ersetzt den Rest durch `0`. Nach Prüfung des gesunkenen Token-Saldos kann der Eigentümer entscheiden, ob er die neuen `100` genehmigt. Falls ja, hat der Spender bereits `400` verwendet und kann später bis zu `100` zusätzlich einsetzen. Zero-first macht die zwischenzeitliche Ausgabe vor der neuen Genehmigung sichtbar, macht sie aber nicht rückgängig.
## Risiken
- Die alte Allowance kann genutzt werden, bis die Nullsetzung ausgeführt wird. Ein Spender kann einer ausstehenden Aufhebung oder Senkung zuvorkommen.
- Werden Nullsetzung und Ersatz ohne Bestätigung der ersten Transaktion gesendet, entfällt der vorgesehene Kontrollpunkt und eine zwischenzeitliche Ausgabe kann verborgen bleiben.
- Eine falsche Chain, Token-Adresse oder Spender-Adresse kann eine andere als die beabsichtigte Berechtigung erstellen oder aufheben. Token-Symbole sind keine eindeutigen Kennungen.
- Der zweistufige Ablauf kostet zwei Transaktionen, wenn beide nötig sind; jede kann fehlschlagen, ersetzt werden oder ausstehend bleiben. Leiten Sie den Zustand nicht allein aus einer eingereichten Signatur ab.
- Unbegrenzte Genehmigungen sowie aktualisierbare oder kompromittierte Spender können künftige Einzahlungen gefährden. Verwenden Sie den kleinsten praktikablen Betrag und prüfen Sie die restliche Allowance nach der Nutzung.
- Vertragsintegrationen müssen nicht standardisierte Rückgabewerte und Genehmigungsverhalten bewusst behandeln. Ein Kompatibilitäts-Wrapper macht einen nicht vertrauenswürdigen Spender nicht sicher.
## Häufige Irrtümer
- **Jeder ERC-20 verlangt Zero-first.** Der Standard empfiehlt die clientseitige Reihenfolge, sagt aber, dass Token-Verträge sie nicht erzwingen sollten. Nur einige Implementierungen lehnen Änderungen von ungleich null zu ungleich null ab.
- **Zero-first beseitigt das Genehmigungswettrennen vollständig.** Der Spender kann die alte Allowance weiterhin nutzen, bevor die Nullsetzung bestätigt ist.
- **Ein zurückgesetzter Ersatz hat die alte Allowance gelöscht.** Ein Revert macht den versuchten Zustandswechsel rückgängig, sodass die vorherige Allowance normalerweise bestehen bleibt.
- **Zwei gemeinsam gesendete Transaktionen entsprechen dem Warten.** Der Sicherheitskontrollpunkt entsteht durch Bestätigung und Prüfung des Nullzustands vor der Entscheidung über den Ersatz.
- **Das Trennen einer Website widerruft ihre Genehmigung.** Wallet-Verbindungsstatus und Onchain-Allowance im Token-Vertrag sind getrennt.
## Verwandte Themen
- [ERC-20-Genehmigungswettrennen](/de/crypto/erc20-approval-race-condition/)
- [Wallet-Genehmigung](/de/crypto/wallet-approval/)
- [Nonce und Deadline einer ERC-2612-Permit](/de/crypto/erc2612-permit-nonce-deadline/)
- [Risiken einer Permit2-Signatur](/de/crypto/permit2-signature-risk/)
## Quellen
- [ERC-20: Token-Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (abgerufen: 2026-08-21)
- [ERC20 | OpenZeppelin-Dokumentation](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20) - OpenZeppelin (abgerufen: 2026-08-21)
- [SafeERC20.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol) - OpenZeppelin (abgerufen: 2026-08-21)
Source: https://wiki.fcontext.com/de/crypto/token-approval-zero-first/index.mdx