L’absence de transaction payante ne rend pas un message inoffensif. Lisez type de demande, domaine, réseau, contrat, bénéficiaire, montant et expiration. Si le portefeuille ne permet pas d’en comprendre la portée, refusez.
Lire le message
Lisible ne veut pas dire sûr
Permission différée
Connexion
Un message de connexion devrait expliquer le service, le compte et le contexte de session. Ne déduisez pas sa fonction du bouton « se connecter » : lisez la demande réelle. Un site peut présenter un message d’autorisation à la place.
Données structurées
EIP-712 structure une signature pour afficher ses champs. Le format n’approuve pas le contrat ni la légitimité du site. Comparez chaîne et contrat vérificateur avec une documentation obtenue indépendamment ; un domaine malveillant peut utiliser un format parfaitement valide.
Permit
Certains tokens permettent d’accorder une allowance par message signé. Un tiers peut soumettre cette signature ultérieurement selon les règles du contrat. Vérifiez spender, plafond, nonce et deadline. Dans ERC-2612, la deadline limite la soumission du permit ; elle ne constitue pas automatiquement une expiration de l’allowance créée.
Opérateurs NFT
Une autorisation d’opérateur peut couvrir tous vos NFT d’un contrat, plutôt qu’un seul objet. Vérifiez collection, opérateur et pouvoir exact. Un écran indiquant « gratuit » décrit éventuellement le coût immédiat, pas l’étendue des droits accordés.
Après une erreur
Conservez les champs de la demande sans publier de secret. Déconnexion, révocation d’allowance et invalidation d’une signature sont distinctes. La réponse dépend du contrat et du nonce ; consultez une procédure vérifiée. Si les clés ont été exposées, une simple révocation n’est pas suffisante.
Une vérification concrète
Contrôlez domaine, réseau, spender, montant et échéance : une signature sans gas peut permettre une dépense ultérieure.
Comparer les demandes de signature
| Mécanisme | Droit potentiel | À contrôler |
|---|---|---|
| Connexion | Authentifier une session selon le message | Service, compte, contexte et durée |
| approve (ERC-20) | Allowance enregistrée pour un spender | Token, spender, montant |
| permit (ERC-2612) | Créer une allowance après soumission du message | Contrat, valeur, nonce, deadline |
| setApprovalForAll (ERC-721) | Opérateur sur tous vos NFT du contrat | Collection, opérateur, activation ou retrait |
Questions fréquentes
Une signature gratuite peut-elle être dangereuse ?
Oui, elle peut autoriser une action ultérieure même sans transaction immédiate.
Un permit expiré supprime-t-il une allowance déjà créée ?
Pas automatiquement dans ERC-2612 : la deadline concerne la soumission du permit.
Déconnecter le site annule-t-il mes signatures ?
Non. Cela ne révoque pas automatiquement les droits enregistrés ou les messages déjà signés.
Une signature de connexion et une délégation EIP-7702 sont-elles équivalentes ?
Non. Une signature de connexion sert à une authentification selon le message ; une autorisation EIP-7702 peut déléguer du code au compte. Cette délégation peut persister et la clé initiale conserve le contrôle. Vérifiez le type de demande et sa portée ; ne concluez pas qu’une signature est inoffensive parce qu’elle ne paie pas de gas immédiatement.
Sources vérifiables
Ethereum.org — Signing safety- EIP-712 — Typed structured data signing
- ERC-2612 — Signed token permits
- ERC-20 — Token allowances
- ERC-721 — NFT operators
- EIP-7702 — Account code delegation
Contenu pédagogique indépendant, relu à partir de documentation primaire. Aucune recommandation personnalisée ni promesse de rendement. Mis à jour le 6 octobre 2026
