Potential security implications of CREATE2? (EIP-1014)



An audit can tell you if a contract can have its code changed, who can change the code, how they can change it, and what the code can be changed to.

Contracts being able to have their code change has always been possible, and this just provides a new way to do it.


Can you link me your explanation? I cannot find it. I would like to see a real world scenario where somehow you cannot prove that redeployments are not possible.


Can you explain this a little better? I was under the impression that CREATE2 was the opcode to redeploy a contract at a specific address with “upgraded code”. If you cannot have any code changed, the all CREATE2 is good for is redeploying the same smart contract to the same address … ?
Thanks in advance!


create2 contracts can also have their code changed, if the init code permits it.

Yes, you can safely interact with a CREATE2 contract, you just need to validate some new things:

  • Prove that there is no way to destroy the contract, then nothing is different from an audit with a CREATEd contract
  • OR, prove that the init code always produces the exact same bytecode. This should be possible for many/most “honest” use cases. You still need to determine if “zombie contracts” are a problem in your scenario (where the same contract pops up after it has been destroyed).


This is like talking to a brick wall.

“Prove that there is no way to destroy the contract” What if that’s not true?

“OR, prove that the init code always produces the exact same bytecode.” What if that’s not true either?

“This should be possible for many/most “honest” use cases.” WTF? We’re not talking about “honest” use cases, we’re talking about people pulling a fast one, which this makes 1000x more likely.

This is full-blown Twilight Zone territory.


Gladly. It goes like this:

  • Company XYZ: Announcing the $50MM Ethereum killer app!

  • Ethereum community: Killer App! But wait a tick; you forgot to guard against CREATE2 exploits

  • Company XYZ: Ah, shoot, you’re right. Well, it would be cost prohibitive to redo it now; You’ll just have to trust us

  • Ethereum community: Okie dokie, then.

  • (months or years pass)

  • Company XYZ: Ooops! Turns out I was a scoundrel. Contract replaced. Money stolen, or whatever I want.


Eliminating the double negatives, you want me to prove redeployments are possible? Your very own CREATE2 does that, friend.

OK, I’m going to stop beating this dead horse because it’s getting me nowhere. I’ll just reiterate this:

People don’t trust the network because they verified some bytecode. That is not how the real world works. People trust the network because a lot of horrible shit that could’ve happened didn’t. That’s it.

This is inviting another DAO-like disaster. You really think we’ll get away with it twice?


I’ve gone ahead and implemented a factory contract for creating what I’m calling metamorphic contracts, or contracts that can be redeployed with new bytecode to the same address. It does so by first deploying an implementation contract, then deploying a transient contract with fixed, non-deterministic initialization code via CREATE2. The transient contract clones the bytecode of the implementation contract and uses it to deploy the metamorphic contract via CREATE, then immediately self-destructs. There’s also an immutable create2 factory contract for preventing metamorphism in any contracts it deploys, which operates similarly to the one by @jochem-brouwer, but with a different mechanism for preventing address collisions / frontrunning.

Use this feature / bug responsibly, try to educate as many people as possible, and stay vigilant against mutable villainy!


Revised the metamorphic contract factory so that it no longer requires an intermediate transient contract. Here’s an explanation of the current initialization code used to deploy the metamorphic contracts: https://gist.github.com/0age/9a4541cce380a1b2c7e477af06ba6376


Here’s another use-case for metamorphic contracts: you can use their runtime code as dynamic storage to save gas in certain applications https://medium.com/coinmonks/on-efficient-ethereum-storage-c76869591add