This ERC proposes a permissionless method to deploy a universal CREATE2 factory contract to a deterministic address (0xC0DE8E984dF1846E6AdE500972641ce0a9669e1b) across EVM-compatible chains. It leverages EIP-7702 and a publicly known private key to initiate the deployment.
This approach aims to overcome limitations of current methods, specifically the reliance on transactions without EIP-155 replay protection, guarded private keys, or chain-specific preinstalled contracts. This makes the mechanism both more permissionless and error resistant compared to existing CREATE2 factory deployments. However, while it does suffer from potential front-running attacks may cause delays and gas griefing, they cannot permanently prevent the factory’s deployment to the expected address.
The ERC specifies exact parameters for the CREATE2 factory, to ensure a single, universal CREATE2 factory for the community.
Some caveats coming from the guy who deployed CreateX on over 150 chains (cannot recommend lol):
This entire approach hinges on the assumption that the new transaction type 4 will be supported by all target chains. This approach scales well until you go beyond the standard EVM chains; example Linea is still running on london. The rollout of this EIP is probably best if the rollout of EIP-7702 has happened almost everywhere; but even then you probably cannot support more exotic use cases like Filecoin with their own EVM-compatible but not EVM-equivalent engine (I doubt they will upgrade to this tx type, but who knows). The fundamental question is: how much do we care about the exotic world of EVM-compatible but not EVM-equivalent world? I personally care and thus have chosen the “private key as backup” method for CreateX, which is definitely suboptimal.
You can have scenarios where EVM chains support transaction type 4 but e.g. not PUSH0. So if the CREATE2_FACTORY_INIT_CODE contains not supported opcodes, this can lead to scenarios where you would face contract creation failures.
That being said, I personally like the idea of the ERC overall. Based on my practical experience, I can envision already a couple of practical issues that can break the scalability of this proposal.
The only issue I see with this scheme is that it stops working in a post-quantum scenario where ECDSA keys are deactivated. However, if you keep the seed private (and safe for however many decades) it could probably just downgrade to the “secret private key” solution (assuming something like this is implemented).
Ideally I think multi-chain deployments should be provided as a native feature of the chain, but this is a great solution as long as we don’t have that.
I agree that having a native feature on chains is the preferred way. The Safe team (and also @pcaversaccio) are trying to get as many of the L2 providers to include them as pre-deployments for now.
if you keep the seed private
As the private key is publicly known (as part of the ERC) this shouldn’t bee an issue.
in a post-quantum scenario
Also agree here that with changes introduced to Ethereum related to Quantum Security will most likely trigger a lot of follow up changes. Lets see when this happen
In the latest version of the ERC, we changed the code to use RETURNDATASIZE for pushing 0’s to remove the dependency on EIP-3855 (i.e. PUSH0). So it should be more portable now.
Why not use Nick’s method to create the signature for the delegation? Then you don’t have to worry about a future opcode permanently deploying code to the deployer account.
You run into a chicken-and-egg problem. Specifically, the delegation signs over MAGIC || rlp([chain_id, address, nonce]), so while MAGIC, chain_id (set to 0 for a chain-agnostic delegation) and nonce (set to 0 by nature of Nick’s method) can all trivially set to fixed values, address cannot. You would have to have a way to deploy the target “bootstrapping” contract to the same address on all chains, which brings us back to the original problem.
I will add a blurb under the “Rationale” section to clarify this.
Edit: added a section to the “Rational” section in the ERC PR to explain this.
