Deterministic Deployment (CREATE2)

What Is Deterministic Deployment (CREATE2)?

Deterministic Deployment (CREATE2) is an Ethereum Virtual Machine method that allows developers to calculate a smart contract’s address before the contract is deployed.

The method uses the EVM opcode

, which is identified by opcode value .

A contract deployed with CREATE2 receives an address derived from the deploying contract, a developer-selected salt, and a hash of the contract’s initialization code.

This differs from ordinary contract deployment, where the resulting address is normally based on the deployer’s address and nonce.

Because CREATE2 does not use the deployer’s changing deployment nonce, developers can predict the same address even when the factory has created other contracts in the meantime.

This property supports counterfactual smart accounts, predictable protocol components, cross-chain application infrastructure, state channels, and contracts that receive cryptocurrency before deployment.

The final EIP-1014 CREATE2 specification defines the opcode, address formula, gas treatment, collision behavior, and original counterfactual deployment motivation.

CREATE2 does not make a contract secure, permanent, decentralized, or identical across every blockchain automatically.

It only provides a deterministic method for deriving the deployment address from specified inputs.

Why Is CREATE2 Called Deterministic?

A process is deterministic when the same inputs always produce the same output.

For CREATE2, the relevant output is the smart contract address.

The relevant inputs are the CREATE2 deployer address, the 32-byte salt, and the hash of the initialization code.

Anyone who knows these inputs can calculate the future address without submitting a blockchain transaction.

The address does not depend on the time of deployment, the current block number, or the number of contracts previously created by the factory.

Changing any address-formula input produces a different predicted address.

The contract can therefore be planned, referenced, funded, or included in signed messages before its code exists onchain.

The CREATE2 Address Formula

The CREATE2 address is calculated using the following formula.

The value

is a one-byte prefix used to separate CREATE2 addresses from addresses created through the ordinary CREATE formula.

The

is the 20-byte address of the contract that directly executes the CREATE2 opcode.

The

is a 32-byte value supplied to the CREATE2 operation.

The

is the initialization code executed during contract creation.

The initialization code is hashed before being included in the final 85-byte CREATE2 hash input.

The last 20 bytes of the final Keccak-256 hash become the contract address.

The formula can be calculated locally without paying a network fee because no blockchain state must be changed to predict the result.

What Is the CREATE2 Deployer?

The CREATE2 deployer is the smart contract that directly calls the CREATE2 opcode.

It is often called a factory, deployer contract, deterministic deployment proxy, or singleton factory.

The externally owned account that sends a transaction to the factory is not automatically the address used in the CREATE2 formula.

The factory’s address is normally the relevant deployer address because the factory executes the opcode.

Using a different factory produces a different predicted contract address even when the salt and initialization code are identical.

This is one reason developers must verify the exact factory address rather than calculating a result from the wallet that submits the transaction.

A factory may allow anyone to deploy arbitrary initialization code, or it may restrict deployments to approved accounts and contract templates.

The factory’s permissions and implementation can affect whether the predicted contract is actually deployable.

What Is a CREATE2 Salt?

A CREATE2 salt is an arbitrary 32-byte value included in the deterministic address calculation.

The salt allows a factory to deploy multiple contracts from the same initialization code while assigning each contract a different address.

A salt can be derived from a user identifier, wallet address, account number, token identifier, application version, random value, or combination of several fields.

The salt does not need to be secret.

Anyone who knows the factory, salt, and initialization code can calculate the same address.

Developers should define a clear salt-encoding method because inconsistent encoding can produce unexpected addresses.

For example, the number

, a text string containing , and a 32-byte value ending in may be interpreted differently by software.

A project may hash structured data to create a fixed 32-byte salt and avoid ambiguous encoding.

What Is Initialization Code?

Initialization code, commonly shortened to init code, is temporary EVM code executed when a smart contract is created.

Its job is to perform constructor logic and return the runtime bytecode that will remain at the new address.

The initialization code itself is not normally stored as the contract’s permanent code.

The CREATE2 formula commits to the hash of this initialization code.

In Solidity, the complete initialization code generally includes the contract creation bytecode and ABI-encoded constructor arguments.

The current Solidity documentation for salted contract creation confirms that the address depends on the creation bytecode and constructor arguments.

Changing a constructor argument changes the initialization-code hash and therefore changes the predicted address.

Developers must use the exact compiler output and constructor encoding intended for deployment when calculating a CREATE2 address.

Initialization Code Versus Runtime Bytecode

Initialization code and runtime bytecode are related but different.

Initialization code runs once during deployment.

Runtime bytecode is the code stored at the contract address after deployment completes.

The CREATE2 address formula directly commits to the initialization-code hash rather than the final runtime-code hash.

This distinction creates an important security consideration.

A constructor can read external blockchain state and use that information to decide which runtime code or initial storage values to create.

The same initialization code can therefore produce different deployed behavior when it executes under different external conditions.

A developer seeking a strong behavioral commitment should avoid environment-dependent constructors or verify the resulting runtime code and storage after deployment.

Constructor Arguments and CREATE2

Constructor arguments form part of the initialization code used in Solidity deployments.

A contract constructed with an owner address of

will normally have a different CREATE2 address from the same contract constructed with an owner address of .

The same rule applies to token names, supply values, implementation addresses, validator lists, fee settings, and other constructor inputs.

Developers must encode constructor arguments in the same order and format expected by the contract’s ABI.

An address predictor that omits the constructor arguments will calculate the wrong result.

Initializer functions called after deployment do not affect the CREATE2 formula unless the initialization call is itself included in the constructor or factory process.

Separating deployment from initialization can create a takeover risk when another account can call an unprotected initializer first.

CREATE Versus CREATE2

CREATE and CREATE2 are EVM operations used to create smart contracts.

Ordinary CREATE derives the new address mainly from the creating account and its deployment nonce.

The nonce increases as the deployer creates additional contracts.

A developer predicting a CREATE address must therefore know the correct deployment sequence.

CREATE2 replaces the nonce-based address formula with one based on the factory address, salt, and initialization-code hash.

CREATE2 does not change the fundamental execution of constructor code or the storage of returned runtime bytecode.

It changes how the destination address is derived and adds a hashing cost for the initialization code.

Both operations fail when the target address violates the EVM’s contract-creation collision rules.

When Was CREATE2 Introduced?

CREATE2 was specified in EIP-1014 in 2018.

It was included in Ethereum’s Constantinople network upgrade.

The Constantinople upgrade specification lists EIP-1014 among the protocol changes included in the upgrade.

CREATE2 has since become an established part of the EVM and is supported by Solidity and widely used development tools.

EVM-compatible networks may support CREATE2 after activating the corresponding protocol behavior.

Developers should verify network compatibility instead of assuming that every blockchain using an EVM-like environment implements identical rules.

CREATE2 in Solidity

Solidity provides a high-level syntax for deploying contracts through CREATE2.

A factory can use the syntax

.

The Solidity compiler prepares the creation bytecode, encodes the constructor arguments, and generates the CREATE2 operation.

A payable constructor can also receive the blockchain’s native currency during deployment through the

option.

The factory should verify that deployment returned the expected nonzero address.

Developers may also call CREATE2 through inline assembly when they need direct control over initialization-code memory, length, salt, and endowment.

Inline assembly increases implementation risk and should be tested carefully.

A Simplified Solidity CREATE2 Example

In this example, the predicted child address depends on the factory address, salt, Child creation bytecode, and encoded

argument.

Changing the external caller without changing these inputs does not necessarily change the address.

Changing the

does change the address because the constructor argument forms part of the initialization code.

Predicting a CREATE2 Address

A developer can calculate a CREATE2 address in a smart contract, deployment script, wallet, or local application.

The calculation must use the exact factory address that will execute CREATE2.

It must also use the salt in its final 32-byte representation.

The initialization-code hash must include the exact creation bytecode and encoded constructor arguments.

The result should be compared with the address returned by the factory after deployment.

Deployment tooling should reject the process when the predicted address and actual address differ.

A wrong prediction commonly results from using runtime bytecode instead of creation bytecode, excluding constructor arguments, selecting the wrong factory, or encoding the salt incorrectly.

What Is Counterfactual Deployment?

Counterfactual deployment describes treating a future smart contract address as meaningful before code is deployed there.

The parties can calculate the address and agree on the contract’s expected initialization code in advance.

They may send assets to the address, include it in another contract, or create signed authorizations connected with it.

The contract is deployed only when execution becomes necessary.

This can avoid an immediate deployment transaction and reduce initial onboarding costs.

EIP-1014 originally emphasized counterfactual interactions for state-channel systems in which a contract might be needed only if participants enter a dispute.

Counterfactual deployment is now also important for smart contract wallets and account abstraction.

Counterfactual Smart Contract Accounts

A smart contract account can have a predictable CREATE2 address before the account contract is deployed.

The user can share that address and may receive cryptocurrency or tokens at it.

The first account operation can then deploy the wallet and perform an action in the same broader process.

This can remove the need for a user to complete a separate wallet-creation transaction before receiving assets.

The ERC-4337 account-abstraction specification supports creating a sender smart contract account from factory initialization data when the account does not yet exist.

CREATE2 is commonly used by account factories to ensure that the sender address can be calculated before deployment.

Not every account-abstraction design is required to use CREATE2 because newer authorization and account models may use different mechanisms.

Sending Cryptocurrency to an Undeployed Address

An undeployed CREATE2 address can receive the blockchain’s native cryptocurrency because an address does not need runtime code to hold a balance.

Fungible and non-fungible tokens can also be transferred to a predicted address when their contracts permit ordinary address transfers.

The assets remain associated with the address even though no contract code exists there yet.

They may become usable after the intended contract is deployed successfully.

This behavior can simplify wallet onboarding and counterfactual application design.

It also creates a serious risk because assets can become inaccessible if the intended factory, salt, or initialization code is wrong.

Users should verify that the deployment can actually occur before sending meaningful value to a counterfactual address.

Can an Empty CREATE2 Address Hold Funds?

Yes, an address with no code can have a native cryptocurrency balance and token balances.

A positive balance alone does not prevent CREATE2 deployment at the address.

The EVM collision rule focuses on whether the destination has nonzero nonce or nonempty code.

This design is necessary for counterfactual accounts that receive funds before deployment.

After deployment, the contract’s code and authorization rules determine how those assets can be used.

CREATE2 Collision Rules

A CREATE2 deployment fails when the destination address already has nonempty code or a nonzero nonce.

This prevents a factory from overwriting an existing contract at the same address.

The rule applies even when the new initialization code would otherwise calculate that address correctly.

A deployment also fails when the initialization code reverts, runs out of gas, returns invalid code, or violates another contract-creation rule.

Factories should handle a zero result from the CREATE2 opcode and return a useful error when possible.

A collision does not mean that the Keccak hash function has been cryptographically broken.

It normally means that the deterministic destination is already occupied under the EVM’s account rules.

Can Two Different Deployments Produce the Same CREATE2 Address?

Two deployment attempts produce the same calculated address when they use the same factory address, salt, and initialization-code hash.

Different initialization code could theoretically have the same hash, but finding a practical Keccak-256 collision is considered computationally infeasible under current security assumptions.

The use of only the final 20 address bytes means random address collisions are theoretically possible, as they are with other Ethereum addresses.

Producing a chosen collision remains impractical with current computing capabilities.

Developers should still avoid treating a visually similar address as proof that the underlying deployment inputs are correct.

Salt Reuse

A factory can reuse the same salt when the initialization code differs because the initialization-code hash will produce a different address.

The same factory cannot successfully deploy the same initialization code with the same salt twice while the original destination remains occupied.

A project may prohibit salt reuse at the application level to make deployment intent easier to track.

A public factory may allow anyone to submit a previously used salt because the full formula also includes the initialization-code hash.

Salt uniqueness by itself is not a complete security property.

The complete factory, salt, and initialization-code combination must be examined.

Front-Running a CREATE2 Deployment

A pending CREATE2 transaction may be visible before it is included in a block.

Another user may copy the factory call and attempt to deploy the contract first.

When a permissionless factory uses the same salt and identical initialization code, the copied deployment should create the same code commitment at the same predicted address.

The original transaction may then fail because the destination is already occupied.

This can still cause timing problems, wasted gas, or disrupted application workflows.

The risk becomes more serious when constructor behavior reads changing environmental information such as block data, transaction origin, external contract state, or caller-dependent factory parameters.

The current deterministic factory proposal recommends using well-known factories for fully deterministic contracts rather than deployments whose results depend on the execution environment.

Constructor Front-Running Risk

A CREATE2 address commits to initialization code but does not freeze all external state that the constructor may read.

An attacker who controls deployment timing may cause the constructor to observe a different price, block value, registry entry, or external contract state.

The resulting runtime code or initial storage can differ from what the original user expected.

A constructor should receive critical configuration through committed constructor arguments instead of reading mutable external state whenever practical.

Deployment scripts should verify runtime bytecode, ownership, storage, and emitted events after creation.

Unprotected Initializer Risk

Proxy contracts and minimal clones often use initializer functions instead of constructors.

The initializer sets ownership, permissions, implementation details, or other essential state after deployment.

A CREATE2 address can be predicted without automatically protecting that initializer.

If deployment and initialization occur in separate transactions, an attacker may call the initializer first.

The factory should initialize the contract atomically during the deployment transaction or enforce strict authorization.

A deterministic address does not compensate for an unprotected initialization design.

CREATE2 Factories

A CREATE2 factory is a reusable smart contract that receives a salt and initialization code and executes the CREATE2 opcode.

Using a factory allows externally owned accounts and other smart contracts to access deterministic deployment through a consistent interface.

A minimal factory may accept arbitrary code without requiring permission.

A specialized factory may deploy only approved account implementations or application modules.

Developers should inspect the factory’s runtime bytecode, deployment history, permissions, failure handling, and value-transfer behavior.

A malicious factory can alter inputs, restrict deployment, keep funds, or execute unexpected code.

Singleton Factories

A singleton factory is a deterministic factory intended to exist at the same address on multiple EVM networks.

A shared factory address helps developers derive the same child contract address on each supported network.

ERC-2470 proposed a permissionless CREATE2 singleton factory for deterministic deployments.

The proposal used a keyless deployment method so the factory could be created at a known address on compatible networks.

As of July 2026, ERC-2470 is marked Stagnant in the EIP repository, although the broader deterministic factory concept remains widely relevant.

A proposal’s repository status and a contract’s real-world deployment status are separate issues.

Multi-Chain Deterministic Deployment

CREATE2 can help deploy a contract at the same address on several EVM networks.

The same result requires the same CREATE2 factory address, salt, and initialization-code hash on each network.

Using the same application deployer wallet is not enough when the wallet calls different factory addresses.

Compiler metadata, library linking, constructor arguments, and contract source changes can alter the initialization-code hash.

The chain ID is not directly included in the basic CREATE2 formula.

However, a constructor or deployment tool may include chain-specific data that changes the initialization code or deployed state.

Developers should verify the deployed code separately on every network even when the addresses match.

Why Same-Address Multi-Chain Deployment Is Useful

Identical contract addresses reduce the number of addresses that wallets, interfaces, software libraries, and other contracts must store.

A developer can use one address constant across several supported networks.

Users are less likely to copy the contract address from the wrong network.

Smart contract accounts can also present one consistent address across multiple chains.

This improves usability but can create false confidence if one network contains different code or configuration at the same address.

The address should always be evaluated together with the chain identifier and verified bytecode.

Current Deterministic Factory Proposals

Deterministic factory infrastructure continues to develop as more EVM networks and rollups are created.

As of July 2026, EIP-7997 is in Review and proposes formally requiring a widely used deterministic factory at a specified address across EVM chains.

The proposal is not final and should not be treated as a universal guarantee for every network.

ERC-7955 remains a Draft proposal for permissionlessly bootstrapping a universal CREATE2 factory through EIP-7702 capabilities.

These proposals address the fact that CREATE2 alone does not solve the problem of placing the original factory at the same address everywhere.

Developers should check current proposal status and actual network state before relying on a universal factory.

CREATE2 and Account Abstraction

Account abstraction allows smart contract accounts to use programmable validation and execution rules.

A wallet may support multiple signers, passkeys, recovery guardians, spending limits, batched operations, and fee sponsorship.

CREATE2 allows the wallet factory to calculate the account address before deploying the wallet contract.

A user can receive funds at the address and deploy the account when the first operation is processed.

ERC-4337 can include factory data that creates an account when the sender does not yet exist.

The account’s counterfactual address must match the address produced by the factory call.

If the factory deploys code somewhere else, the account operation fails under the standard’s validation flow.

CREATE2 and Predeployment Signatures

A counterfactual contract account may need to sign an authentication message before it is deployed.

Ordinary contract-signature verification cannot call the account because no runtime code exists at the address.

ERC-6492 defines a wrapper format for verifying signatures made on behalf of predeployment contract accounts.

The verification process can simulate or perform the required factory deployment before checking the contract’s signature logic.

The standard recommends CREATE2 contracts because their addresses are predictable.

A signature from a counterfactual account should be verified through the applicable contract-signature standard rather than treated as an ordinary externally owned account signature.

CREATE2 and Token-Bound Accounts

A token-bound account is a smart contract account associated with a non-fungible token.

The account can hold cryptocurrency, tokens, NFTs, and other onchain assets.

ERC-6551 uses CREATE2 so token-bound account addresses can exist counterfactually before deployment.

This allows assets to be transferred to a token’s account before someone pays to deploy the account contract.

The account address depends on the registry, implementation, salt, blockchain identifier, token contract, and token identifier under the standard’s rules.

Ownership of the controlling NFT determines who can normally execute actions through the token-bound account.

CREATE2 and State Channels

State channels allow participants to perform repeated interactions offchain while using a blockchain contract to enforce the final result or resolve a dispute.

Participants may agree in advance on the code and address of a dispute contract.

CREATE2 allows them to calculate that address without deploying the contract immediately.

They can refer to the counterfactual contract throughout the offchain process.

The contract needs to be deployed only when enforcement becomes necessary.

This was one of the original use cases described by EIP-1014.

CREATE2 and Minimal Proxy Contracts

A minimal proxy is a small contract that delegates calls to an implementation contract.

A factory can combine minimal proxies with CREATE2 to create predictable account or application addresses.

The implementation address may form part of the proxy initialization code.

Changing the implementation address can therefore change the predicted proxy address.

Some factories place initialization parameters in the deployed proxy’s storage during the same transaction.

Developers must verify whether the deterministic commitment covers the implementation, initializer data, or only a generic proxy shell.

CREATE2 and Upgradeable Contracts

CREATE2 is not an upgrade system by itself.

A contract deployed with CREATE2 can be upgradeable when it uses a proxy or another explicit upgrade architecture.

In that design, the proxy remains at the deterministic address while its implementation reference may change.

The proxy’s administrator, governance rules, delay, and implementation verification determine upgrade security.

A deterministic proxy address does not guarantee immutable behavior.

Users should inspect upgrade permissions instead of assuming that a predictable address means permanent code.

CREATE2, SELFDESTRUCT, and Redeployment

Older CREATE2 designs sometimes used

to remove a contract and later deploy different behavior at the same address.

These designs were often called metamorphic contracts.

Ethereum’s current EIP-6780 SELFDESTRUCT rules generally prevent a long-lived contract from deleting its code and storage.

When SELFDESTRUCT is called by a contract that was not created in the same transaction, it transfers the balance but does not delete the code, storage, or account.

As a result, ordinary upgrade patterns that depended on destroying a deployed contract and recreating it at the same CREATE2 address no longer work.

EIP-6780 explicitly recommends using established proxy-based upgrade designs instead of CREATE2 redeployment for upgradeability.

SELFDESTRUCT remains deprecated, and new systems should not rely on its behavior remaining unchanged indefinitely.

Metamorphic Contract Risk

A metamorphic contract is intended to change the code operating at a stable address through destruction and redeployment.

Before current SELFDESTRUCT restrictions, this pattern could make address-based trust especially dangerous.

A user might verify one version of the code and later interact with different code at the same address.

Current Ethereum rules have broken the general long-lived redeployment pattern, but older networks or different EVM environments may have different SELFDESTRUCT behavior.

Security tools should evaluate the rules of the specific blockchain and block period being analyzed.

A historical transaction should be interpreted according to the protocol rules active when it occurred.

CREATE2 Gas Costs

CREATE2 uses a gas structure similar to ordinary CREATE and adds a cost for hashing the initialization code.

EIP-1014 defines this additional hash cost according to the number of 32-byte words in the initialization code.

Larger initialization code therefore requires more gas for address derivation as well as more gas for memory and constructor execution.

The deployment also pays for storing the resulting runtime bytecode and performing constructor operations.

Network gas schedules can change through protocol upgrades, so fixed gas estimates should not be treated as permanent.

A prefunded counterfactual account may still need enough native cryptocurrency or a fee sponsor to pay for its eventual deployment.

Initialization-Code Size Limits

Ethereum applies protocol limits and metering to contract initialization code.

EIP-3860 introduced additional init-code metering and a maximum initialization-code size.

The rules apply to both CREATE and CREATE2 deployments.

Large factories should not assume that arbitrarily large constructor logic can be submitted successfully.

Development tools should test the final compiled initialization code against current network limits.

Vanity Contract Addresses

Developers can search through many salt values until the predicted CREATE2 address contains a desired prefix or pattern.

This process is known as mining a vanity contract address.

A short recognizable prefix can make an address easier to identify visually.

It does not improve the smart contract’s security or authority.

Users should verify the complete address because scammers can generate addresses with similar prefixes and suffixes.

A vanity address should never replace bytecode verification and trusted deployment records.

CREATE2 and Address Poisoning

Address poisoning attempts to make a deceptive address appear in a user’s transaction history or wallet interface.

An attacker may generate an address with characters resembling a trusted address.

CREATE2 can help search for contract addresses with chosen visual patterns by varying the salt.

The attack does not require breaking CREATE2 or Keccak-256.

It relies on users checking only the beginning or end of an address.

Users should verify the complete address or use a trusted address-book system before sending cryptocurrency.

Cross-Chain Address Confusion

The same hexadecimal address can exist on multiple EVM networks.

It may contain the same code, different code, or no code depending on the network.

A deterministic deployment plan can create identical addresses, but the blockchain identifier remains essential.

Sending assets to the correct address on the wrong network may make them inaccessible through the intended application.

Wallets and interfaces should display both the contract address and selected network clearly.

Developers should verify code hashes and configuration on every supported chain.

Factory Trust Risks

A deterministic address calculation assumes that the selected factory behaves as expected.

A factory may alter the salt, modify initialization code, apply access controls, charge fees, or transfer deployment value unexpectedly.

An upgradeable factory may change after a developer initially reviews it.

A factory controlled by one private key may become unavailable or malicious if the key is lost or compromised.

Permissionless factories reduce some control risks but can create front-running and spam concerns.

Developers should verify the factory runtime code and its deployment mechanism before relying on predicted addresses.

Compiler and Metadata Risks

Solidity compiler versions can produce different creation bytecode from the same source code.

Compiler settings such as optimization runs, metadata configuration, linked libraries, and target EVM version can also change the bytecode.

A small bytecode difference produces a different initialization-code hash and CREATE2 address.

Developers should pin the compiler version and build configuration used for deterministic deployment.

Reproducible build procedures help independent users confirm that published source code generates the deployed bytecode.

Copying only the Solidity source without the build settings may be insufficient to reproduce the predicted address.

Library Linking

A Solidity contract may contain placeholders that must be replaced with deployed library addresses before creation.

The linked creation bytecode becomes part of the CREATE2 initialization code.

Changing a library address changes the predicted contract address.

Cross-chain deployment can therefore fail to produce identical addresses when linked libraries are located at different addresses.

Projects seeking identical multi-chain addresses may need deterministic library deployments before deploying dependent contracts.

CREATE2 Verification Checklist

Verify the blockchain and factory address before calculating the predicted destination.

Confirm the salt’s exact 32-byte encoding.

Use creation bytecode rather than runtime bytecode.

Include ABI-encoded constructor arguments in the initialization code.

Pin the compiler version, optimization settings, linked libraries, and metadata configuration.

Check whether the predicted address already has code or a nonzero nonce.

Simulate the factory call and review any constructor dependencies on external state.

After deployment, compare the actual address, runtime bytecode, storage configuration, owner, implementation, and emitted events with the expected result.

Advantages of CREATE2

CREATE2 allows a contract address to be known before deployment.

It supports counterfactual wallets and contracts that can receive assets before code is created.

It removes dependence on the factory’s changing deployment nonce.

It can create consistent application addresses across compatible EVM networks when all required inputs match.

It supports efficient state-channel and dispute-contract designs.

It can simplify address management in wallets, software libraries, smart contracts, and multichain interfaces.

It also enables reproducible deployment systems in which users independently verify the expected destination.

Limitations of CREATE2

CREATE2 does not guarantee that the contract will actually be deployed.

It does not guarantee that the factory is trustworthy or available on every network.

It does not guarantee that identical addresses contain identical runtime code or state across chains.

It does not protect an uninitialized proxy, unsafe constructor, compromised administrator, or vulnerable smart contract.

It does not permit an existing contract to be overwritten when the destination has code or a nonzero nonce.

Current SELFDESTRUCT rules prevent general long-lived destroy-and-redeploy upgrade patterns.

It also creates operational risks when users send funds to a predicted address before fully verifying the deployment inputs.

Frequently Asked Questions

What is CREATE2 in simple terms?

CREATE2 is an EVM instruction that lets developers calculate a smart contract address before deploying the contract.

What does deterministic deployment mean?

Deterministic deployment means that the same defined deployment inputs produce the same calculated contract address.

Which EIP introduced CREATE2?

CREATE2 was introduced through EIP-1014.

What is the CREATE2 opcode?

The CREATE2 opcode is

.

What inputs determine a CREATE2 address?

The address depends on the CREATE2 factory address, a 32-byte salt, and the hash of the initialization code.

Does CREATE2 use a nonce?

CREATE2 does not use the factory’s changing contract-creation nonce in its address formula.

Is the transaction sender included in the CREATE2 formula?

The contract that directly executes CREATE2 is included, which is normally the factory rather than the external wallet calling it.

What is a CREATE2 salt?

A salt is a 32-byte value used to distinguish deterministic deployments and produce different addresses.

Does the CREATE2 salt need to be secret?

No, the salt normally does not need to remain secret.

What is init code?

Init code is temporary creation code that runs the constructor and returns the runtime bytecode stored at the new address.

Does CREATE2 hash runtime bytecode?

The address formula hashes initialization code rather than directly hashing only the final runtime bytecode.

Do constructor arguments change the CREATE2 address?

Yes, Solidity constructor arguments are included in the initialization code and normally change the predicted address.

Can CREATE2 predict an address offchain?

Yes, the address can be calculated locally without submitting a blockchain transaction.

Can an undeployed CREATE2 address receive cryptocurrency?

Yes, a predicted address can receive native cryptocurrency and compatible tokens before contract deployment.

Is sending funds to an undeployed address safe?

It is risky unless the factory, salt, initialization code, deployment ability, and future authorization rules have been verified.

Can CREATE2 deploy over an existing contract?

No, deployment fails when the target address already has nonempty code or a nonzero nonce.

Can CREATE2 deploy the same contract twice?

The same factory, salt, and initialization code cannot successfully deploy twice while the original destination remains occupied.

Can the same salt be reused?

Yes, the same salt can produce different addresses when the factory or initialization-code hash differs.

Can someone front-run a CREATE2 deployment?

Someone may copy a public factory call and deploy first, which can disrupt timing and may be dangerous when constructor behavior depends on changing external data.

Does CREATE2 guarantee identical code across chains?

No, identical addresses require matching inputs, while constructor environment, initialization, configuration, and network state can still produce important differences.

How can CREATE2 create the same address on several networks?

The same factory address, salt, and initialization-code hash must be used on every compatible network.

Is the chain ID part of the CREATE2 formula?

The basic formula does not directly include the chain ID, although deployment code or constructor inputs may include chain-specific information.

What is a CREATE2 factory?

A CREATE2 factory is a smart contract that executes deterministic deployments for users or other contracts.

What is a singleton factory?

A singleton factory is a CREATE2 deployer intended to exist at a known identical address across several networks.

What is counterfactual deployment?

Counterfactual deployment means using or referencing a predictable contract address before the contract has been deployed.

How does CREATE2 help smart contract wallets?

It lets a wallet address be calculated and funded before the wallet contract is created.

How is CREATE2 related to ERC-4337?

ERC-4337 account factories commonly use CREATE2 to derive and deploy predictable smart contract account addresses.

Can an undeployed contract sign messages?

ERC-6492 provides a method for verifying signatures associated with certain counterfactual contract accounts before deployment.

Is CREATE2 an upgrade mechanism?

No, upgradeability requires a separate proxy or governance design.

Can SELFDESTRUCT clear a contract for CREATE2 redeployment?

Current Ethereum rules generally preserve the code and storage of established contracts, so long-lived destroy-and-redeploy upgrade patterns no longer work.

What is a metamorphic contract?

A metamorphic contract is an older design intended to change code at one address through destruction and deterministic redeployment.

Does CREATE2 cost more gas than CREATE?

CREATE2 adds a cost for hashing the initialization code in addition to ordinary creation, memory, constructor, and code-storage costs.

Can CREATE2 generate a vanity address?

Yes, developers can test many salts until the predicted address contains a desired visual pattern.

Does a vanity CREATE2 address improve security?

No, a recognizable prefix or suffix does not prove code safety, ownership, or authenticity.

Why did my predicted CREATE2 address differ from deployment?

Common causes include the wrong factory, salt encoding, compiler output, linked library, constructor arguments, or confusion between creation and runtime bytecode.

How can I verify a CREATE2 deployment?

Recalculate the address from exact inputs and compare the deployed runtime code, storage, owner, implementation, and events with the expected values.

Conclusion

Deterministic Deployment through CREATE2 allows an Ethereum-compatible smart contract address to be calculated before the contract exists onchain.

The address is derived from a fixed prefix, the CREATE2 factory address, a 32-byte salt, and the hash of the initialization code.

Constructor arguments, compiler output, linked libraries, and build settings can change the initialization code and therefore change the address.

CREATE2 supports counterfactual smart accounts, state channels, token-bound accounts, predictable application components, and same-address multichain deployments.

A predicted address can receive cryptocurrency before deployment, but those assets may become inaccessible if the intended contract cannot be created.

The same address across networks requires the same factory, salt, and initialization-code hash and does not automatically guarantee identical code, state, or security.

Developers must also protect initializer functions, avoid environment-dependent constructors, verify factory behavior, and account for front-running risks.

Current Ethereum SELFDESTRUCT rules prevent general upgrade systems based on destroying a long-lived contract and recreating it at the same address.

CREATE2 should therefore be treated as an address-derivation and deployment tool rather than an automatic security or upgrade solution.

When its inputs, factory, bytecode, and initialization process are carefully verified, CREATE2 provides a powerful foundation for predictable and user-friendly cryptocurrency applications.