Smart Contracts Aren’t Deployed Yet, but Addresses Already Exist: Why CREATE2 (EIP-1014) Matters

In fact, the CREATE opcode hasn't gone anywhere — it's used every time a contract is created using the new keyword:

The full contract code is provided here.

The CREATE opcode takes three arguments and returns one value:

Input data (Stack input):

• value — the amount of native currency in wei to be sent to the new address.
• offset — the byte offset where the contract’s initialization code starts.
• size — the size of the initialization code.

Output data (Stack output):

• address — the address of the deployed contract, or 0 if an error occurred.

Deploying a contract via assembly looks more illustrative:

The full contract code with creation via assembly is here.

Address Calculation with the CREATE Opcode (0xf0)

For the CREATE opcode to return the address of the deployed contract, it needs the caller’s address (msg.sender) and its nonce:

In simplified form, it looks like this:

But in reality, the process is more complex:

Where:

• sender_address — the address of the sender creating the contract.
• sender_nonce — the sender’s nonce (number of transactions sent from this address).
• rlp — RLP encoding function. RLP (Recursive Length Prefix) is used for serializing data in Ethereum, ensuring unambiguous and predictable encoding.
• keccak256 — the Keccak-256 hash function.
• [12:] — the first 12 bytes are discarded since keccak256 returns 32 bytes, and an Ethereum address takes the last 20 bytes of the hash (32 - 20 = 12).

Thus, in theory, it’s possible to calculate the future contract address in advance. However, there's a problem: this address depends on the nonce. If another transaction is sent before the contract is deployed, the nonce will increase, and the calculated address will become invalid.

Due to the use of RLP for address calculation, the following bulky function is needed in Solidity before deployment:

The total encoding length depends on how many bytes are needed to encode the nonce, since the address has a fixed length of 20 bytes — hence all the if statements.

For example, if the nonce is 0, the parameters mean the following:

• 0xd6 — the total length of the structure is 22 bytes (in the case where nonce is 0).
• bytes1(0x94) — indicates that the following field is 20 bytes long.
• _origin — the address field.
• bytes1(0x80) — indicates that the nonce is 0, according to RLP.

The rest is similar — only the nonce is added as one byte and so on. In RLP encoding, it’s important to explicitly specify the length of the data before the data itself.

I added this function to the Deployer contract — you can test it in Remix.

In 2018, Vitalik Buterin proposed EIP-1014: Skinny CREATE2 with the following motivation:

Sounds complicated, but I’ll try to explain. It’s about state channels. Before rollups appeared, they were considered a way to scale Ethereum.

In short, state channels had inefficiencies that could be eliminated with counterfactual instantiation. The idea is that a smart contract could exist counterfactually — meaning it didn’t need to be deployed, but its address was known in advance.

This contract could be deployed on-chain if needed — for example, if one of the channel participants tried to cheat the other during an off-chain transaction.

Example from the mechanism description:

So, from a game theory perspective, knowing that such an "insurance" exists, the parties won’t try to cheat each other, and the contract most likely won’t even need to be deployed.

You can read more about this here and here, but fair warning — the topic is not an easy one.

The CREATE2 opcode was introduced in the Constantinople hard fork as an alternative to CREATE. The main difference is the way the address of the created contract is calculated. Instead of the deployer's nonce, it uses the initialization code (creationCode) and a salt (salt).

New address calculation formula:

• 0xff — a prefix that prevents collisions with addresses created via CREATE. In RLP encoding, 0xff can only be used for petabyte-sized data, which is unrealistic in the EVM. Additionally, keccak256 provides protection against collisions.
• sender_address — the address of the sender creating the contract.
• salt — a 32-byte value, usually the keccak256 hash of some dataset that ensures the uniqueness of this salt.
• initialisation_code — the initialization code of the contract.

Important! If CREATE or CREATE2 is called in a contract creation transaction and the target address already has a non-zero nonce or non-empty code, the creation immediately reverts — similar to the case when the first byte of the initialisation_code is an invalid opcode.

This means that if a deployment results in an address collision with an already existing contract (for example, one deployed via CREATE), a revert will occur because the address’s nonce is already non-zero. This behavior cannot be changed even with SELFDESTRUCT, since it does not reset the nonce within the same transaction.

Compared to CREATE, CREATE2 differs only by the addition of one input parameter — salt.

Input data (Stack input):

• value — the amount of native currency (wei) to send to the new address.
• offset — the byte offset where the initialization code starts.
• size — the size of the initialization code.
• salt — a 32-byte value used during contract creation.

Output data (Stack output):

• address — the address of the deployed contract, or 0 if an error occurred.

Using CREATE2 in Solidity

In Solidity, CREATE2 can be used just like CREATE, simply by adding a salt:

• The full contract code is here.

  Important! The CREATE and CREATE2 opcodes are used only for creating smart contracts from other smart contracts. During the initial deployment of a contract, things work very differently — the to field in the transaction is set to nil (equivalent to null), and the actual creation is done by the RETURN opcode inside the creationCode, not by CREATE.

CREATE2 Using Assembly

Example code in Assembly (taken from Cyfrin):

• The full contract code is here.

Previously, when computing the address via CREATE, only address and nonce were used, taking no more than 64 bytes. That’s why no additional gas was charged for computation (see evm.codes).

In CREATE2, a hash of the initialization code (hash_cost) is added to the computation, since its size can vary greatly. This changed the gas calculation formula:

Thus, using CREATE2 is more expensive than CREATE, but it allows more flexibility when working with a smart contract’s address before it’s created — which opens up new possibilities.

What did the introduction of the new opcode bring?

1. Counterfactual Initialization CREATE2 allows reserving contract addresses before they are actually deployed. This is especially useful in state channels, as we discussed earlier.

2. Simplified User Onboarding In the context of account abstraction, counterfactual initialization allows creating accounts off-chain and deploying them only with the first transaction — which can even be paid for via a relayer. This makes creating an abstract account easier than creating an EOA.

   When CREATE2 first appeared, it was just an idea — but three years later, the concept was implemented in ERC-4337. It uses a static call to entryPoint.getSenderAddress(bytes initCode), which allows retrieving the counterfactual wallet address before it's deployed.

3. Vanity Addresses You can generate a "pretty" address by brute-forcing the salt, for example, if you want it to start or end with certain characters: 0xC0FFEE..., 0xDEADBEEF..., and so on.

4. Efficient Addresses In the EVM, the gas cost differs for zero and non-zero bytes. Each non-zero byte in calldata costs G_txdatanonzero (16 gas), while a zero byte costs G_txdatazero (4 gas). This means that if your address starts with zeros, using it will be cheaper.

   This aspect is explained in detail here: On Efficient Ethereum Addresses (though the gas calculations are outdated due to changes in calldata pricing).

5. Metamorphic Contracts A method of upgrading contracts via CREATE2, where a contract is destroyed (SELFDESTRUCT) and then recreated at the same address with new code. Fortunately, the community didn’t adopt this approach — for example, in this article it’s called the "ugly stepbrother of the Transparent Proxy."

   You can check out code examples here.

6. Address Calculation Instead of Storage In many cases, it’s easier to compute the address of a contract deployed via CREATE2 than to store it. A clear example of this is Uniswap v2.

   How does it work?

• To create pairs via UniswapV2Factory, CREATE2 is used, and the salt is derived from the addresses of the two tokens in the pair. Note that the pair contract uses an initialize function to store the token addresses — this is an important detail.

• Now the UniswapV2Library can compute the pair address using the known init code hash in the pairFor function. The initialization code can be hardcoded, because there’s no need to pass constructor arguments — that’s exactly why initialize is used:

⚠️ If you're forking Uniswap v2, don’t forget to change the init code hash, as it depends on the factory (factory), whose address is set in the constructor of the pair contract.

• And now, with the pairFor function, you can easily compute this address whenever needed. Just look at how often this function is used in UniswapV2Router01. For example, here’s how the add liquidity function looks:

As you can see, CREATE2 has unlocked a lot of new possibilities, though it also comes with some drawbacks.

You can find the following warning in the Solidity documentation:

This refers to a well-known vulnerability: a combination of CREATE and CREATE2 together with SELFDESTRUCT allows deploying different contracts at the same address. This exact method was used in the Tornado Cash hack, where $1M was stolen.

This also applies to metamorphic contracts.

Attack Demonstration

There’s a repository that reproduces a similar attack. I slightly modified that code so it can be tested in Remix — we’ll go through it in more detail below:

Factory contract:

This factory creates contracts with identical addresses but different code. 😈

Step 1. Deploy MetamorphicContract and call the firstDeploy function:

This call:

• Deploys the factory and the first version of the contract.
• Immediately destroys them after deployment.
• Logs their addresses.
• Destroys both contracts.

Step 2. Now you can call the secondDeploy function:

What just happened?

1. Deployed the factory using CREATE2 with a fixed salt.
2. The factory used CREATE to deploy an implementation contract. Its address depends on the factory’s address and its nonce.
3. Both contracts were destroyed using SELFDESTRUCT. This reset the factory’s nonce.
4. Deployed the same factory at the same address (since the salt didn’t change).
5. Deployed a different implementation at the same address, because the factory’s nonce is again 0.
6. Now there's completely different code at the exact same address!

The full contract code is here.

Now you know how to deploy different contracts at the same address. 🚨

• EIP-1014: Skinny CREATE2
• Docs: Salted contract creations / create2
• Blog: Precompute Contract Address with Create2
• Blog: Getting the most out of CREATE2
• Blog: A State Channels Adventure with Counterfactual Rick! (Part 1)
• Blog: Counterfactual: Generalized State Channels on Ethereum
• Blog: Understanding Solidity’s create & create2 with Tornado Cash $1M Hack
• Blog: On Efficient Ethereum Addresses