﻿---
title: "Chain ID"
description: "Guia orientado à verificação sobre chain IDs EVM, domínios antirreplay EIP-155 de transações legacy, transações tipadas, CHAINID, verificações de wallet e RPC, domínios EIP-712 e identificadores de redes não 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

> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

<a id="answer"></a>

## Resposta direta

No ecossistema EVM, chain ID é um inteiro configurado usado como parâmetro de domínio antirreplay. A EIP-155 o vincula às assinaturas protegidas de transações legacy; formatos tipados, como o tipo 2, o codificam no próprio payload assinado; `CHAINID` o expõe durante a execução EVM; e `eth_chainId` o informa via JSON-RPC. São interfaces relacionadas, não um certificado universal de identidade.

O valor não é garantidamente único no mundo nem permanente. Redes privadas e forks controversos podem reutilizá-lo, um RPC pode mentir e o mesmo endereço pode conter código e estado diferentes em chains distintas. A EIP-712 inclui um campo opcional de chain ID no domínio, enquanto mensagens brutas e sistemas não EVM usam outras regras de replay e identidade. O uso correto exige o esquema exato de assinatura, endpoint, genesis ou checkpoint e domínio da aplicação.

<a id="mechanism"></a>

## Como funciona

1. Identifique primeiro o ecossistema e a semântica: inteiro EIP-155 EVM, domínio EIP-712, referência com namespace CAIP-2, chain ID textual Cosmos, genesis hash Solana ou outro esquema. Nunca compare entre ecossistemas um número sem qualificação.
2. Fixe um snapshot confiável: URL RPC, chain ID esperado em decimal e hexadecimal, genesis ou checkpoint finalizado, bloco de cabeçalho, configuração do cliente, `codeHash` de contratos essenciais e data da fonte. Nome e ícone de rede da wallet são metadados não confiáveis.
3. Consulte `eth_chainId` para assinatura EVM e analise a quantidade hexadecimal JSON-RPC sem perda de precisão. Compare o inteiro normalizado com a configuração esperada e o estado do provider da wallet; não substitua por `net_version`; rejeite divergências antes de construir a assinatura.
4. Reconstrua o domínio exato. Distinga transações legacy desprotegidas, codificação legacy protegida EIP-155 e envelopes tipados; em EIP-712 verifique campos do domínio, `verifyingContract`, nonce e deadline; em intents retransmitidos ou de smart accounts examine o hash interno do protocolo.
5. Verifique o alvo na chain ativa: destinatário, valor, calldata, endereço do token, código ou implementação do proxy, nonce da conta, taxas e estado simulado. Chain ID separa o domínio, mas não prova autenticidade desses objetos.
6. Trate `chainChanged` da EIP-1193, mudanças de conta e desconexões como fronteiras rígidas. Descarte cotação, allowance, nonce, simulação e pedidos de assinatura em cache, releia chain e alvo e transmita apenas a transação bruta revisada ao endpoint fixado.
7. Concilie na chain pretendida: bytes assinados e hash, aceitação RPC, status do recibo, número e hash do bloco, consumo de nonce, mudanças de estado e finalidade exigida. Monitore forks, mudanças de ID, confusão L1/L2 e desvio do provider; falhe de forma fechada diante de diferenças inexplicadas.

<a id="example"></a>

## Exemplos resolvidos

- **Gate RPC hexadecimal e decimal.** Base tem chain ID decimal `8453`, representado por `eth_chainId` como `0x2105`: `2 * 4096 + 1 * 256 + 0 * 16 + 5 = 8453`. Ethereum mainnet é `1 = 0x1` e Arbitrum One `42161 = 0xa4b1`. Se a wallet espera `8453` e recebe `0x1`, deve abortar antes de assinar em vez de confiar no nome exibido.
- **v de transação legacy protegida.** Para transações legacy EIP-155, `v = 35 + 2 * chainId + yParity`. Com chain ID `1`, os valores são `37` ou `38`; com chain ID `61`, `157` ou `158`. Inversamente, `floor((37 - 35) / 2) = 1`. A aritmética não vale para y-parity de transações tipadas nem para assinaturas legacy desprotegidas com `27` ou `28`.
- **Transação tipada e rejeição na chain errada.** Um payload tipo 2 vincula `chain_id=8453`. Com `21,000 gas`, base fee de `20 gwei`, prioridade máxima de `2 gwei` e taxa máxima de `30 gwei`, o preço efetivo é `min(30, 20 + 2) = 22 gwei` e a taxa `21,000 * 22 gwei = 0.000462 ETH`. Uma chain que aplique corretamente ID `1` rejeita o payload assinado por divergência de domínio; essa rejeição não consome gas on-chain ali. A transação ainda pode falhar por outros motivos no ID 8453.
- **Identificadores duais e não EVM.** Uma implantação Cosmos EVM pode usar ID textual Cosmos SDK `local-1` e ID inteiro EVM independente `262144 = 0x40000`. A assinatura Cosmos-native usa a string com número da conta e sequence; a assinatura EVM usa o domínio inteiro. Solana expõe um genesis hash e usa recent blockhash ou durable nonce, não inteiro EIP-155.

<a id="risks"></a>

## Riscos

- Conectar ao RPC ou à chain ativa errados.
- Confiar em RPC malicioso sobre ID, estado ou broadcast.
- Confundir hexadecimal e decimal.
- Perder precisão com tipo numérico inseguro.
- Usar `net_version` como equivalente a `eth_chainId`.
- Perder `chainChanged` ou corrida de troca.
- Reutilizar nonces, cotações, approvals ou simulações.
- Supor registro global sem colisões.
- Assinar em redes privadas ou forks com o mesmo ID.
- Não definir comportamento de ID após fork.
- Aceitar transação legacy sem domínio EIP-155.
- Aplicar fórmula `v` legacy a outras assinaturas.
- Supor domínio em mensagem bruta ou `personal_sign`.
- Omitir ou codificar errado chain ID EIP-712.
- Omitir `verifyingContract`, nonce, deadline ou finalidade.
- Confiar em endereço idêntico sem comparar código e estado.
- Confundir domínios L1, L2, origem e destino.
- Ignorar domínio interno de intent, permit ou smart account.
- Tratar metadados, explorer ou ícone como autenticação.
- Transplantar semântica EVM para outro protocolo.

<a id="misconceptions"></a>

## Erros comuns

- Chain ID é registro oficial global, único e permanente.
- Chain ID correto prova RPC, rede e contratos.
- Toda assinatura Ethereum inclui chain ID.
- IDs diferentes impedem replay de toda mensagem.
- Toda blockchain usa inteiro EIP-155.

<a id="related"></a>

## Tópicos relacionados

- [Assinatura tipada EIP-712](/pt-br/crypto/eip712-typed-signature/)
- [Assinatura de wallet](/pt-br/crypto/wallet-signature/)
- [Nó RPC](/pt-br/crypto/rpc-node/)

<a id="sources"></a>

## Fontes

- [EIP-155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
- [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
- [EIP-1344: ChainID opcode](https://eips.ethereum.org/EIPS/eip-1344) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
- [EIP-1193: Ethereum Provider JavaScript API](https://eips.ethereum.org/EIPS/eip-1193) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
- [EIP-3085: wallet_addEthereumChain RPC Method](https://eips.ethereum.org/EIPS/eip-3085) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
- [CAIP-2: Blockchain ID Specification](https://standards.chainagnostic.org/CAIPs/caip-2) - Chain Agnostic Improvement Proposals (acessado em: 2026-08-12)
- [getGenesisHash RPC Method](https://solana.com/docs/rpc/http/getgenesishash) - Solana Documentation (acessado em: 2026-08-12)

Source: https://wiki.fcontext.com/pt-br/crypto/chain-id/index.mdx
