Permit2 crypto est un système d’autorisation développé par Uniswap Labs pour uniformiser l’utilisation des jetons ERC-20 dans les applications. Il ne remplace pas le wallet et ne rend pas une signature dangereuse plus sûre. Il sépare l’approbation on-chain du jeton des permissions que l’utilisateur signe pour une application précise. Cette architecture réduit les transactions répétées et la multiplication des allowances, mais elle impose un constat essentiel : après l’approbation d’un jeton à Permit2, une signature malveillante peut conférer un pouvoir financier réel.
Une utilisation sûre exige donc trois vérifications distinctes : le contrat qui reçoit l’approbation ERC-20, le contenu exact du message signé et le spender autorisé à agir. Ce guide explique les deux modèles de transfert, expiration et nonce, les risques de phishing, les limites du protocole et la méthode pour contrôler puis révoquer les permissions sans prendre une signature hors chaîne pour une simple connexion.
Permit2 crypto : ce que le mécanisme change vraiment
Dans le parcours ERC-20 traditionnel, l’utilisateur envoie une transaction approve(spender, amount) au contrat du jeton avant d’utiliser une dApp. Le spender, souvent un routeur, peut ensuite appeler transferFrom dans la limite du montant approuvé. Chaque nouveau spender nécessite une allowance et une transaction on-chain distinctes ; une approbation illimitée peut rester active pendant des années.
Avec Permit2, l’utilisateur commence par approuver le contrat Permit2 comme spender ERC-20. Les applications intégrées demandent ensuite des permissions plus granulaires au moyen de signatures EIP-712. Le contrat vérifie signature, domaine, spender, jeton, montant, échéance et nonce avant de déplacer les fonds. L’application n’hérite pas automatiquement de l’approbation ERC-20 principale : elle ne reçoit que le pouvoir décrit dans le message signé et encadré par le module employé.
Un contrat commun peut servir plusieurs protocoles sans nouvelle transaction d’approbation à chaque fois. En revanche, un message « signer » sans gas peut tout de même autoriser le transfert de jetons approuvés à Permit2.
AllowanceTransfer ou SignatureTransfer : tableau de décision
Permit2 propose deux mécanismes différents. Le choix dépend du besoin : une autorité réutilisable ou une exécution ponctuelle.
| Question | AllowanceTransfer | SignatureTransfer |
|---|---|---|
| Que permet-il ? | Une allowance enregistrée pour propriétaire, jeton et spender | Un transfert ou un lot décrit par la signature |
| La permission persiste-t-elle ? | Oui, jusqu’à épuisement du montant ou expiration | Non après exécution standard : le nonce ne peut être rejoué |
| Comment la limiter ? | Montant, spender et expiration | Jeton, montant maximal, spender, deadline et nonce |
| Usage adapté | Interactions récurrentes avec une dApp fiable | Action unique ou lot atomique |
| Risque principal | Allowance persistante et excessive | Signature volée exécutée avant sa deadline |
AllowanceTransfer enregistre une autorisation dans le contrat. L’application peut la consommer en plusieurs opérations, dans la limite du solde autorisé et avant expiration. SignatureTransfer utilise une signature pour autoriser un transfert immédiat. Ses nonces non ordonnés sont organisés en bitmap, ce qui permet plusieurs permissions indépendantes sans séquence stricte. La variante witness peut lier des données applicatives supplémentaires, à condition que l’intégration les définisse et les vérifie correctement.
L’approbation ERC-20 à Permit2 constitue la base
La première étape reste une transaction normale envoyée au contrat du jeton. Le champ spender doit contenir l’adresse officielle de Permit2 pour le réseau actif, et non le site web, le routeur de la dApp ou une adresse copiée dans un message. Avant de confirmer, il faut comparer réseau, contrat du jeton, spender et montant avec la documentation officielle de l’application.
Une approbation exacte limite l’exposition, mais devra être renouvelée. Une allowance élevée réduit les frictions tout en augmentant la somme accessible après une signature dangereuse. Une approbation illimitée n’autorise pas n’importe quel site à prendre les jetons : elle permet à Permit2 de les déplacer sous une permission valide. Elle reste néanmoins un pouvoir durable.
La révocation principale remet à zéro l’allowance ERC-20 accordée à Permit2. Elle bloque les nouveaux transferts de ce jeton même si une permission secondaire reste valide. Cette transaction coûte du gas et doit viser le réseau et le contrat de l’approbation initiale.
Signatures EIP-712, expiration, deadline et nonce
Les signatures typées EIP-712 peuvent être décodées grâce à un domaine et à des champs structurés. Le domaine lie généralement la signature à un nom, un chain ID et un verifying contract. Une fenêtre bien présentée ne prouve pas sa sûreté. Il faut vérifier que le contrat de vérification est Permit2, que le réseau est celui attendu et que le spender correspond au contrat réellement nécessaire.
Dans AllowanceTransfer, expiration fixe la durée pendant laquelle le spender peut utiliser l’allowance enregistrée. Le nonce ordonne les mises à jour et empêche de réutiliser une ancienne permission remplacée. Une sigDeadline distincte limite le délai de soumission on-chain de la signature qui crée l’allowance. Expiration de l’allowance et deadline de la signature ne désignent donc pas la même échéance.
Dans SignatureTransfer, la deadline fixe le dernier instant d’exécution du transfert signé. Après exécution, le nonce est marqué comme utilisé et un replay échoue. Le nonce empêche une deuxième exécution, pas une première exécution hostile. Si la signature a été remise à un site malveillant, une courte deadline réduit la fenêtre d’attaque sans rappeler les données déjà transmises.
Scénario pratique : swap régulier ou opération unique
Prenons un utilisateur qui détient 5 000 USDC et veut en échanger 300 via un agrégateur. Le site demande d’abord l’approbation ERC-20 de USDC à Permit2. L’utilisateur vérifie le réseau, le véritable contrat USDC et l’adresse Permit2, puis choisit un montant limité plutôt qu’un plafond illimité.
Pour un seul swap, SignatureTransfer est souvent cohérent. Le message signé indique USDC, un maximum de 300, le spender de l’agrégateur, un nonce inutilisé et une deadline proche. Le contrat appelant peut dépenser moins que le maximum si l’exécution évolue, jamais davantage. Si le swap échoue avant consommation du nonce, la signature peut rester exécutable jusqu’à sa deadline ; l’erreur affichée par l’interface ne suffit pas à l’annuler.
Pour des swaps hebdomadaires sur un protocole vérifié, AllowanceTransfer réduit les demandes répétées. L’utilisateur peut autoriser 1 000 USDC pendant trente jours, puis contrôler l’allowance interne et l’approbation ERC-20 avant tout renouvellement.
Limites et responsabilités que Permit2 ne supprime pas
Permit2 exige des jetons compatibles avec ERC-20 et l’approbation requise. Il ne déplace pas l’actif natif sans représentation comme WETH. Pause, blacklist, frais de transfert ou solde insuffisant peuvent faire échouer l’exécution.
Permit2 ne certifie pas l’honnêteté du spender. Il valide l’autorisation et applique ses limites ; il ignore si l’utilisateur a mal compris une page contrefaite. L’intégration de la dApp compte également : witness mal géré, appelant insuffisamment lié ou affichage ambigu peuvent affaiblir les garanties attendues. Les guides CryptoRoad sur les smart contracts et leurs risques et sur le fonctionnement de la DeFi donnent le contexte nécessaire.
Une révocation ne récupère pas les fonds déjà transférés. Révoquer uniquement une permission interne laisse active l’approbation ERC-20 à Permit2. Inversement, remettre l’approbation du jeton à zéro bloque l’utilisation immédiate sans nécessairement effacer les enregistrements internes. Ces deux niveaux doivent être examinés séparément.
Phishing de signatures : les signaux importants
Le phishing réclame souvent une signature « pour se connecter » ou « réclamer un airdrop ». Si le wallet affiche Permit2, PermitSingle, PermitBatch ou un transfert typé, la demande peut créer une allowance ou déplacer des fonds.
- Le domaine provient d’une publicité, d’un message privé, d’un courriel urgent ou d’un résultat sponsorisé.
- Le spender diffère du contrat indiqué dans la documentation de la vraie dApp.
- Le montant maximal ou le batch inclut des jetons inutiles à l’action annoncée.
- L’expiration est lointaine, ou le wallet ne décode pas les champs importants.
- Le site réclame plusieurs signatures après une erreur sans expliquer le nonce précédent.
Refuser un message opaque est la bonne décision. Un hardware wallet protège la clé, pas le jugement : si l’utilisateur confirme une signature malveillante sur l’appareil, elle devient valide. Les soldes importants devraient être séparés du wallet quotidien, conformément au guide des wallets custodial, non custodial, hot et cold.
Contrôler et révoquer allowances et signatures
Le contrôle commence sur un explorateur fiable ou un gestionnaire d’allowances ouvert depuis un favori. Après sélection du bon réseau, il faut inspecter l’allowance du jeton accordée à Permit2, puis les allowances internes de Permit2 par propriétaire, jeton et spender. Un vérificateur ERC-20 classique peut n’afficher que le premier niveau et omettre les permissions secondaires.
Pour supprimer une allowance persistante, on utilise la fonction de lockdown/révocation de Permit2 ou une interface transparente qui compose l’appel correct. SignatureTransfer n’a pas d’allowance résiduelle classique : les nonces utilisés ne sont plus rejouables, tandis que les nonces disponibles peuvent être invalidés via les fonctions de bitmap. Une signature jamais divulguée et proche de sa deadline peut expirer ; si elle a été exposée, mieux vaut invalider son nonce.
En cas de compromission présumée, la priorité consiste à remettre à zéro l’approval ERC-20 vers Permit2 pour les jetons concernés, à révoquer les spenders directs et à déplacer les actifs vers un wallet sain si la seed phrase ou la clé privée a pu fuiter. Le guide CryptoRoad pour révoquer les autorisations crypto distingue le pouvoir encore actif des transferts déjà exécutés.
Erreurs fréquentes et meilleures décisions
Croire que toute signature est sans danger. Une signature Permit2 peut équivaloir économiquement à une autorisation. Il faut lire jeton, spender, montant et limites temporelles.
Révoquer sur le mauvais réseau. Une allowance dépend de la chaîne, du jeton et du propriétaire. Une révocation sur Ethereum ne modifie pas la position correspondante sur une L2.
Vérifier seulement le symbole. Un faux jeton peut reprendre le même nom. Seule l’adresse du contrat permet de l’identifier.
Choisir par défaut une approbation illimitée. Elle ne se justifie que si fréquence, frais de gas et confiance dans le spender compensent l’exposition. Une action unique appelle un montant limité et une deadline courte.
Signer à nouveau après un timeout. La première demande peut rester valide. Il faut contrôler transaction, nonce et expiration avant toute nouvelle signature.
Checklist d’hygiène du wallet
- Ouvrir les dApps depuis des favoris et vérifier domaine, réseau et contrat.
- Ne conserver dans le wallet opérationnel que le capital nécessaire.
- Confirmer l’adresse officielle de Permit2 sur la chaîne utilisée.
- Préférer des montants bornés et des expirations courtes pour une action ponctuelle.
- Lire spender, jeton, montant, expiration, deadline et nonce avant de signer.
- Refuser les messages non décodés et les lots de jetons injustifiés.
- Contrôler régulièrement approvals ERC-20 et allowances internes.
- Révoquer après une campagne, un mint, un swap unique ou un test.
- Ne jamais saisir une seed phrase sur un site de révocation ou de support.
- Après une signature suspecte, invalider les permissions et déplacer les actifs si la clé est menacée.
Conclusion : gagner en fluidité sans déléguer la sécurité
Permit2 crypto simplifie l’interaction avec les dApps en centralisant une approbation ERC-20 et en permettant des permissions signées plus granulaires. AllowanceTransfer convient aux relations récurrentes, mais laisse un pouvoir utilisable jusqu’à épuisement ou expiration. SignatureTransfer vise l’exécution ponctuelle avec nonce anti-replay et deadline, mais une signature volée peut encore être exécutée une fois.
La règle pratique consiste à séparer les niveaux : vérifier l’approbation du jeton à Permit2, puis la permission signée pour le spender. Limites faibles, durées courtes et wallets compartimentés réduisent l’impact d’une erreur.
