Approbations de tokens, allowances et Permit : ce que vous signez vraiment

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'à épuisement ou modification de l'allowance. Deux propriétés comptent. Premièrement, l'allowance est détenue par le contrat que vous avez approuvé, pas par le 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é avec des délégations expirantes et plafonnées. 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 — nous couvrons la façon sûre de procéder 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). 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 navigateur ou l'app mobile, sur EVM, Solana et TON. Le volet frais est là où WATS ne ressemble à rien d'autre : chaque action, y compris les transactions d'approbation et de révocation, est facturée dans un seul token, l'ATS, au lieu du gas natif de la chaîne — via un paymaster ERC-4337 sur EVM et un fee-payer/relayer équivalent sur Solana et TON — de sorte que le nettoyage de vieilles allowances ne cale jamais faute de token de gas sur ce réseau. L'ATS collecté est brûlé, de 100M vers un plancher de 30M, et comme l'ATS est un OFT LayerZero, un seul solde couvre toutes les chaînes. WATS est le premier et le seul portefeuille à combiner les frais en token unique ERC-4337 + OFT avec ce burn — détails sur la page des frais ATS.