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.