new<\/code> keyword with a salt<\/code> option. The salt is a value you pick, and changing it changes the resulting address. That is what gives you control over where the contract lands.<\/p>\n\n\n\nThis guide covers what CREATE2 is, how the address is derived, how to predict and deploy an address in Solidity, and what it takes to get the same address across EVM networks. It also covers the limits worth knowing before you build on it.<\/p>\n\n\n
What Is CREATE2, and How Is It Different From CREATE?<\/h2>\n\n\n![\"\"](\"https:\/\/nownodes.io\/blog\/wp-content\/uploads\/2026\/10\/image-117-1024x535.png\")
<\/figure>\n\n\n\nEvery contract on an EVM chain has an address, and that address is decided at deployment. The real question is what the address is derived from.<\/p>\n\n\n\n
The original CREATE<\/code> opcode derives the address from two things: the deployer’s address and its nonce, a counter of how many contracts or transactions that account has sent. Because the nonce increases with every deployment, you cannot reliably predict a CREATE<\/code> address in advance, and you cannot reproduce it later.<\/p>\n\n\n\nEIP-1014<\/a> introduced CREATE2 in the Constantinople upgrade in early 2019. It swaps the nonce for a salt and a hash of the contract’s init code. None of those inputs depend on account history, so the address is deterministic: the same inputs always produce the same address, on any EVM chain.<\/p>\n\n\n\nHere’s the practical difference. With CREATE<\/code>, the address is a side effect of when<\/em> you deploy. With CREATE2, the address is something you decide up front.<\/p>\n\n\nHow Does CREATE2 Derive the Address?<\/h2>\n\n\n
CREATE2 runs the address through a single hash. The formula from EIP-1014 is:<\/p>\n\n\n\n
address = keccak256(0xff ++ deployer ++ salt ++ keccak256(init_code))[12:]<\/code><\/pre>\n\n\n\nkeccak256<\/code> is the hash function the EVM uses, ++<\/code> means the bytes are joined together, and [12:]<\/code> means the address is the last 20 bytes of the 32-byte hash. The full input to the hash is always exactly 85 bytes.<\/p>\n\n\nThe four inputs that decide the address<\/h3>\n\n\n\n0xff<\/code><\/strong> \u2014 a single constant byte. It never changes, and its only job is to keep CREATE2 addresses from colliding with regular CREATE<\/code> addresses.<\/li>\n\n\n\ndeployer<\/code><\/strong> \u2014 the 20-byte address of the account or contract running CREATE2. Deploy from a different address and you get a different result.<\/li>\n\n\n\nsalt<\/code><\/strong> \u2014 a 32-byte value you choose. This is the knob you turn to produce the address you want.<\/li>\n\n\n\nkeccak256(init_code)<\/code><\/strong> \u2014 the hash of the contract’s init code, meaning the creation bytecode plus any constructor arguments. Change the code or the arguments and the address changes.<\/li>\n<\/ul>\n\n\n\nTwo of these are fixed by context (the constant byte and the deployer) and two are under your control (the salt and the code). That is the entire basis for predictable addresses: fix the code, pick a salt, and the address falls out of the formula.<\/p>\n\n\n
Why Predictable Contract Addresses Are Useful<\/h2>\n\n\n
Knowing an address before deployment solves problems that are awkward with CREATE.<\/p>\n\n\n\n
You can reference a contract before it exists. A protocol can hard-code the address of a contract it will deploy later, or two contracts can be told about each other without a chicken-and-egg deployment order.<\/p>\n\n\n\n
You can fund or interact with an address ahead of time. Some wallet designs send assets to a smart-account address that is only deployed on first use. The address is derived with CREATE2, so it is valid and fundable before any contract code is there. These “counterfactual” designs underpin a lot of account-abstraction work.<\/p>\n\n\n\n
In practice, the heavy users are smart-account and wallet teams, DeFi protocols that deploy per-user or per-pair contracts (Uniswap-style pair contracts are the classic example), and anyone shipping the same contracts to more than one network.<\/p>\n\n\n
How to Predict and Deploy a Contract Address in Solidity<\/h2>\n\n\n
You usually do two things: compute the address, then deploy to it. Solidity’s CREATE2 support handles both.<\/p>\n\n\n
Compute the address before you deploy<\/h3>\n\n\n
You can compute the address off-chain or on-chain. On-chain, a helper reproduces the EIP-1014 formula directly:<\/p>\n\n\n\n
solidity<\/p>\n\n\n\n
function predict(bytes32 salt) public view returns (address) {\n \/\/ Target is the contract you intend to deploy\n bytes32 initCodeHash = keccak256(type(Target).creationCode);\n bytes32 h = keccak256(\n abi.encodePacked(bytes1(0xff), address(this), salt, initCodeHash)\n );\n return address(uint160(uint256(h)));\n}<\/code><\/pre>\n\n\n\nIf Target<\/code>‘s constructor takes arguments, append them to the creation code before hashing, because they are part of the init code. OpenZeppelin ships this logic as a reusable Create2<\/code> library with computeAddress<\/code> and deploy<\/code> functions, documented in its contract utilities<\/a>. Off-chain, libraries such as ethers.js (getCreate2Address<\/code>) and viem (getCreate2Address<\/code>) run the same calculation in JavaScript.<\/p>\n\n\nDeploy with the salt option<\/h3>\n\n\n
To deploy, add a salt<\/code> option to the new<\/code> expression. This compiles down to the CREATE2 opcode:<\/p>\n\n\n\nsolidity<\/p>\n\n\n\n
\/\/ SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\n\ncontract Factory {\n event Deployed(address addr, bytes32 salt);\n\n function deploy(bytes32 salt) external returns (address) {\n Target t = new Target{salt: salt}(); \/\/ Target is any contract\n emit Deployed(address(t), salt);\n return address(t);\n }\n}<\/code><\/pre>\n\n\n\nThe salt option has been part of Solidity for years and behaves the same in the current 0.8.x releases<\/a> \u2014 0.8.37 at the time of writing. If a contract already exists at the computed address, the deployment reverts rather than overwriting it.<\/p>\n\n\nVerify the result over RPC<\/h3>\n\n\n
Once you deploy, confirm the contract landed where you predicted. The quickest check is the eth_getCode<\/code> JSON-RPC method against the predicted address: it returns 0x<\/code> when nothing is deployed and the contract’s runtime bytecode once it is.<\/p>\n\n\n\nbash<\/p>\n\n\n\n
curl https:\/\/eth.nownodes.io\/YOUR_API_KEY \\\n -X POST -H \"Content-Type: application\/json\" \\\n -d '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getCode\",\"params\":[\"0xYourPredictedAddress\",\"latest\"],\"id\":1}'<\/code><\/pre>\n\n\n\nTo broadcast the deployment and run that check, you need an endpoint for each chain you are targeting. Our RPC endpoints<\/a> cover Ethereum, BNB Smart Chain, Polygon, Arbitrum, and other EVM networks, so you can point the same script at one chain after another without running the underlying infrastructure yourself.<\/p>\n\n\nGetting the Same Address on Every EVM Chain<\/h2>\n\n\n
This is the part the title promises. Because a CREATE2 address depends only on the deployer, the salt, and the init code \u2014 and not on anything chain-specific \u2014 the same three inputs produce the same address on Ethereum, BNB Smart Chain, Polygon, and any other EVM network. Deploy with identical inputs on each chain and your contract lives at one address everywhere, which is far easier to document, integrate, and audit.<\/p>\n\n\n
What has to match across chains<\/h3>\n\n\n
Determinism is only as good as the inputs you keep identical. To land on the same address on every chain, all of these have to match, as Foundry’s guide<\/a> spells out:<\/p>\n\n\n\n\n- The same deployer<\/strong> \u2014 either the same externally owned account or the same factory contract on every chain.<\/li>\n\n\n\n
- The same salt.<\/strong><\/li>\n\n\n\n
- Identical bytecode<\/strong> \u2014 no values baked in that differ per chain. A
block.chainid<\/code> read in a constructor, or a chain-specific immutable, changes the init code and therefore the address.<\/li>\n\n\n\n- The same compiler settings<\/strong> \u2014 solc version, optimizer runs, and EVM version. A different compiler can emit different bytecode from the same source.<\/li>\n<\/ul>\n\n\n\n
A common way to guarantee the same deployer everywhere is a shared factory. Arachnid’s deterministic deployment proxy sits at 0x4e59b44847b379578588920ca78fbf26c0b4956c<\/code> on many chains and is Foundry’s default CREATE2 deployer. It is not on every network, though \u2014 check with cast code<\/code> against that address, and a 0x<\/code> result means it is not deployed there.<\/p>\n\n\nCREATE2 vs CREATE3<\/h3>\n\n\n
CREATE2 has one catch for cross-chain work: the init code is part of the address. If the bytecode differs by even a byte between chains \u2014 a different compiler, a tweaked constructor \u2014 the addresses diverge.<\/p>\n\n\n\n
CREATE3 is a deployment pattern built to remove that constraint. It combines CREATE2 with a small intermediate deployer so the final address depends only on the deployer and the salt, not on the contract’s bytecode. As 1inch’s write-up explains<\/a>, that lets teams deploy different or upgraded bytecode to the same address across chains. CREATE3 is a convention implemented by libraries such as Solady and factories like CreateX, not a native opcode, so it costs more gas and adds a dependency. For most cases where you control the bytecode, plain CREATE2 is simpler; CREATE3 earns its keep when keeping bytecode byte-identical across many chains is impractical.<\/p>\n\n\nLimits and Risks to Know<\/h2>\n\n\n![\"\"](\"https:\/\/nownodes.io\/blog\/wp-content\/uploads\/2026\/10\/image-118-1024x535.png\")
<\/figure>\n\n\n\nCREATE2 is useful, but a few things trip people up.<\/p>\n\n\n\n
Redeployment is mostly gone.<\/strong> The old trick of self-destructing a CREATE2 contract and deploying different code to the same address \u2014 the “metamorphic contract” pattern \u2014 stopped working after the Dencun upgrade (March 2024). EIP-6780<\/a> restricts SELFDESTRUCT<\/code> so it only fully removes a contract when it runs in the same transaction that created the contract. Outside that case the code stays put, so you can no longer swap a deployed contract’s code by destroying and redeploying it.<\/p>\n\n\n\nInit code has a size limit.<\/strong> Since the Shanghai upgrade, EIP-3860<\/a> caps init code at 49,152 bytes and charges extra gas per 32-byte word of it. Very large contracts deployed via CREATE2 can run into this ceiling.<\/p>\n\n\n\n