EVM

CREATE2

CREATE2 is an EVM opcode that deploys contracts to deterministic addresses based on the deployer, salt, and init-code hash.

CREATE2 lets a contract address be known before the contract is deployed.

CREATE2 Explained in Detail

CREATE2 deploys a contract to an address computed from four values: a fixed prefix, the deployer address, a 32-byte salt, and the hash of the contract's init code.

This lets protocols know an address before deployment. It is useful for factories, minimal proxies, counterfactual wallets, and systems that need to approve or reference a contract before it exists.

Smart contract example

The address depends on the salt and init code:

function deploy(bytes32 salt, bytes memory bytecode) external returns (address addr) {
    assembly {
        addr := create2(0, add(bytecode, 0x20), mload(bytecode), salt)
    }
    require(addr != address(0), "deploy failed");
}

Constructor arguments are part of init code, so changing them changes the resulting address.

CREATE2 in Auditing

CREATE2 lets protocols trust an address before code exists there, so auditors must verify who can deploy that code and whether the bytecode is fixed.

It is especially important around factories, account abstraction wallets, clones, and systems that send funds to an address before code exists.

Red flags in code

  • Protocol trusts a not-yet-deployed address without verifying expected bytecode.

  • Salt is predictable when the protocol assumes the deployer, owner, or first initializer cannot be front-run.

  • Address calculation omits constructor arguments or uses the wrong deployer.

  • Factory lets untrusted users deploy contracts at addresses that other flows trust.

  • Comments assume selfdestruct allows redeployment at the same address, even though modern Ethereum only removes code in limited same-transaction cases.

How to test or review it

  • Recompute expected addresses from deployer, salt, and init-code hash.

  • Test salt collisions and repeated deployment attempts.

  • Verify constructor arguments are included in address prediction.

  • Check whether funds can be sent to a future address and later captured by unexpected code.

  • Review factories for authorization, bytecode allowlists, initializer arguments, and emitted deployment events.

Sources