---
title: "Condition de concurrence des autorisations ERC-20"
description: "Un dépensier ERC-20 peut utiliser une ancienne allowance avant la confirmation de l'autorisation qui la remplace, puis utiliser la nouvelle. Découvrez le fonctionnement de cette condition de concurrence et comment modifier ou révoquer des autorisations de façon plus sûre."
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.
# Condition de concurrence des autorisations ERC-20
> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
## Réponse directe
La condition de concurrence des autorisations ERC-20 peut se produire lorsqu'un propriétaire remplace une allowance non nulle par une autre en appelant `approve(spender, newAmount)`. Un dépensier peut repérer le changement en attente, dépenser d'abord l'ancienne allowance avec `transferFrom`, puis utiliser la nouvelle allowance après sa confirmation.
La spécification ERC-20 recommande donc aux interfaces client de ramener d'abord l'allowance à `0` avant de définir une nouvelle valeur pour le même dépensier. Chaque transaction doit être confirmée dans l'ordre. Lorsqu'un token les prend en charge, les appels atomiques `increaseAllowance` ou `decreaseAllowance` évitent de remplacer directement une allowance non nulle.
## Fonctionnement
ERC-20 définit `approve` comme un écrasement : un appel réussi à `approve(spender, amount)` fixe l'allowance du dépensier à `amount`. Par ailleurs, `transferFrom(owner, recipient, amount)` permet à ce dépensier de transférer les tokens du propriétaire et réduit normalement l'allowance restante. Les transactions en attente ne réservent aucun ordre d'exécution ; un dépensier peut donc soumettre un transfert qui s'exécute avant la modification de l'autorisation par le propriétaire.
La transition risquée est `N -> M`, avec à la fois `N > 0` et `M > 0`. Si le dépensier consomme `N` avant l'exécution de l'autorisation de remplacement, l'autorisation ultérieure crée une nouvelle allowance de `M`. Le maximum dépensé au cours de cette séquence peut donc atteindre `N + M`, sous réserve du solde de tokens du propriétaire et de l'implémentation du token.
## Exemple
Alice a autorisé un protocole à dépenser `100` tokens. Elle soumet `approve(protocol, 50)` pour ramener l'allowance restante à `50`. Avant la confirmation de cette transaction, le dépensier du protocole soumet `transferFrom(Alice, recipient, 100)` et le fait exécuter en premier. L'autorisation d'Alice fixe ensuite l'allowance à `50`, que le dépensier peut utiliser dans un autre transfert. Les deux transferts totalisent `150` tokens.
Une procédure de remplacement plus sûre consiste à soumettre `approve(protocol, 0)`, à attendre la confirmation, à vérifier l'allowance et le solde obtenus, puis seulement à soumettre `approve(protocol, 50)` si la nouvelle autorisation reste appropriée. Si le dépensier utilise l'ancienne allowance avant la confirmation de la mise à zéro, Alice peut constater le changement de solde et s'arrêter avant d'accorder les nouveaux `50`.
## Risques
- Ramener l'allowance à `0` n'annule pas une dépense déjà exécutée et n'empêche pas l'utilisation de l'ancienne allowance avant la confirmation de la mise à zéro.
- Envoyer ensemble la mise à zéro et l'autorisation de remplacement, sans attendre la première confirmation, réintroduit un risque lié à l'ordre d'exécution.
- `increaseAllowance` et `decreaseAllowance` ne font pas partie de la norme ERC-20 de base ; utilisez-les uniquement lorsque le contrat vérifié du token les prend en charge.
- Une allowance illimitée peut exposer l'intégralité du solde de tokens du propriétaire tant qu'elle reste active. Vérifiez le réseau, le contrat du token, le dépensier et le montant avant de signer.
- Certains tokens ont un comportement d'autorisation non standard. Lisez la simulation du portefeuille et les calldata de la transaction, puis vérifiez l'allowance on-chain après chaque étape.
## Idées reçues courantes
- « La dernière transaction d'autorisation remplace immédiatement l'ancienne. » Elle ne modifie l'état que lors de son exécution on-chain.
- « Réduire une allowance plafonne toutes les dépenses futures au nouveau montant. » Un dépensier peut utiliser l'ancienne allowance avant l'exécution du changement.
- « La mise à zéro en premier garantit qu'aucun autre token ne peut sortir. » L'ancienne allowance reste utilisable jusqu'à la confirmation de la mise à zéro.
- « Tous les ERC-20 possèdent `increaseAllowance` et `decreaseAllowance`. » Ce sont des extensions facultatives, et non des exigences d'ERC-20.
- « Révoquer la connexion au site révoque l'autorisation du token. » L'état de connexion du portefeuille et l'allowance on-chain du contrat du token sont distincts.
## Sujets connexes
- [Distinguer les tokens canoniques des tokens enveloppés](/fr/crypto/canonical-vs-wrapped-token/)
- [Mempool](/fr/crypto/mempool/)
- [Risque lié aux signatures Permit2](/fr/crypto/permit2-signature-risk/)
- [Ordres de réduction uniquement](/fr/crypto/reduce-only-order/)
- [Autorisation du portefeuille](/fr/crypto/wallet-approval/)
## Sources
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consulté le : 2026-08-20)
- [ERC20 | OpenZeppelin Docs](https://docs.openzeppelin.com/contracts/4.x/api/token/erc20) - OpenZeppelin (consulté le : 2026-08-20)
Source: https://wiki.fcontext.com/fr/crypto/erc20-approval-race-condition/index.mdx