EIPs

EIP-1014 — CREATE2

eips.ethereum.org/EIPS/eip-1014

CREATE2 derives a contract’s address deterministically from (deployer, salt, init_code) instead of from (deployer, nonce). The address is knowable before deployment, which is what makes counterfactual systems (EIP-6492, smart-account factories, deterministic CREATE patterns) work.

import {
  get_create2_address,
  get_contract_address,
  deploy_contract,
} from "@ethernauta/eip/1014";

const address = get_create2_address({
  deployer: factory_address,
  salt: salt_bytes32,
  init_code: contract_bytecode,
});

Surface

ExportTypePurpose
get_create2_address(args) => AddressCREATE2 address derivation.
get_contract_address(args) => AddressPick CREATE or CREATE2 by argument shape.
deploy_contractSignable<Hash32>Submit a deployment via eth_sendTransaction.
Valibot schemas for both above

CREATE vs CREATE2

get_contract_address accepts either:

get_contract_address({ deployer, nonce });               // → CREATE
get_contract_address({ deployer, salt, init_code });    // → CREATE2

The discriminant is which fields are present. Useful when a deployment script handles both legacy CREATE and CREATE2 sites.

Where this gets used

  • Smart accounts. Factories compute the user’s account address before deployment so the dapp can route funds there.
  • EIP-6492 counterfactual signatures. The wrapped signature carries the factory + salt + init_code; the verifier recomputes the address and falls through to the EIP-1271 logic that the deployed account would have.
  • Deterministic deployments. Same (deployer, salt, init_code) everywhere → same address on every chain (assuming same chain ID semantics).

See also

  • EIP-6492 — counterfactual signatures (the primary consumer).
  • EIP-4337 — smart-account flows.