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.
Keep learning this topic
SELFDESTRUCT (Solidity/EVM)
selfdestruct is an EVM operation that can force-send Ether and historically removed contract code and storage under older semantics.
Calldata
Calldata is the read-only input data sent to a contract call, usually containing the function selector and ABI-encoded arguments.
Storage Slot
A storage slot is a 32-byte indexed location in EVM contract storage used to hold state variables and derived storage data.
Self Destruct Attacks
See how this vulnerability appears in real smart contract audits.
Access Control Attacks
Access control attacks in Solidity: broken authorization patterns, privilege escalation paths, and secure role and ownership design.
Smart Contract Audit Checklist
Use this SCH tool to turn the concept into practical audit work.
Practice this in real audit scenarios
Definitions help, but auditors need reps. SCH turns concepts like CREATE2 into exploit labs, code review habits, and report-writing practice.
Start the free trial or see the full smart contract auditing course.