---
title: "Como verificar um endereço de contrato CREATE2"
description: "CREATE2 prevê um endereço a partir do deployer, do salt e do hash do código de inicialização, mas a verificação ainda exige evidências específicas da cadeia sobre fábrica, bytecode, implantação, proxy e controle."
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.

# Como verificar um endereço de contrato CREATE2

> Somente para fins educacionais; não constitui aconselhamento de investimento ou de segurança. Um endereço previsto, uma conta vazia, um checksum ou um rótulo de fábrica não provam implantação, código, controle, propriedade ou segurança.

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

## Resposta direta

CREATE2 prevê o endereço criado por um contrato deployer específico a partir de um `32-byte salt` e do hash do seu `init_code` exato. A fórmula do protocolo é `address = keccak256(0xff || deployer(20 bytes) || salt(32 bytes) || keccak256(init_code))[12:]`: calcula o hash de um `85-byte preimage` e mantém os últimos `20 bytes`. O deployer é a fábrica que executa CREATE2, não necessariamente a carteira que chamou a fábrica.

`init_code` é o bytecode de criação mais os argumentos do construtor codificados em ABI; ele é executado uma vez e produz o bytecode de execução. A versão do compilador, a otimização, as bibliotecas vinculadas, os metadados, os argumentos do construtor ou o ponto de entrada da fábrica podem alterar o hash. O código de execução é uma saída, não a entrada do CREATE2. O mesmo endereço só é comparável com o mesmo deployer, salt, código de inicialização, regras da EVM e estado da cadeia.

Um endereço contrafactual pode receber fundos antes de existir código, mas ainda não tem lógica de controle verificada. A previsão não prova implantação, propriedade, autorização, finalidade ou segurança. Verifique o bytecode e o calldata da fábrica, o recibo e os eventos, `eth_getCode`, nonce, armazenamento, saldo, implementação do proxy, inicializador e proprietário na cadeia e no bloco pretendidos.

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

## Como funciona

Fixe a cadeia ou o domínio, as regras do fork, RPC e bloco, o endereço da fábrica e o hash do runtime, o salt bruto, os bytes exatos do init, a codificação do construtor, o compilador e as bibliotecas vinculadas. Recalcule `keccak256(init_code)` e o `85-byte preimage`; normalize o preenchimento ABI, o endianess, o checksum e a extração dos últimos 20 bytes.

Depois decodifique a chamada e o valor enviados à fábrica. Confirme que a fábrica, o ponto de entrada, o domínio do salt, o construtor, o proprietário e o inicializador pretendidos estão vinculados. Para um proxy mínimo, faça o hash do bytecode de criação do clone que contém o endereço da implementação, não do runtime da implementação. Para um proxy, verifique separadamente a implementação, o administrador, os slots de armazenamento e a política de atualização.

O EIP-684 faz a criação reverter quando o nonce de destino não é zero ou o código não está vazio. Um construtor que falha também não deixa uma implantação válida. As suposições sobre `SELFDESTRUCT` e uma nova implantação dependem das regras do fork; nunca confie na antiga afirmação de que o código pode ser sempre substituído à vontade.

A evidência da implantação tem camadas: inclusão e status da transação, eventos emitidos, código e nonce, armazenamento e saldos, e depois um estado seguro ou finalizado. Uma resposta RPC bem-sucedida ou um checksum previsto não substitui a verificação do recibo e do estado. Cópias do mesmo endereço em cadeias diferentes podem ter código, proprietários, armazenamento e ativos diferentes.

Use este fluxo:

1. Fixe cadeia, fork, RPC e bloco; endereço da fábrica ou deployer e hash do runtime; bytes do salt; código init, argumentos do construtor, compilador e bibliotecas vinculadas.
2. Calcule o hash do código init e o preimagem CREATE2 exato, conferindo larguras, preenchimento, `0xff`, os últimos 20 bytes e o checksum.
3. Decodifique o calldata e o valor da fábrica; compare o endereço previsto, proprietário, inicializador, destino do proxy e permissões pretendidas.
4. Verifique recibo, status, eventos, `eth_getCode`, nonce, saldo e armazenamento na cadeia correta; registre estados não implantado e de colisão.
5. Inspecione fábrica, proxy, implementação, administrador, inicializador, atualização e premissas da Singleton Factory, incluindo destinos ERC-1167.
6. Teste falha do construtor, colisão por nonce/código, nova implantação sensível ao fork, fábricas aninhadas e premissas de domínio de cadeia ou replay.
7. Antes de financiar ou assinar, reconcilie valores humanos e brutos; depois da implantação, monitore hash do código, proprietário, implementação, funções, eventos e finalidade.

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

## Exemplos

- **Vetor EIP-1014:** deployer `0x0000000000000000000000000000000000000000`, salt zero, init `0x00` produz `0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38`.
- **Vínculo do construtor:** com deployer e salt fixos, alterar um argumento do construtor codificado em ABI altera `keccak256(init_code)` e, portanto, o endereço previsto; fazer hash do runtime verificaria o objeto errado.
- **Colisão:** se o nonce de destino for maior que `0` ou o código não estiver vazio, CREATE2 deve reverter conforme o EIP-684. Um endereço financiado com código vazio e nonce zero é apenas contrafactual e continua sem verificação.
- **Proxy mínimo:** o endereço de um clone ERC-1167 faz hash do bytecode de criação do clone que contém o endereço da implementação. Fazer hash do runtime da implementação gera uma previsão diferente.

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

## Riscos

- É usada a fábrica ou o deployer errado.
- A largura, o preenchimento, o endianess ou o domínio do salt estão errados.
- O código init é confundido com o bytecode de execução.
- Os argumentos do construtor são omitidos ou reordenados.
- O ponto de entrada, o valor ou o calldata da fábrica diferem.
- O proxy ou destino delegatecall não é a implementação pretendida.
- A cadeia, o fork ou o domínio EVM diferem.
- O nonce existente causa uma colisão.
- O código existente causa uma colisão.
- São usadas premissas obsoletas sobre nova implantação após SELFDESTRUCT.
- CREATE2 aninhado muda o deployer efetivo.
- As fórmulas CREATE e CREATE2 são misturadas.
- O destino da implementação ERC-1167 não é verificado.
- O endereço ou as premissas da Singleton Factory não são verificados.
- Uma atualização ou um administrador da implementação muda o comportamento.
- O compilador, os metadados, a biblioteca ou o artefato-fonte diferem.
- Recibo, mempool, falha e estados finalizados são confundidos.
- Um checksum ou envenenamento da interface esconde o endereço errado.
- Fundos pré-carregados não têm prova de propriedade da conta contrafactual.
- Premissas sobre EIP-7702, replay, gás, negação de serviço ou monitoramento obsoleto estão erradas.

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

## Equívocos comuns

- **“Uma conta vazia é segura ou tem proprietário.”** Ela pode não ter código nem controlador verificado.
- **“O salt sozinho determina o endereço.”** O deployer e o hash do código init também são vinculantes.
- **“CREATE2 faz hash do bytecode de execução.”** Ele faz hash do código de criação, incluindo os argumentos do construtor.
- **“O mesmo endereço em duas cadeias significa o mesmo código e controle.”** O estado e as implantações de cada cadeia precisam ser verificados separadamente.
- **“Uma previsão bem-sucedida prova implantação e segurança.”** Apenas recibo, código, estado, permissões e finalidade estabelecem o que existe.

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

## Tópicos relacionados

- [Contrato proxy](/pt-br/crypto/proxy-contract/)
- [Contrato inteligente](/pt-br/crypto/smart-contract/)
- [Verificação de endereço de contrato de token](/pt-br/crypto/token-contract-verification/)

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

## Fontes

- [EIP-1014: Skinny CREATE2](https://eips.ethereum.org/EIPS/eip-1014) - Ethereum Improvement Proposals (acessado em: 2026-08-13)
- [EIP-684: Revert creation in case of collision](https://eips.ethereum.org/EIPS/eip-684) - Ethereum Improvement Proposals (acessado em: 2026-08-13)
- [Salted contract creations / CREATE2](https://docs.soliditylang.org/en/latest/control-structures.html#salted-contract-creations-create2) - Solidity (acessado em: 2026-08-13)
- [ERC-1167: Minimal Proxy Contract](https://eips.ethereum.org/EIPS/eip-1167) - Ethereum Improvement Proposals (acessado em: 2026-08-13)
- [ERC-2470: Singleton Factory](https://eips.ethereum.org/EIPS/eip-2470) - Ethereum Improvement Proposals (acessado em: 2026-08-13)
- [Create2](https://docs.openzeppelin.com/contracts/5.x/api/utils#Create2) - OpenZeppelin (acessado em: 2026-08-13)
- [EIP-155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155) - Ethereum Improvement Proposals (acessado em: 2026-08-13)
- [Contract Metadata](https://docs.soliditylang.org/en/latest/metadata.html) - Solidity (acessado em: 2026-08-13)

Source: https://wiki.fcontext.com/pt-br/crypto/create2-address-verification/index.mdx