Une approbation de token est une permission on-chain stockée dans un contrat de token ERC-20 — une allowance — qui enregistre qu'un contrat précis peut dépenser jusqu'à un montant précis de vos tokens, à n'importe quel moment ultérieur, sans vous redemander. Elle est créée par une transaction approve() et survit à l'interaction pour laquelle vous l'avez accordée : le site web peut disparaître, l'allowance demeure. Permit (EIP-2612) remplace cette transaction distincte par une signature off-chain que la dApp soumet avec sa propre action, et Permit2 étend ce même modèle — plafonné en montant et borné dans le temps — aux tokens qui n'ont jamais implémenté EIP-2612, ce qui signifie qu'une signature peut désormais céder un pouvoir de dépense : les demandes de signature méritent donc l'attention que l'on réservait aux approbations. La défense est sans éclat : approuvez des montants bornés plutôt qu'illimités, et révoquez les allowances dont vous ne vous servez plus. Dans un portefeuille entièrement non-custodial comme WATS — où l'utilisateur détient les clés et où WATS n'en détient jamais aucune — aucune approbation, signature Permit ni révocation ne peut avoir lieu sans que votre propre clé la signe, et parce que les frais de réseau sont facturés dans un seul token, l'ATS, une transaction de nettoyage n'est jamais reportée faute du token de gas natif de la chaîne concernée.
Pourquoi les dApps demandent une approbation
Les tokens ERC-20 ont une particularité qui façonne la moitié de l'UX du Web3 : un smart contract ne peut pas simplement prendre des tokens sur votre adresse, même quand vous le souhaitez. Un DEX qui échange vos USDC a d'abord besoin de votre permission explicite. C'est pourquoi tant d'interactions se font en deux étapes — d'abord une transaction approve, puis l'échange ou le dépôt réel. L'approbation n'est pas une formalité ; c'est une délégation permanente de pouvoir de dépense, qui survit à la transaction pour laquelle vous l'avez donnée.
Ce qu'approve() accorde réellement
Quand vous signez une approbation, le contrat du token enregistre une allowance : l'adresse X (le contrat de la dApp) peut dépenser jusqu'à N de vos tokens, quand elle le veut, jusqu'à ce que l'allowance soit épuisée, réduite ou révoquée. Deux propriétés comptent. Premièrement, l'allowance réside dans le contrat du token et est accordée au contrat que vous avez approuvé, pas au site web visité — l'interface peut disparaître, la permission demeure. Deuxièmement, rien dans une allowance ne requiert votre intervention au moment de la dépense : une fois accordée, le contrat approuvé peut prélever des tokens dans n'importe quelle transaction ultérieure sans nouvelle signature de votre part. C'est exactement ce qui rend les approbations utiles — et exactement ce qui en fait une surface d'attaque.
Approbations infinies : pratiques, et un risque permanent
Chaque approbation coûtant du gas, beaucoup de dApps demandent une allowance effectivement illimitée pour que vous n'ayez plus jamais à approuver. Le confort est réel, mais le marché aussi : une allowance illimitée à un contrat signifie que tout votre solde de ce token repose à jamais sur la sécurité de ce contrat. Si le contrat est exploité des années plus tard — ou était malveillant depuis le début — l'attaquant n'a besoin ni de votre clé ni de votre signature ; l'allowance que vous avez accordée suffit. Beaucoup des plus grands incidents de vidage de portefeuilles n'étaient pas des vols de clés, mais de vieilles approbations encaissées.
Permit et Permit2 : des approbations par signature
Le raffinement moderne est Permit (EIP-2612) : au lieu d'une transaction approve on-chain, vous signez un message off-chain que la dApp soumet avec son action — une transaction au lieu de deux, pas de gas d'approbation séparé, et la permission peut être bornée par une échéance. Permit2 généralise l'idée aux tokens qui n'ont jamais implémenté EIP-2612, en jouant le rôle de hub d'approbation partagé : vous faites une seule approbation on-chain ordinaire au contrat Permit2 lui-même, et dès lors chaque dApp est autorisée par une signature portant son propre montant et sa propre échéance. Il faut être précis sur ce compromis : Permit2 n'abolit pas les approbations, il les concentre — l'allowance permanente que vous avez accordée à Permit2 est elle-même une approbation à surveiller. Ce sont de véritables améliorations, mais notez ce qu'elles changent : les signatures font désormais le travail que faisaient les transactions. Un site de phishing qui vous fait signer le mauvais message Permit obtient le même résultat qu'une approbation malveillante — lire ce que vous signez compte donc plus que jamais, pas moins.
La surface d'attaque : drainers et allowances périmées
L'abus d'approbation existe en deux saveurs. Actif : les sites drainer imitent de vraies dApps et demandent des approbations (ou signatures Permit) déguisées en actions anodines comme « réclamer » ou « vérifier le portefeuille ». Passif : des allowances accordées il y a des années à des contrats légitimes dorment jusqu'à ce que le contrat, ses clés d'administration ou son chemin de mise à niveau soient compromis. Deux raisons de traiter le flux connexion-approbation comme le moment critique de la sécurité Web3 ; la façon sûre de procéder est détaillée dans comment connecter votre portefeuille à une dApp.
Une hygiène d'approbation qui fonctionne vraiment
Trois habitudes couvrent l'essentiel du risque. Approuvez des montants bornés quand la dApp le permet, surtout pour les gros soldes — l'approbation supplémentaire ultérieure est une assurance bon marché. Vérifiez et révoquez périodiquement vos allowances avec un vérificateur d'approbations réputé, en traitant tout ce que vous n'utilisez plus comme du poids mort à retirer — la révocation est elle-même une transaction on-chain qui remet l'allowance à zéro : elle coûte du gas et exige votre signature comme n'importe quelle autre. Et gardez les avoirs sérieux sur une adresse qui ne signe simplement jamais d'approbations, séparée de votre portefeuille dApp actif. Plus d'habitudes en couches dans nos bonnes pratiques de sécurité de portefeuille.
Où WATS entre en jeu
Les approbations sont des signatures, et les signatures sont le territoire du portefeuille. WATS est entièrement non-custodial — vous détenez vos clés, WATS n'en détient jamais aucune — donc chaque approbation, signature Permit et révocation n'a lieu que lorsque votre clé la signe, depuis l'extension Chrome, l'app mobile ou le Hot Wallet, sur Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana et TON. Cela fixe aussi la limite honnête de ce qu'un portefeuille peut faire pour vous : un portefeuille peut vous montrer la demande, mais vous seul pouvez décider que le dépensier et le montant sont bien ceux que vous vouliez.
Le volet frais supprime l'autre excuse courante pour laisser de vieilles allowances en place. Dans WATS, chaque action, y compris les transactions d'approbation et de révocation, est facturée dans un seul token, l'ATS, au lieu du token de gas natif de chaque chaîne — via un paymaster ERC-4337 sur EVM et un fee-payer/relayer équivalent sur Solana et TON. Ce n'est pas une remise : le réseau perçoit toujours ce qui lui est dû et le coût sous-jacent est inchangé — ce qui change, c'est le token qui paie. L'ATS collecté est brûlé, d'une offre de 100M vers un plancher de 30M, et comme l'ATS est un OFT LayerZero, un seul solde couvre toutes les chaînes prises en charge. WATS est le premier et le seul portefeuille à combiner les frais en token unique ERC-4337 et OFT avec ce burn — détails sur la page des frais ATS.
La version pratique de cet article tient donc en une courte routine : préférez les approbations bornées, lisez ce qu'une signature Permit autorise réellement avant de la signer, et une fois par trimestre ouvrez un vérificateur d'approbations pour éliminer les dépensiers dont vous ne vous servez plus. L'étape concrète consiste à exécuter cette routine depuis un portefeuille qui ne s'interpose jamais entre vous et la clé : dans le Hot Wallet WATS, l'extension Chrome ou l'app mobile, chaque approbation et chaque révocation n'existe que parce que votre propre clé l'a signée — WATS n'en détient jamais aucune — et la révocation est payée en ATS plutôt que dans le token de gas natif que cette chaîne-là réclame.
Foire aux questions
Qu'est-ce qu'une allowance de token ?
Une allowance est une permission permanente enregistrée dans un contrat de token ERC-20 : elle stipule qu'un contrat spécifique peut dépenser jusqu'à un montant donné de vos tokens. Elle naît quand vous signez une transaction approve et persiste — indépendamment du site web utilisé — jusqu'à être dépensée, modifiée ou révoquée. Au moment de la dépense, le contrat approuvé n'a besoin d'aucune signature supplémentaire de votre part.
Les approbations illimitées (infinies) sont-elles sûres ?
Elles sont pratiques mais portent un risque de queue permanent : tout votre solde de ce token dépend de ce que le contrat approuvé ne soit jamais exploité ni malveillant, indéfiniment. Pour de petits soldes actifs, le confort l'emporte souvent ; pour de gros avoirs, préférez des montants bornés et révoquez périodiquement les allowances inutilisées. Beaucoup de grands incidents de vidage étaient de vieilles approbations exploitées, pas des clés volées.
Quelle est la différence entre Permit et une approbation normale ?
Une approbation normale est une transaction on-chain à part entière qui coûte du gas avant que la dApp puisse agir. Permit (EIP-2612) la remplace par une signature off-chain que la dApp intègre à sa transaction — une seule étape, avec des échéances optionnelles ; Permit2 étend le motif aux tokens sans support natif de Permit, via une unique approbation on-chain au contrat Permit2 sur laquelle s'appuient ensuite les signatures propres à chaque dApp. Le modèle de sécurité se déplace en conséquence : une signature peut désormais accorder un pouvoir de dépense, alors examinez les demandes de signature exactement comme vous le feriez pour une approbation.
Comment révoquer une approbation de token ?
Révoquer, c'est remettre l'allowance à zéro, ce qui est en soi une transaction on-chain : vous ouvrez un vérificateur d'approbations réputé ou l'interface du token lui-même, sélectionnez le contrat dépensier et signez une transaction qui inscrit une allowance de 0 (les délégations Permit2 s'annulent via ses propres mécanismes de lockdown/expiration). Cela coûte du gas, exige votre signature et n'affecte que la chaîne sur laquelle vous le faites — une allowance sur Ethereum est distincte d'une allowance sur Arbitrum, Base ou Polygon : chaque chaîne doit être nettoyée séparément.
Quel portefeuille utiliser pour gérer les approbations de tokens ?
WATS est un choix pratique parce qu'il est entièrement non-custodial — l'utilisateur détient les clés et WATS n'en détient jamais aucune — donc chaque approve, signature Permit et révocation n'existe que parce que votre propre clé l'a signée, sur Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana et TON, depuis l'extension Chrome, l'app mobile ou le Hot Wallet, avec la Carte Métallique NFC disponible comme étape d'authentification sans contact sur l'appareil appairé. WATS facture aussi les frais de réseau dans un seul token, l'ATS, au lieu du token de gas natif de chaque chaîne : une session de révocations sur plusieurs chaînes n'est donc pas bloquée parce que vous détenez le mauvais token de gas. Aucun portefeuille ne supprime la nécessité de lire le dépensier et le montant avant de signer — cette décision vous appartient.