CREATE derives an Ethereum contract address from the creator's address and nonce. CREATE2 derives it from the creator's address, a 32-byte salt and the hash of initialization code. Both can be calculated before deployment. A matching prediction establishes the address calculation; deployment, runtime code, initialization and authority require separate checks.
CREATE and CREATE2 use different inputs
CREATE is predictable when you know the creator and the nonce the creation will use. CREATE2 removes that nonce dependency, allowing a fixed deployment recipe to retain its address while the creator performs other creations. Ethereum's account documentation describes these two input sets. Ethereum contract addresses.
For CREATE, encode the creator address and nonce as an RLP list, hash that encoding with Keccak-256, then take the final 20 bytes. RLP is a structured byte encoding; joining a printed address and decimal nonce as text gives different input. EIP-1014's comparison with CREATE.
For CREATE2, join the single byte 0xff, the 20-byte creator address, the 32-byte salt and the 32-byte Keccak-256 hash of initialization code. Hash those joined bytes and take the final 20 bytes. The outer input is always 1 + 20 + 32 + 32 = 85 bytes, regardless of the initialization program's length. The 0x prefix marks hexadecimal notation; it is not extra text to include in the hash. EIP-1014 address definition.
| Input or change | CREATE | CREATE2 |
|---|---|---|
| Creator address | Part of the calculation | Part of the calculation |
| Creator nonce | Part of the calculation | Excluded |
| Salt | No salt input | Exactly 32 bytes |
| Initialization-code hash | Excluded from address derivation | Part of the calculation |
| Other creations advance the creator's nonce | Recalculate for the new nonce | Fixed recipe keeps its calculated address |
A factory is a contract that creates other contracts. Its CREATE deployment plan needs the intended creation nonce; its CREATE2 plan needs the exact salt and initialization bytes. Either plan needs evidence that execution succeeded.
Identify the creator in the execution route
Suppose a wallet sends a transaction to factory F, and F executes CREATE2. The address input is F, rather than the wallet that paid for the transaction. Do not substitute the transaction sender, a website operator or a contract owner for the actual creator. The ethers address helpers distinguish the creating account and its nonce from the other deployment inputs.
Delegated execution adds a reason to inspect the route. If F delegates to library L and L's code executes CREATE2 in F's context, use F's address. Solidity 0.8.30 documents that DELEGATECALL takes code from the target while preserving the calling contract's address and storage context. Solidity delegated execution. The CALL versus DELEGATECALL comparison explains how to follow that context through a call path.
For a factory's CREATE operation, obtain the factory's own account nonce. The number of transactions your wallet has sent to it is a different quantity. Retain the nonce at the relevant state snapshot and account for creations that occur before the planned instruction.
A checked factory example
Consider a hypothetical factory F whose full address is 0x1111111111111111111111111111111111111111. All results below are local educational calculations. Assume F's next creation uses nonce 7, with sufficient gas and no destination collision.
Use initialization bytes 0x60016000f3. This five-byte program returns one byte from fresh, zeroed memory: runtime code 0x00, the STOP instruction. It is deliberately minimal so the two kinds of code stay visible.
CREATE with nonce 7 gives 0x34E0765525c4d4D837Dc20bcb458EdD206120e59.
CREATE with nonce 8 gives 0x43CeE6586B589FE6F81637bf323121087f54FEF0.
For CREATE2, encode integer 7 as a 32-byte salt: 31 zero bytes followed by byte 07. This is different from hashing the text character "7" to obtain a salt. With F and the five-byte initialization program, the result is 0x6fF5351bA5f6381F67110A4b0366feEe45c9505f.
The calculations were checked by assembling the hash inputs directly and comparing the results with the address helper in viem 2.57.0. The following rows are alternative calculations from the assumed starting snapshot; they are not repeated deployments to an occupied address.
| Alternative input | CREATE consequence | CREATE2 consequence |
|---|---|---|
| Nonce changes from 7 to 8 | Address changes to the nonce-8 result | Nonce change leaves the stated salt-7 calculation unchanged |
| Salt changes from integer 7 to 8 | No salt input to change | Address changes |
Append one unused 00 byte to initialization code | Same creator and nonce give the same address | Initialization hash and resulting address change |
That appended byte is after RETURN, so both initialization programs still return the same runtime byte, 0x00. CREATE2 commits to the initialization bytes, not simply to the runtime eventually returned. Conversely, matching runtime code does not establish that two deployments used the same creation recipe.
Now make one event sequential: F successfully creates another contract first, advancing its nonce from 7 to 8. A later CREATE must use the nonce-8 prediction. The CREATE2 recipe still calculates the same salt-7 address, but its ability to deploy there depends on the state when it executes.
Preserve initialization bytes, then inspect what they produce
Initialization code runs during creation and produces the runtime code stored at the new account. Hashing the runtime returned by an explorer is therefore the wrong substitution for a CREATE2 initialization-code hash. EIP-1014 initialization-code distinction.
For Solidity 0.8.30's documented salted-creation pattern, the hash input includes creation bytecode followed by encoded constructor arguments. A changed constructor recipient or owner can therefore change the prediction even when the contract's source name stays the same. Solidity salted-creation example.
Keep the build recipe with those bytes: compiler version, settings, linked libraries, source inputs and constructor encoding. Solidity's metadata documentation explains how to reproduce a build and why metadata changes may affect bytecode. A source filename or repository label cannot reconstruct the deployment artifact. Solidity 0.8.30 build metadata.
Even exact initialization bytes do not describe every resulting state value. A constructor can read external state, and Solidity's documentation notes that such reads can affect deployed code. Record relevant dependencies and inspect the actual result. If creation deploys a proxy, the address calculation also leaves its implementation and upgrade authority to be reviewed. The upgradeable-contract admin worksheet follows those controls after deployment.
A predicted address is not a successful creation
A local hash calculation does not submit a transaction or reserve an address. Under Ethereum's collision rule, creation fails if the destination already has a nonzero nonce or nonzero code length. A balance alone is not the collision condition. Checking only that an explorer shows no code leaves the nonce check unfinished. EIP-684 collision rule.
Ethereum's account-creation rules also set a newly created contract's nonce to one before initialization executes. A contract that returns empty runtime code can therefore still block another creation through its nonce. Empty code is neither proof of an untouched destination nor proof of a usable application. EIP-161 created-account nonce.
Creation can fail for other reasons, including a constructor exception or insufficient resources. A correct formula cannot make that execution succeed. Solidity documents creation exceptions separately from the salted address calculation. Solidity creation failures.
Treat old destroy-and-redeploy explanations cautiously. Under Ethereum's EIP-6780 rules, SELFDESTRUCT outside the transaction that created the contract does not delete its code or storage. A same-transaction exception remains. A plan to remove an established contract today and replace it tomorrow cannot assume the historical deletion behavior. Other EVM chains require their own fork-rule check. EIP-6780 SELFDESTRUCT rules.
That exception still does not permit destroying and recreating a contract within one transaction. Its nonce prevents the second creation, as EIP-1014's collision discussion explains. Keep deletion at the transaction boundary separate from the address formula.
Verify the address, then the deployed contract
Use one explicit block number for related state reads and keep its block hash. Ethereum JSON-RPC exposes eth_getCode for code and eth_getTransactionCount for account nonce, with a block parameter. A saved prediction and a later state read answer different questions, so date both. Ethereum state-query methods.
| Record | Evidence to retain | What the evidence establishes |
|---|---|---|
| Network and snapshot | Chain ID, block number and hash | Which state was inspected |
| Creator route | Full address and actual creation instruction | Which account supplies the address input |
| CREATE recipe | Creator nonce used by that instruction | Reproducible nonce-based prediction |
| CREATE2 recipe | Exact salt, initialization bytes and their hash | Reproducible salted prediction |
| Destination before creation | Code and account nonce at the checked block | Whether the observed collision condition blocks creation |
| Creation outcome | Included transaction and creation execution result | Whether this creation completed |
| Deployed application | Runtime bytes, initialization state and controllers | What exists and who can affect its behavior |
For creation inside a factory transaction, inspect the creation result itself. Solidity permits handling a creation exception with try/catch, so an outer transaction can complete despite an inner creation failure. Reconcile the expected address with execution evidence and the code present afterward. Solidity 0.8.30 exception handling.
Preserve the complete address through this process. A correct calculation does not authenticate the source that supplied its inputs, and matching a shortened prefix and suffix can miss a substituted address. Use the address-poisoning checklist when carrying the verified result into a transfer or approval.
A token allowance is another separate check. Predicting a future spender does not explain what authority an approval grants it. The access list versus token allowance guide distinguishes transaction access preparation from permission to spend tokens.
Finally, record the chain even when the numeric address matches elsewhere. Chain ID is absent from both address recipes, so matching inputs can produce the same address on different chains. That arithmetic does not establish matching factory code, fork rules, external state, deployed runtime or initialization. Complete the deployment record separately for each network before relying on its contract.