---
title: "Chain ID"
description: "Guide fondé sur la vérification des chain ID EVM, domaines anti-rejeu EIP-155 des transactions legacy, transactions typées, CHAINID, contrôles wallet et RPC, domaines EIP-712 et identifiants non EVM."
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.
# Chain ID
> À 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
Dans l'écosystème EVM, la chain ID est un entier configuré servant de paramètre de domaine anti-rejeu. EIP-155 la lie aux signatures protégées des transactions legacy ; les formats typés, comme le type 2, l'encodent dans leur payload signé ; `CHAINID` l'expose pendant l'exécution EVM ; `eth_chainId` la renvoie par JSON-RPC. Ces interfaces sont liées, mais ne constituent pas un certificat universel d'identité.
La valeur n'est ni garantie unique au niveau mondial ni permanente. Des réseaux privés et forks conflictuels peuvent la réutiliser, un RPC peut mentir et une même adresse peut contenir un code et un état différents selon la chaîne. EIP-712 comporte un champ chain ID facultatif, tandis que les messages bruts et systèmes non EVM suivent d'autres règles. Il faut donc connaître le schéma de signature, l'endpoint, le genesis ou checkpoint et le domaine applicatif exacts.
## Fonctionnement
1. Identifiez d'abord l'écosystème et la sémantique : entier EIP-155 EVM, domaine EIP-712, référence CAIP-2 avec namespace, chain ID textuelle Cosmos, genesis hash Solana ou autre schéma. Ne comparez jamais un nombre non qualifié entre écosystèmes.
2. Fixez un instantané fiable : URL RPC, chain ID attendue en décimal et hexadécimal, genesis ou checkpoint finalisé, bloc de tête, configuration client, `codeHash` des contrats clés et date de la source. Nom et icône du réseau dans le wallet sont des métadonnées non fiables.
3. Interrogez `eth_chainId` pour signer sur EVM et analysez la quantité hexadécimale JSON-RPC sans perte de précision. Comparez l'entier normalisé à la configuration et à l'état du provider ; ne remplacez pas par `net_version` ; refusez tout écart avant de signer.
4. Reconstituez le domaine exact. Distinguez transactions legacy non protégées, legacy EIP-155 et enveloppes typées ; pour EIP-712, vérifiez champs du domaine, `verifyingContract`, nonce et deadline ; pour intents relayés ou smart accounts, inspectez le hash interne du protocole.
5. Vérifiez sur la chaîne active destinataire, valeur, calldata, adresse du token, code ou implémentation proxy, nonce, frais et état simulé. La chain ID sépare un domaine, mais n'authentifie aucun de ces objets.
6. Traitez `chainChanged` d'EIP-1193, changements de compte et déconnexions comme des frontières strictes. Supprimez cotation, allowance, nonce, simulation et requête de signature en cache, relisez chaîne et cible et ne diffusez que la transaction brute vérifiée vers l'endpoint fixé.
7. Rapprochez sur la chaîne prévue bytes signés et hash, acceptation RPC, statut du reçu, numéro et hash de bloc, consommation du nonce, changements d'état et finalité. Surveillez forks, changements d'ID, confusion L1/L2 et dérive du provider ; arrêtez-vous face à toute différence inexpliquée.
## Exemples détaillés
- **Contrôle RPC hexadécimal et décimal.** Base a la chain ID décimale `8453`, renvoyée par `eth_chainId` sous la forme `0x2105` : `2 * 4096 + 1 * 256 + 0 * 16 + 5 = 8453`. Ethereum mainnet vaut `1 = 0x1` et Arbitrum One `42161 = 0xa4b1`. Si le wallet attend `8453` mais reçoit `0x1`, il doit abandonner avant signature.
- **v d'une transaction legacy protégée.** Pour EIP-155, `v = 35 + 2 * chainId + yParity`. Avec l'ID `1`, les valeurs sont `37` ou `38` ; avec l'ID `61`, `157` ou `158`. Inversement, `floor((37 - 35) / 2) = 1`. Ce calcul ne vaut ni pour y-parity des transactions typées ni pour les signatures legacy non protégées avec `27` ou `28`.
- **Transaction typée et rejet sur la mauvaise chaîne.** Un payload de type 2 lie `chain_id=8453`. Avec `21,000 gas`, base fee `20 gwei`, priority fee maximal `2 gwei` et fee maximal `30 gwei`, le prix effectif est `min(30, 20 + 2) = 22 gwei` et les frais `21,000 * 22 gwei = 0.000462 ETH`. Une chaîne appliquant correctement l'ID `1` rejette le payload pour écart de domaine sans consommation de gas on-chain ; il peut encore échouer pour une autre raison sur l'ID 8453.
- **Identifiants doubles et non EVM.** Cosmos EVM peut utiliser l'ID texte Cosmos SDK `local-1` et l'ID entier EVM indépendant `262144 = 0x40000`. La signature native Cosmos utilise texte, numéro de compte et sequence ; la signature EVM utilise l'entier. Solana utilise genesis hash et recent blockhash ou durable nonce, non un entier EIP-155.
## Risques
- Mauvais endpoint RPC ou mauvaise chaîne active.
- RPC malveillant sur l'ID, l'état ou la diffusion.
- Confusion hexadécimal/décimal.
- Perte de précision numérique.
- `net_version` pris pour `eth_chainId`.
- Événement `chainChanged` ou course de bascule manqués.
- Réutilisation de nonces, cotations, approvals ou simulations.
- Unicité mondiale sans collision supposée.
- Signature sur réseaux privés ou forks avec le même ID.
- Comportement après fork non défini.
- Transaction legacy non protégée acceptée.
- Formule legacy `v` appliquée ailleurs.
- Domaine supposé dans message brut ou `personal_sign`.
- Chain ID EIP-712 omise ou mal encodée.
- `verifyingContract`, nonce, deadline ou objectif omis.
- Adresse identique sans comparaison du code et de l'état.
- Confusion des domaines L1, L2, origine et destination.
- Domaine interne d'intent, permit ou smart account ignoré.
- Métadonnées, explorer ou icône pris pour authentification.
- Sémantique EVM transposée à un autre protocole.
## Idées reçues
- La chain ID est un numéro officiel mondial, unique et permanent.
- Une chain ID correcte authentifie RPC, réseau et contrats.
- Toute signature Ethereum lie automatiquement la chain ID.
- Des ID différents empêchent le rejeu de tout message signé.
- Toute blockchain utilise un entier de type EIP-155.
## Sujets connexes
- [Signature typée EIP-712](/fr/crypto/eip712-typed-signature/)
- [Signature du wallet](/fr/crypto/wallet-signature/)
- [Nœud RPC](/fr/crypto/rpc-node/)
## Sources
- [EIP-155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155) - Ethereum Improvement Proposals (consulté : 2026-08-12)
- [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559) - Ethereum Improvement Proposals (consulté : 2026-08-12)
- [EIP-1344: ChainID opcode](https://eips.ethereum.org/EIPS/eip-1344) - Ethereum Improvement Proposals (consulté : 2026-08-12)
- [EIP-1193: Ethereum Provider JavaScript API](https://eips.ethereum.org/EIPS/eip-1193) - Ethereum Improvement Proposals (consulté : 2026-08-12)
- [EIP-3085: wallet_addEthereumChain RPC Method](https://eips.ethereum.org/EIPS/eip-3085) - Ethereum Improvement Proposals (consulté : 2026-08-12)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consulté : 2026-08-12)
- [CAIP-2: Blockchain ID Specification](https://standards.chainagnostic.org/CAIPs/caip-2) - Chain Agnostic Improvement Proposals (consulté : 2026-08-12)
- [getGenesisHash RPC Method](https://solana.com/docs/rpc/http/getgenesishash) - Solana Documentation (consulté : 2026-08-12)
Source: https://wiki.fcontext.com/fr/crypto/chain-id/index.mdx