Autorisations et allowances de jetons : vérifier et révoquer ERC-20

La connexion à un site permet généralement à l’application de voir une adresse publique et de demander des signatures. Elle ne l’autorise pas, à elle seule, à déplacer tous les jetons ERC-20. L’allowance est enregistrée séparément dans le contrat du jeton. MetaMask distingue aussi la déconnexion d’une dapp du retrait des autorisations de jetons.

Une allowance ERC-20 dépend du contrat du jeton, de la chaîne, de l’adresse du propriétaire et de celle du spender. Une autorisation sur Ethereum n’est pas la même que pour le même symbole sur Polygon ou pour un autre jeton. Se souvenir seulement « d’avoir autorisé ce site » peut faire oublier quel jeton et quel réseau restent concernés.

Ce guide porte sur approve, allowance et transferFrom d’ERC-20 sur Ethereum et les réseaux compatibles. Les transferts d’ETH natif, setApprovalForAll des NFT, les autres standards et la connexion de portefeuille suivent d’autres modèles. Pour les clés, consultez le guide de sauvegarde de phrase de récupération et de restauration du portefeuille.

Avec approve(spender, amount), le propriétaire peut autoriser un spender précis à utiliser jusqu’à une certaine quantité. transferFrom permet à ce spender de déplacer des jetons pour son compte. L’appel approve ne change donc généralement pas le solde sur le moment, mais un appel ultérieur du contrat peut consommer l’allowance. C’est le fonctionnement décrit par le standard ERC-20.

Par exemple, si un portefeuille détient 300 jetons et accorde 80 d’allowance à un routeur, un ERC-20 classique limite le montant utilisable au plus petit entre l’allowance restante et le solde. Le droit peut couvrir plusieurs actions : un contrat peut appeler transferFrom plusieurs fois. Si le contrat autorisé ou le parcours prévu est détourné, les jetons peuvent bouger d’une manière inattendue. Les comportements non standards du jeton comptent aussi.

L’autorisation est généralement une transaction on-chain adressée au contrat du jeton et peut entraîner des frais réseau. Certaines applications séparent autorisation et échange; d’autres combinent une signature d’autorisation avec une transaction ultérieure. Vérifiez ce que le portefeuille vous demande réellement de signer et sur quel réseau, pas seulement le bouton « Approve ».

L’étiquette « Unlimited » représente souvent une valeur proche de l’entier maximal du jeton. Elle ne crée pas des jetons infinis et ne transfère pas le solde au moment de l’autorisation. Le spender peut toutefois utiliser le droit restant plus tard sur les jetons de même type qui arriveraient dans ce portefeuille sur cette chaîne. Certaines implémentations ne diminuent pas une valeur maximale; vérifiez donc le comportement du jeton.

Une application peut demander une limite large pour éviter des autorisations répétées, mais commodité et exposition vont ensemble. Une vulnérabilité ou un abus du contrôle du contrat spender peut rendre une ancienne autorisation utilisable plus tard. Le guide de révocation d’Ethereum.org explique pourquoi une allowance large peut rester importante après le retour des actifs dans le portefeuille.

Une limite plus petite ne supprime pas tous les risques. Un faux jeton ou un mauvais spender peut causer une perte même avec une limite faible; autoriser à chaque opération ajoute aussi des frais et des occasions d’erreur. Tenez compte du montant prévu, de la fréquence d’utilisation, de la confiance envers le spender et de votre capacité à vérifier à nouveau l’autorisation.

Avant la signature, vérifiez quatre éléments : le réseau sélectionné correspond-il à celui indiqué par l’application; l’adresse du contrat du jeton est-elle correcte, et pas seulement son symbole; l’adresse du spender correspond-elle aux documents officiels ou à des données de contrat vérifiables; la limite correspond-elle à l’action prévue ou laisse-t-elle un droit large dans la durée?

Ne connectez pas le portefeuille depuis un lien reçu en message privé, code QR, chat d’assistance ou publicité non vérifiée. Un site de phishing peut imiter une vraie application. Utilisez une adresse officielle enregistrée ou la documentation du projet. Un nom de contrat familier ne prouve pas que l’adresse est sûre; un badge de vérification dans un explorateur ne garantit pas la sécurité du contrat.

Un signataire matériel peut isoler la clé privée du navigateur ordinaire, mais ne décide pas si le spender ou le montant est sûr. Si l’appareil n’affiche pas la demande de manière compréhensible, arrêtez et consultez les explications officielles du fournisseur du portefeuille. Moins de détails visibles signifie moins de possibilités de vérification.

Certains ERC-20 prennent en charge ERC-2612 permit. Au lieu d’envoyer une transaction approve classique, le propriétaire signe des données typées; une autre partie peut soumettre cette signature pour définir l’allowance. Le message standard contient propriétaire, spender, montant, nonce et deadline, avec un domaine qui rattache la signature à une chaîne et un contrat.

La deadline d’ERC-2612 est la dernière date à laquelle le permit signé peut être soumis. Elle ne fait pas expirer automatiquement une allowance déjà définie avec succès. Le droit peut rester jusqu’à son utilisation, sa modification ou sa révocation. Certains jetons utilisent d’autres variantes de permit ou des règles d’expiration supplémentaires; toutes les demandes nommées « permit » ne suivent pas ERC-2612.

Une signature peut permettre à un autre compte de payer les frais, mais ce n’est pas pour autant une simple confirmation de connexion. Si le portefeuille n’affiche pas clairement le jeton, le spender, le montant et les conditions de temps, ou si ces détails contredisent l’explication de l’application, refusez et consultez les documents officiels. Une signature non encore soumise peut l’être par quelqu’un d’autre avant sa deadline.

Se déconnecter ou couper la liaison change la session du navigateur ou le droit de connexion. Une allowance ERC-20 déjà inscrite dans le contrat du jeton peut rester active. Inversement, sa révocation n’efface ni l’adresse publique connue du site ni l’historique on-chain. Le guide de déconnexion de MetaMask explique cette différence.

La révocation consiste généralement à envoyer une transaction on-chain qui met à zéro l’allowance de ce jeton et de ce spender. Elle entraîne des frais réseau, et l’ancien droit peut rester actif jusqu’à confirmation. Ensuite, actualisez la liste ou relisez le contrat pour vérifier le zéro avec le même portefeuille, la même chaîne, le même jeton et le même spender. MetaMask et Ethereum.org décrivent des vérificateurs propres à chaque réseau; vérifiez le domaine officiel et le réseau choisi.

Chaque chaîne conserve son propre état. Mettre à zéro une allowance sur Ethereum ne modifie pas automatiquement l’autorisation sur une autre chaîne. Vérifiez chaque compte, contrat de jeton, spender et réseau pertinent, puis contrôlez le résultat après confirmation. Un outil de révocation ne doit jamais demander votre phrase de récupération ni votre clé privée.

Après confirmation d’une allowance à zéro, ce droit ne peut plus soutenir un nouvel appel transferFrom. La révocation n’annule pas les transferts terminés, ne récupère pas les jetons chez le destinataire et ne supprime pas les autorisations d’autres contrats. Si un spender suspect a déjà déplacé des jetons, la révocation ne garantit pas leur récupération.

Si la clé privée du portefeuille est exposée, un attaquant peut encore signer autrement. Des autorisations accordées à d’autres spenders ou jetons, des droits d’opérateur NFT, des signatures permit et des permissions propres à certains contrats peuvent également subsister. Interprétez le résultat dans les limites exactes du portefeuille et du réseau vérifiés.

Après révocation, un nouvel échange, dépôt ou retrait peut nécessiter une nouvelle autorisation. Avant d’agir, vérifiez si une transaction en attente ou une position active dépend du spender et, si besoin, consultez l’aide officielle du protocole. Il faut savoir ce qui changera dans le flux suivant.

Le standard ERC-20 recommande aux interfaces de mettre d’abord à zéro une allowance non nulle avant de la remplacer par une autre valeur non nulle. Si une transaction du spender s’intercale entre l’ancienne et la nouvelle autorisation, il peut utiliser plus que prévu. Par exemple, lors du passage de 100 à 25, il pourrait utiliser les anciens 100 avant que les nouveaux 25 soient enregistrés, puis utiliser aussi ces derniers.

Confirmer d’abord le zéro réduit le risque que les anciennes et nouvelles valeurs se chevauchent, mais n’annule pas l’usage de l’ancienne allowance avant confirmation de la transaction zéro. Les deux étapes peuvent coûter des frais et les jetons peuvent se comporter différemment. Suivez la procédure sûre documentée par le portefeuille ou le jeton et attendez la confirmation.

Si vous ignorez le montant actuel, interrogez le contrat du jeton sur le réseau sélectionné avant de le remplacer. Si le portefeuille affiche une valeur vide ou inattendue, assurez-vous de ne pas consulter une autre chaîne ou adresse. L’adresse du propriétaire et celle du contrat du jeton doivent correspondre.

1. Confirmez le domaine officiel du projet et le réseau sélectionné.
2. Vérifiez les adresses du contrat du jeton et du spender, puis comparez la limite au montant prévu.
3. Lisez la vraie transaction ou les données typées affichées par le portefeuille. Ne signez pas une demande incompréhensible.
4. Sur le réseau concerné, contrôlez les spenders inutilisés ou auxquels vous ne faites plus confiance; mettez l’allowance à zéro si nécessaire et vérifiez le résultat.
5. Pour comparer des portefeuilles, examinez aussi la lisibilité des autorisations et la clarté des consignes de mise à jour et de récupération.

Un portefeuille matériel est une option de conservation de clé et de vérification de signature, pas une garantie de sécurité du contrat ni un rempart contre une limite trop large que vous approuvez. Vérifiez vous-même spender, jeton, réseau et montant. Comprendre que l’allowance persiste indépendamment de la connexion au site aide aussi à comparer les fonctions de sécurité et leurs limites réelles.