The CREATE2 address formula itself is just one line: keccak256(0xff ++ deployer ++ salt ++ keccak256(init_code))[12:]. But predictions before deployment often go wrong. The reason is almost never the formula itself, but two inputs: who the deployer actually is, and what the init_code actually is. If either one is wrong, the predicted address will not match the actual deployed address.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
What Each Item in the Formula Means
According to EIP-1014, the four parts need to be understood word by word.
0xff is a fixed byte. Its purpose is to make sure CREATE2 addresses can never collide with traditional CREATE addresses (keccak256(rlp([sender, nonce]))).
deployer is the address that executes the CREATE2 opcode, fixed at 20 bytes. This is the easiest item to get wrong. If you deploy through a factory contract, the deployer is the factory contract address, not your personal EOA wallet address. If you use the default CREATE2 deployer in a Foundry script, it is 0x4e59b44847b379578588920cA78FbF26c0B4956C. First confirm which address actually called CREATE2 in your transaction, then fill in this field.
salt is a 32-byte value you choose. It has no format requirement, but your choice affects the address and also affects security.
keccak256(init_code) is the hash of the initialization code, not the hash of the runtime bytecode. init_code is the code that "produces the runtime bytecode after execution." In Solidity, it usually includes constructor logic and constructor arguments. Constructor arguments must be appended to init_code before hashing. If you hash only type(MyContract).creationCode and leave out the arguments, the calculated address will definitely be wrong.
Finally, the formula takes the last 20 bytes of the hash result (that is, [12:]). This is the contract address.
Use Tools Instead of Calculating by Hand
Manually assembling bytes and then calculating keccak256 is error-prone. For everyday verification, tools are more reliable.
Foundry's cast provides a direct calculation command. If you have the full content of init_code, including constructor arguments, you can use cast create2 --salt --init-code to get the address. If you already have the hash of init_code, you can use cast compute-address and pass --init-code-hash. In Solidity tests, Foundry's cheatcode vm.computeCreate2Address(salt, initCodeHash, deployer) can directly assert in the test whether the predicted address matches the actual deployed address. Note that the two-parameter overload uses the default deployer. If you directly use new Contract{salt: salt}() in a test contract, the deployer is the test contract itself, so you need the three-parameter version.
ethers.js provides ethers.getCreate2Address(deployer, salt, initCodeHash) to do the same calculation. Before calling it, you need to encode the constructor arguments yourself, append them to the creationCode, and then take the keccak256 hash.
Prediction Does Not Match Reality? Check These Four Things First
First, the deployer is wrong. You used your own EOA address, but the actual deployment went through a factory contract. Or in local testing the deployer was the test contract address, but after going on-chain it changed to another factory. Find the actual to address of the transaction or the contract address that triggered CREATE2, replace the deployer, and recalculate.
Second, init_code is missing or has extra decoded arguments. The types and values of constructor arguments must exactly match the actual deployment. abi.encode and abi.encodePacked can produce different results for certain types. Use the encoding method you actually passed in your deployment script or contract call.
Third, Solidity metadata changed. This is a subtle but critical issue. Solidity appends CBOR-encoded metadata to the end of the bytecode by default, including source hash, compiler version, file path, and other information. Even if the contract logic does not change, a change in repository path or dependency version may cause the metadata to change, which changes keccak256(init_code) and the CREATE2 address. If you need deterministic deployment across environments or chains, set bytecode_hash = "none" and cbor_metadata = false in the Foundry config to remove this metadata and make the bytecode stable. The trade-off is that contract verification on block explorers may show as "partial match" instead of "full match."
Fourth, the salt type or encoding is inconsistent. If you use bytes32 salt = keccak256("my-salt") in Solidity, you must do the same keccak256 off-chain, not just convert the string to bytes32 directly. Generate the salt the same way on both sides.
Verification: Compare the Actual Address After Deployment
After the deployment transaction is confirmed, get the actual created contract address from the transaction receipt or block explorer, and compare it byte by byte with your predicted address. If they match, the formula and the inputs are correct. If they do not match, check the four branches above one by one.
There is one edge case to know: CREATE2 allows address collisions, but the behavior in a collision is defined by EIP-684: if the target address already has a non-zero nonce or non-empty code, the creation fails immediately, gas is consumed, and the original state remains unchanged. This means you cannot use CREATE2 to overwrite an existing contract. If the predicted address already has something on it, the deployment will revert instead of replacing it.
Also, if you are using a public CREATE2 factory, confirm that the factory address on your target chain is the same as the deployer you used in the calculation. The same factory can theoretically have the same address on different chains, such as 0x4e59... promoted by EIP-7997, but not all chains have it pre-deployed. Before deployment, check on the target chain's block explorer whether the factory contract exists.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
References
- Ethereum Improvement Proposals·EIP-1014: Skinny CREATE2, no update date indicated; accessed: 2026-10-20.
- Foundry·Deterministic Deployments with CREATE2, no update date indicated; accessed: 2026-10-20.
- Foundry·computeCreate2Address Cheatcode Reference, no update date indicated; accessed: 2026-10-20.
- Foundry·cast compute-address Reference, no update date indicated; accessed: 2026-10-20.
- GitHub·Non-deterministic CREATE2 deployments due to Solidity bytecode metadata (ithacaxyz/account #348), no update date indicated; accessed: 2026-10-20.
- Ethereum Improvement Proposals·EIP-7997: Deterministic Factory Contract, no update date indicated; accessed: 2026-10-20.
- Foresight News·Smart Contract Security Audit Basics — Deploy Different Contracts to the Same Address, no update date indicated; accessed: 2026-10-20.
