---
title: "Signatures typées EIP-712 : domaines, condensés et vérification sûre"
description: "EIP-712 rend les messages structurés Ethereum déterministes et lisibles, mais une signature sûre exige de vérifier précisément domaine, type, valeur, nonce, échéance, exécution et politique du signataire."
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.
# Signatures typées EIP-712 : domaines, condensés et vérification sûre
> À 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
EIP-712 normalise la manière dont les applications Ethereum décrivent, hachent et font signer des données structurées typées. Une demande contient `types`, `primaryType`, `domain` et `message` ; son condensé est `keccak256("\x19\x01" || domainSeparator || hashStruct(message))`. L'encodage devient déterministe et un portefeuille compatible peut afficher les champs plus clairement qu'un hachage opaque.
La norme ne rend **pas** le message véridique, anodin, révocable ou protégé contre la répétition. L'application doit lier l'autorité à la bonne chaîne et au bon vérificateur, définir chaque champ sans ambiguïté, imposer nonces et limites temporelles, valider le bon signataire et restreindre l'exécution. Une signature valide prouve l'approbation d'un condensé exact selon une règle de vérification, pas l'identité, l'intention éclairée ni la sûreté du site ou du contrat.
## Fonctionnement
### 1. Identifier l'action et le chemin de vérification
Déterminez si la demande autorise une connexion, un ordre, un vote, une allowance de jeton, un transfert, un appel relayé ou une autre action. Repérez le code qui reconstruit le condensé et consomme la signature. Pour un compte détenu de l'extérieur, on récupère souvent une adresse depuis une signature ECDSA ; pour un compte contrat, ERC-1271 `isValidSignature(hash, signature)` et sa valeur de réussite `0x1626ba7e` peuvent être nécessaires.
### 2. Fixer le domaine
Examinez le type `EIP712Domain` exact et ses valeurs. Les champs standard sont `name`, `version`, `chainId`, `verifyingContract` et `salt`, mais seuls ceux présents sont hachés. Confirmez indépendamment chaîne active, code déployé et vérificateur prévu ; nom, symbole, étiquette de proxy ou adresse à somme de contrôle familiers ne suffisent pas. ERC-5267 `eip712Domain()` peut exposer le domaine, mais sa prise en charge est facultative et proxies ou mises à niveau restent à examiner.
### 3. Reconstruire le graphe des types
Partez de `primaryType`, conservez l'ordre des membres et rassemblez récursivement les structures référencées. `encodeType` ajoute leurs définitions triées par nom de type. EIP-712 accepte les entiers de largeur fixe, `address`, `bool`, de `bytes1` à `bytes32`, les `bytes` et `string` dynamiques, tableaux et structures ; les alias `uint` et `int`, types à virgule fixe et valeurs cycliques ne sont pas définis.
### 4. Décoder chaque valeur et unité
Associez chaque valeur à son type déclaré et à son sens applicatif. Vérifiez adresses complètes, unités entières brutes, signes, ordre des tableaux, destinataires, spenders, actifs, montants, frais, limites, destinations, hachages de calldata et chaînes lisibles. Les `bytes` et `string` dynamiques sont représentés dans `encodeData` par le hachage Keccak-256 de leur contenu ; les tableaux hachent les encodages concaténés et les structures imbriquées utilisent leur propre `hashStruct`.
### 5. Recalculer indépendamment le condensé
Calculez `typeHash = keccak256(encodeType(primaryType))`, puis `hashStruct(message) = keccak256(typeHash || encodeData(message))`. Calculez pareillement le séparateur de domaine et combinez-le aux octets de version ERC-191 `0x19 0x01`. Comparez frontend, bibliothèque de signature, contrat vérificateur et implémentation indépendante ; des JSON visuellement identiques ne prouvent pas un encodage typé identique.
### 6. Auditer répétition, temps et exécution
EIP-712 n'inclut aucune protection contre la répétition. Vérifiez que le validateur contrôle le signataire prévu, consomme ou invalide le bon nonce, impose `deadline` ou les fenêtres de validité, lie tous les paramètres critiques et conserve le résultat voulu si un relayeur ou un frontrunner soumet en premier. La séparation de domaine ne prévient que les collisions entre domaines réellement encodés ; des champs absents ou erronés peuvent permettre une réutilisation entre contrats ou chaînes.
### 7. Signer au minimum et rapprocher le résultat
Refusez champs cachés, types inexpliqués, valeurs illimitées, échéances lointaines, contrats inconnus, identifiants de chaîne divergents, écrans de blind signing ou contexte d'exécution incomplet. Conservez le JSON typé exact et le condensé, utilisez si possible un compte dédié et contrôlez transaction, reçu, événements, soldes, allowances, nonces, état de l'ordre et finalité. Déconnecter le site ne révoque ni une signature utilisable ni une autorité déjà créée.
## Exemples calculés
### Exemple 1 : Construction du type et du condensé
Pour `Order(address maker,address token,uint256 amount,uint256 nonce,uint256 deadline)`, `typeHash` est le hachage Keccak-256 de cette chaîne exacte, ordre des champs compris. Le hachage du message est `keccak256(typeHash || maker || token || amount || nonce || deadline)` et chaque membre encodé occupe 32 octets. Le condensé final ajoute `0x1901`, séparateur de domaine et hachage du message ; passer `amount` de `250000000` à `250000001` modifie le condensé et invalide l'ancienne signature.
### Exemple 2 : Unités et échéance
`250 USDC` d'un jeton à six décimales s'encodent comme valeur brute `250000000`, pas `250`. Si l'horodatage courant est `1727000000` et l'échéance `1727000900`, la fenêtre vaut `900 seconds = 15 minutes`. L'affichage décimal et l'horloge locale ne sont que des aides ; le vérificateur utilise l'entier brut et sa règle temporelle on-chain.
### Exemple 3 : Contrôle de répétition
Un ordre porte le nonce `41` et un maximum de `5 ETH`. Après consommation du nonce 41, une seconde soumission doit échouer même si la signature reste valide. Si le contrat ne consomme pas le nonce et que l'exécution n'est pas idempotente, la même signature peut autoriser encore `5 ETH` ; le séparateur de domaine seul ne l'empêche pas.
### Exemple 4 : Validité d'un portefeuille contrat
Un portefeuille contrat 2-sur-3 approuve un condensé avec A, B et C comme signataires. Les signatures de A et B peuvent faire renvoyer aujourd'hui `0x1626ba7e` par ERC-1271. Si une mise à niveau remplace B par D, les mêmes octets peuvent devenir invalides : la validité ERC-1271 peut dépendre de l'état, de la politique, du temps et d'appels externes actuels ; récupérer une adresse ne suffit pas pour un compte contrat.
## Risques
- `chainId` erroné ou absent
- `verifyingContract` contrefait ou inattendu
- `name` ou `version` de domaine trompeur
- Implémentation proxy ou domaine modifié après mise à niveau
- `primaryType` erroné ou type fantôme au libellé proche
- Ordre des membres, dépendances ou encodeur incompatible
- Adresse tronquée, substituée ou étiquetée de façon trompeuse
- Erreur de décimales ou d'entier signé contre non signé
- Élément de tableau, structure imbriquée ou charge `bytes` cachée
- Montant illimité, portée large ou destinataire contrôlé par l'attaquant
- Nonce absent, périmé, partagé ou mal consommé
- Échéance absente, lointaine, en dépassement ou ambiguë
- Répétition entre chaînes, contrats, comptes ou actions
- Rétention, censure, front-running ou redirection par le relayeur
- Malléabilité de signature ou récupération ECDSA trop permissive
- Changement de signataire, module, seuil, état ou code ERC-1271
- Rendu du portefeuille, blind signing ou type non pris en charge
- JSON du frontend différent du condensé du vérificateur
- Révocation ou annulation perdant une course d'ordonnancement
- Confusion entre dialogue de signature, reçu, état et finalité
## Idées reçues
### Idée reçue 1 : Les signatures EIP-712 sont des transactions
Ce sont des messages signés hors chaîne. Un relayeur peut les soumettre ensuite à un contrat ; la transaction résultante peut consommer du Gas et changer l'état sans être envoyée par le signataire.
### Idée reçue 2 : Un affichage structuré rend la demande sûre
Les champs typés facilitent l'examen, mais schémas, valeurs, contrats, libellés, imbrications cachées ou rendu incomplet malveillants peuvent encore tromper.
### Idée reçue 3 : Le séparateur de domaine empêche toute répétition
Il ne sépare que le domaine encodé. La répétition dans un même domaine exige nonce, échéance, annulation, comptabilité d'exécution ou idempotence ; un champ omis ne crée aucune frontière.
### Idée reçue 4 : Récupérer l'adresse attendue prouve l'autorisation
La récupération prouve une signature EOA sur le condensé, pas la sémantique applicative. Les comptes contrats exigent leur politique ERC-1271 plutôt qu'une récupération ordinaire.
### Idée reçue 5 : Fermer la page ou déconnecter le portefeuille annule la signature
Une signature copiée reste utilisable jusqu'à ce que nonce, échéance, annulation, état ou politique du vérificateur l'invalide. Vérifiez l'état on-chain pertinent, pas la session.
## Sujets connexes
- [Identifiant de chaîne](/fr/crypto/chain-id/)
- [Nonce et échéance du Permit ERC-2612](/fr/crypto/erc2612-permit-nonce-deadline/)
- [Risque des signatures Permit2](/fr/crypto/permit2-signature-risk/)
- [Autorisation du portefeuille](/fr/crypto/wallet-approval/)
- [Signature du portefeuille](/fr/crypto/wallet-signature/)
## Sources
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consulté : 2026-08-19)
- [ERC-191: Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191) - Ethereum Improvement Proposals (consulté : 2026-08-19)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (consulté : 2026-08-19)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (consulté : 2026-08-19)
- [ERC-5267: Retrieval of EIP-712 domain](https://eips.ethereum.org/EIPS/eip-5267) - Ethereum Improvement Proposals (consulté : 2026-08-19)
- [EIP-2: Homestead Hard-fork Changes](https://eips.ethereum.org/EIPS/eip-2) - Ethereum Improvement Proposals (consulté : 2026-08-19)
- [Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html) - Solidity Documentation (consulté : 2026-08-19)
- [ERC-7730: Structured Data Clear Signing Format](https://eips.ethereum.org/EIPS/eip-7730) - Ethereum Improvement Proposals (consulté : 2026-08-19)
Source: https://wiki.fcontext.com/fr/crypto/eip712-typed-signature/index.mdx