---
title: "Risque lié à la signature Permit2"
description: "Permit2 sépare les allowances réutilisables des transferts ponctuels autorisés par signature ; signer en sécurité exige de vérifier précisément le déploiement, le domaine, le spender, le destinataire, le montant, le nonce, l’échéance, le witness et les calldata d’exécution."
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.
# Risque lié à la signature Permit2
> À 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
Permit2 réunit deux systèmes d’autorisation distincts. `AllowanceTransfer` enregistre une allowance réutilisable entre propriétaire, token et spender, assortie d’un montant, d’une expiration et d’un nonce ordonné. `SignatureTransfer` consomme une fois un plafond signé au moyen d’un nonce bitmap non ordonné et ne crée aucune allowance aval persistante. Tous deux dépendent néanmoins de l’allowance ERC-20 accordée par le propriétaire du token à Permit2.
Une signature sans frais de gas pour l’utilisateur peut déplacer des actifs lorsqu’un spender ou un relayeur paie l’exécution. Il faut vérifier précisément la chaîne, le code Permit2 déployé, le domaine EIP-712, le module, le token, le spender, le plafond signé, les calldata du destinataire, le nonce et les contraintes temporelles. Un contrat Permit2 légitime ne rend pas sûrs un spender, un destinataire, un routeur ou un witness malveillants.
## Fonctionnement
1. Fixer `chainId`, le réseau, le `verifyingContract` Permit2, le code d’exécution déployé, l’adresse et les décimales du token, le type de wallet du propriétaire et l’application prévue. Utiliser un registre officiel des déploiements : une adresse ou une étiquette familière ne suffit pas.
2. Lire le solde et l’allowance ERC-20 amont du propriétaire vers Permit2. Distinguer une approbation limitée d’une approbation illimitée et identifier le comportement propre au token lors des transferts ; ce registre subsiste après l’expiration d’une signature Permit2 ou d’une allowance aval enregistrée.
3. Identifier le parcours exact et le type primaire signé : `PermitSingle` ou `PermitBatch` pour AllowanceTransfer, ou `PermitTransferFrom` ainsi que ses variantes batch et witness pour SignatureTransfer. Ne pas confondre `transferFrom` avec le type signé.
4. Décoder le domaine EIP-712 et chaque entrée du message. Pour AllowanceTransfer, vérifier le token, `uint160 amount`, `expiration`, le nonce ordonné, le spender et `sigDeadline`. Pour SignatureTransfer, vérifier le token et le montant autorisés, le nonce non ordonné, l’échéance et le spender lié par le contexte de l’appelant.
5. Décoder séparément les calldata d’exécution. Dans le SignatureTransfer de base, `SignatureTransferDetails.to` et `requestedAmount` sont des paramètres d’exécution, et non des champs du permis signé de base ; le montant demandé doit seulement rester inférieur ou égal au plafond signé. Vérifier chaque indice du batch ainsi que, le cas échéant, le hash du witness et la chaîne de type exacts.
6. Interroger le nonce courant de l’allowance ordonnée ou le mot et le bit de la bitmap non ordonnée, puis simuler l’appelant, les calldata, la chaîne et l’état exacts. Rapprocher le destinataire, les actions du routeur, les particularités du token, le solde et les deux registres d’allowance ; la simulation peut diverger selon l’état, l’ordre des transactions ou une réorganisation.
7. Réduire au minimum les montants et les durées. En cas de soupçon, conserver les données typées et soumettre, par un canal fiable, la révocation appropriée de l’approbation amont, de l’allowance aval ou l’invalidation du nonce, en la traitant comme une course dans le mempool ; attendre la confirmation et rapprocher transferts, soldes, allowances et bits de bitmap.
Le `sigDeadline` d’AllowanceTransfer limite la période pendant laquelle le permis signé peut créer ou mettre à jour l’autorité enregistrée ; `expiration` limite la durée pendant laquelle cette autorité peut être utilisée. L’échéance de SignatureTransfer limite son exécution ponctuelle. EIP-712 apporte le hachage typé et la séparation des domaines, mais ni protection contre le rejeu ni garantie de l’intention : ces limites reposent sur les règles de nonce et d’échéance de Permit2.
Pour un wallet contractuel, la validité ERC-1271 dépend de la politique `isValidSignature` actuelle, des modules, des seuils et du code du wallet. Les étiquettes du wallet, les écrans tronqués d’un hardware wallet et les simulations réussies sont des éléments d’analyse, pas des garanties. Déconnecter un frontend ne révoque aucune approbation ni signature.
## Exemple
- **Deux registres d’allowance.** L’allowance limitée du token vers Permit2 commence à `1,000 USDC` ; un `PermitSingle` enregistre `600 USDC` pour le spender S. Après un transfert de `225 USDC` par S, le montant enregistré est de `600 - 225 = 375 USDC`, tandis qu’une allowance amont standard et limitée devient `1,000 - 225 = 775 USDC`. Faire expirer ou révoquer 375 n’efface pas automatiquement 775 ; les tokens non standard peuvent se comporter différemment.
- **Destinataire et montant ponctuels.** Un SignatureTransfer signe un plafond de `250 USDC` ; les calldata demandent `180 USDC` au bénéfice d’un commerçant. Si le solde et l’allowance amont sont suffisants, l’exécution peut transférer 180. Le nonce est consommé, de sorte que les `70 USDC` inutilisés ne sont pas réutilisables. Si les calldata désignent un attaquant comme destinataire, le permis de base n’empêche pas à lui seul cette redirection par le spender lié.
- **Bitmap de nonces non ordonnés.** Pour le nonce `513`, `wordPos = 513 >> 8 = 2`, `bitPos = 513 & 255 = 1` et `mask = 1 << 1 = 2`. L’exécution positionne le bit 1 du mot 2 ; rejouer 513 échoue, tandis que le nonce `512`, au bit 0, reste indépendant.
- **Course à la révocation.** Une allowance enregistrée vaut `400 USDC`. Le propriétaire diffuse une révocation à zéro, mais un transfert de `300 USDC` s’exécute d’abord et laisse `100 USDC` ; la révocation ultérieure ramène le reliquat à `0`. Une allowance finale nulle n’annule pas la perte réalisée de `300 USDC` : il faut rapprocher l’ordre des transactions et les soldes.
## Risques
- Identifiant de chaîne, déploiement ou code d’exécution erroné
- Contrat de vérification contrefait ou inattendu
- Confusion entre AllowanceTransfer et SignatureTransfer
- Spender ou appelant malveillant ou renseigné par erreur
- Destinataire choisi dans les calldata d’exécution
- Montant demandé proche du plafond signé
- Adresse, symbole, décimales ou unités brutes du token erronés
- Approbation ERC-20 amont persistante ou illimitée
- Montant ou expiration aval excessifs
- Confusion entre échéance, échéance de signature et expiration
- Nonce ordonné obsolète ou faisant l’objet d’une course
- Bit de bitmap réutilisé ou masque d’invalidation trop large
- Hash du witness ou chaîne de type exacte non concordants
- Entrée de batch masquée, dupliquée ou mal indexée
- Écart entre l’affichage du frontend, les calldata et l’intention
- Révocation devancée dans le mempool ou par le MEV
- Changement de module, de signataire, de seuil ou mise à niveau ERC-1271
- Token à frais de transfert, rebasing, pause, blocage ou callback
- Dérive de l’état simulé, échec de simulation ou réorganisation
- Confirmation sur hardware wallet ou déconnexion prise pour une garantie
## Idées reçues
- **Une signature sans demande de gas ne peut pas déplacer de tokens.** Une autre partie peut payer le gas de l’exécution.
- **L’adresse Permit2 officielle prouve que le spender et le destinataire sont sûrs.** Permit2 peut exécuter fidèlement une autorité malveillante.
- **SignatureTransfer et AllowanceTransfer créent la même autorisation persistante.** Le premier est à usage unique ; le second enregistre une allowance réutilisable.
- **Déconnecter ou révoquer une couche annule tous les parcours et toutes les signatures en attente.** Les états amont, aval et des nonces sont distincts, et les courses demeurent.
- **EIP-712, un hardware wallet ou une simulation réussie prouvent l’intention et la finalité.** Ils améliorent la visibilité ou les tests, mais ne remplacent pas la vérification des champs, des calldata et de l’état confirmé.
## Sujets connexes
- [Signature typée EIP-712](/fr/crypto/eip712-typed-signature/)
- [Approbation du wallet](/fr/crypto/wallet-approval/)
- [Signature du wallet](/fr/crypto/wallet-signature/)
## Sources
- [Overview](https://developers.uniswap.org/docs/protocols/permit2/overview) - Uniswap Developers (consulté le 2026-08-13)
- [Allowance Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/allowance-transfer) - Uniswap Developers (consulté le 2026-08-13)
- [Signature Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/signature-transfer) - Uniswap Developers (consulté le 2026-08-13)
- [Deployments](https://developers.uniswap.org/deployments) - Uniswap Developers (consulté le 2026-08-13)
- [PermitHash.sol](https://github.com/Uniswap/permit2/blob/main/src/libraries/PermitHash.sol) - Uniswap Permit2 (consulté le 2026-08-13)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consulté le 2026-08-13)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (consulté le 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consulté le 2026-08-13)
Source: https://wiki.fcontext.com/fr/crypto/permit2-signature-risk/index.mdx