---
title: "Cómo verificar una dirección de contrato CREATE2"
description: "CREATE2 predice una dirección a partir del implementador, el salt y el hash del código de inicialización, pero la verificación aún exige evidencia de fábrica, bytecode, despliegue, proxy y control específica de la cadena."
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.

# Cómo verificar una dirección de contrato CREATE2

> Solo con fines educativos; no constituye asesoramiento de inversión ni de seguridad. Una dirección predicha, una cuenta vacía, un checksum o una etiqueta de fábrica no prueban despliegue, código, control, propiedad ni seguridad.

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

## Respuesta directa

CREATE2 predice la dirección creada por un contrato implementador específico a partir de un `32-byte salt` y del hash de su `init_code` exacto. La fórmula del protocolo es `address = keccak256(0xff || deployer(20 bytes) || salt(32 bytes) || keccak256(init_code))[12:]`: calcula el hash de un `85-byte preimage` y conserva los últimos `20 bytes`. El implementador es la fábrica que ejecuta CREATE2, no necesariamente la cartera que llamó a la fábrica.

`init_code` es el bytecode de creación más los argumentos del constructor codificados con ABI; se ejecuta una vez y produce el bytecode de ejecución. La versión del compilador, la optimización, las bibliotecas enlazadas, los metadatos, los argumentos del constructor o el punto de entrada de la fábrica pueden cambiar el hash. El código de ejecución es una salida, no la entrada de CREATE2. Una misma dirección solo es comparable con el mismo implementador, salt, código de inicialización, reglas EVM y estado de la cadena.

Una dirección contrafactual puede recibir fondos antes de que exista código, pero aún no tiene lógica de control verificada. La predicción no demuestra despliegue, propiedad, autorización, finalidad ni seguridad. Verifica el bytecode y calldata de la fábrica, el recibo y los eventos, `eth_getCode`, nonce, almacenamiento, saldo, implementación del proxy, inicializador y propietario en la cadena y bloque previstos.

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

## Cómo funciona

Fija la cadena o dominio, las reglas de fork, RPC y bloque, la dirección de la fábrica y el hash de runtime, el salt bruto, los bytes exactos de init, la codificación del constructor, el compilador y las bibliotecas enlazadas. Recalcula `keccak256(init_code)` y el `85-byte preimage`; normaliza el relleno ABI, el endianess, el checksum y la extracción de los últimos 20 bytes.

Después decodifica la llamada y el valor enviados a la fábrica. Confirma que la fábrica, el punto de entrada, el dominio del salt, el constructor, el propietario y el inicializador previstos están vinculados. Para un proxy mínimo, hashea el bytecode de creación del clon que contiene la dirección de implementación, no el runtime de la implementación. Para un proxy, verifica por separado la implementación, el administrador, los slots de almacenamiento y la política de actualización.

EIP-684 hace que la creación revierta cuando el nonce de destino no es cero o el código no está vacío. Un constructor fallido tampoco deja un despliegue válido. Las suposiciones sobre `SELFDESTRUCT` y el redespliegue posterior dependen de las reglas del fork; nunca confíes en la antigua afirmación de que el código puede reemplazarse siempre a voluntad.

La evidencia del despliegue tiene capas: inclusión y estado de la transacción, eventos emitidos, código y nonce, almacenamiento y saldos, y finalmente un estado seguro o finalizado. Una respuesta RPC exitosa o un checksum predicho no sustituye la verificación del recibo y del estado. Copias de la misma dirección en distintas cadenas pueden tener código, propietarios, almacenamiento y activos diferentes.

Usa este flujo:

1. Fija cadena, fork, RPC y bloque; dirección de fábrica o implementador y hash de runtime; bytes del salt; código init, argumentos del constructor, compilador y bibliotecas enlazadas.
2. Calcula el hash del código init y el preimagen CREATE2 exacto, comprobando anchos, relleno, `0xff`, los últimos 20 bytes y el checksum.
3. Decodifica calldata y valor de la fábrica; compara dirección predicha, propietario, inicializador, destino del proxy y permisos previstos.
4. Verifica recibo, estado, eventos, `eth_getCode`, nonce, saldo y almacenamiento en la cadena correcta; registra estados no desplegado y de colisión.
5. Inspecciona fábrica, proxy, implementación, administrador, inicializador, actualización y supuestos de Singleton Factory, incluidos los destinos ERC-1167.
6. Prueba fallo del constructor, colisión por nonce/código, redespliegue sensible al fork, fábricas anidadas y supuestos de dominio de cadena o replay.
7. Antes de financiar o firmar, reconcilia importes humanos y brutos; después del despliegue monitoriza hash de código, propietario, implementación, roles, eventos y finalidad.

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

## Ejemplos

- **Vector EIP-1014:** implementador `0x0000000000000000000000000000000000000000`, salt cero, init `0x00` produce `0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38`.
- **Vinculación del constructor:** con implementador y salt fijos, cambiar un argumento del constructor codificado con ABI cambia `keccak256(init_code)` y, por tanto, la dirección predicha; hashear el runtime verificaría el objeto equivocado.
- **Colisión:** si el nonce de destino es mayor que `0` o su código no está vacío, CREATE2 debe revertir conforme a EIP-684. Una dirección financiada con código vacío y nonce cero solo es contrafactual y sigue sin estar verificada.
- **Proxy mínimo:** la dirección de un clon ERC-1167 hashea el bytecode de creación del clon que contiene la dirección de implementación. Hashear el runtime de la implementación produce una predicción distinta.

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

## Riesgos

- Se usa una fábrica o implementador equivocado.
- El ancho, relleno, endianess o dominio del salt es incorrecto.
- Se confunde el código init con el bytecode de ejecución.
- Se omiten o reordenan los argumentos del constructor.
- Difieren el punto de entrada, valor o calldata de la fábrica.
- El proxy o destino delegatecall no es la implementación prevista.
- Difieren la cadena, el fork o el dominio EVM.
- El nonce existente causa una colisión.
- El código existente causa una colisión.
- Se usan suposiciones obsoletas sobre redespliegue tras SELFDESTRUCT.
- CREATE2 anidado cambia el implementador efectivo.
- Se mezclan las fórmulas CREATE y CREATE2.
- No se verifica el destino de implementación ERC-1167.
- No se verifican la dirección o supuestos de despliegue de Singleton Factory.
- Una actualización o administrador de implementación cambia el comportamiento.
- Difieren el compilador, metadatos, biblioteca o artefacto fuente.
- Se confunden recibo, mempool, fallo y estados finalizados.
- Un checksum o envenenamiento de la interfaz oculta una dirección equivocada.
- Los fondos prefijados no tienen prueba de propiedad de la dirección contrafactual.
- Son erróneos los supuestos sobre EIP-7702, replay, gas, denegación de servicio o monitorización obsoleta.

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

## Errores comunes

- **«Una dirección vacía es segura o propia».** Puede no tener código ni controlador verificado.
- **«El salt por sí solo determina la dirección».** El implementador y el hash del código init también son vinculantes.
- **«CREATE2 hashea el bytecode de ejecución».** Hashea el código de creación, incluidos los argumentos del constructor.
- **«La misma dirección en dos cadenas implica el mismo código y control».** Hay que comprobar por separado el estado y despliegue de cada cadena.
- **«Una predicción correcta prueba despliegue y seguridad».** Solo el recibo, el código, el estado, los permisos y la finalidad establecen qué existe.

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

## Temas relacionados

- [Contrato proxy](/es/crypto/proxy-contract/)
- [Contrato inteligente](/es/crypto/smart-contract/)
- [Verificación de la dirección del contrato de token](/es/crypto/token-contract-verification/)

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

## Fuentes

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

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