Understanding ERC-7955: The Permissionless CREATE2 Factory

ERC-7955 introduces a revolutionary permissionless method for deploying CREATE2 factories across EVM-compatible chains using EIP-7702, eliminating the need for private keys while enabling truly deterministic smart contract deployments.

Smart contract deployment has evolved significantly since Ethereum's early days. While developers initially relied on nonce-based CREATE operations for contract deployment, the introduction of CREATE2 in 2019 revolutionized how we approach deterministic deployments. Now, ERC-7955: Permissionless CREATE2 Factory proposes the next evolution in this space, combining the power of EIP-7702 with CREATE2 to solve long-standing challenges in cross-chain contract deployment.

ERC-7955 defines a permissionless and deterministic deployment mechanism across all EVM-compatible chains. It uses the EIP-7702Set Code for EOAs (0x4) transaction type to deploy a universal CREATE2 factory contract to a fixed address (0xC0DEb853af168215879d284cc8B4d0A645fA9b0E) with known bytecode.

This standard addresses a fundamental bootstrapping problem: how to deploy CREATE2 factory contracts with consistent addresses and code across multiple blockchain networks without requiring private keys or centralized coordination.

ERC-7955 leverages several key technologies:

Before ERC-7955, developers faced three main approaches for deploying CREATE2 factories, each with significant limitations:

Nick Johnson's CREATE2 deployment proxy uses a sealed transaction with fixed gas price and limit, making it unsuitable for chains that enforce EIP-155 replay protection or have alternative gas schedules. It does not work on chains that only accept EIP-155 replay-protected transactions and is sensitive to changes in gas parameters on the target chain.

This method requires carefully guarding a secret key and is permissioned: the party that holds the secret key has the ultimate say on which chains will get the CREATE2 factory deployments. The current process requires builders to open a GitHub issue in the Safe Singleton Factory repository and wait for the contract to be deployed.

Having popular CREATE2 deployment factories deployed on new chains by default is not standardized nor adopted by all chains and is permissioned as a chain can choose not to include a specific CREATE2 factory contract preinstalled.

The ERC-7955 deployment process involves three key steps:

First, a bootstrap contract is deployed containing the necessary code to create the CREATE2 factory. The exact implementation or address to which this contract is deployed does not matter, as long as it has the critical bootstrapping code.

The deployer account signs an EIP-7702 authorization to the bootstrap contract; this can be done permissionlessly because the account is publicly known and standardized as part of ERC-7955.

A transaction is executed, including the authorization, calling the deployer account. This results in the execution of the bootstrapping code and creation of the Permissionless CREATE2 Factory contract.

The CREATE2 factory accepts salt || init_code as input - a 32-byte salt value concatenated with the initialization code. It will execute a CREATE2 with the specified salt and init_code, deploying a contract with init_code to keccak256(0xff || CREATE2_FACTORY_ADDRESS || salt || keccak256(init_code))[12:].

The standard specifies several fixed parameters:

It can be executed on any chain by any user and guarantees a reliable determination of smart contract deployments on any chain. Unlike previous methods, ERC-7955 works across all EVM-compatible chains that support EIP-7702.

The method is secure against "out of gas" and other errors. Unlike either method, failed deployments are recoverable: even if the transaction were to revert, the CREATE2 factory can still be deployed in a new transaction.

The universal CREATE2 factory contract can be deployed by anyone. This eliminates the need for teams to request deployments from specific organizations or wait for manual interventions.

CREATE2 allows you to deploy smart contracts to deterministic addresses, based on parameters controlled by the deployer, enabling "counterfactual" deployments where you can interact with addresses that haven't been created yet.

Popular existing solutions include:

CREATE2 introduces risks like address squatting or frontrunning: if a project publicly reveals that it intends to deploy a contract with certain code and salt, an attacker could attempt to deploy their own contract to that same address before the project does.

CREATE2 provides new capabilities such as the ability to deploy or redeploy smart contracts at a deterministically calculated address, but must be used carefully to protect against potential exploitation.

ERC-7955 enables seamless deployment of protocols across multiple chains without coordination overhead. Eco provides a frictionless stablecoin experience that accelerates user onboarding and streamlines money movement onchain, and could benefit from consistent addressing across chains.

With the CREATE2 opcode, a counterfactual smart contract — which is created off-chain at a deterministic address but never actually deployed — can be created and used by channel participants, but only actually deployed if needed.

Modular smart accounts move functionality into external contracts (modules) to increase innovation speed and allow customizability by developers and users. ERC-7955 enables consistent smart account addresses across chains.

Streamlined contract deployment with CREATE2 helps with deployment automation since addresses can be automatically precalculated and included in other smart contracts that need them.

When implementing ERC-7955:

For projects looking to integrate ERC-7955:

This mechanism requires an EVM chain with EIP-7702 enabled, meaning not all chains can use this deployment method. Chains must implement EIP-7702 support before ERC-7955 becomes viable.

Because the DEPLOYER_PRIVATE_KEY is public, anyone can sign alternative delegations or transactions and front-run a legitimate CREATE2 factory deployment. However, this primarily results in gas griefing rather than permanent deployment prevention.

A future network upgrade may introduce new mechanisms to set an account's code permanentl. If this were to happen, the DEPLOYER_ADDRESS account's code could be set to something that does not execute the necessary bootstrapping code.

Safe Research proposed ERC-7955 and released an ERC-7955 Permissionless CREATE2 Factory deployment tool to make the process more accessible. Early adoption by major protocols could accelerate widespread implementation.

The Ethereum community continues to refine cross-chain deployment standards. There's an ongoing Ethereum Magicians discussion to help shape the future of the ERC.

Development tools and frameworks are beginning to integrate ERC-7955 support, making it easier for developers to leverage permissionless deployments in their workflows.

ERC-7955 represents a significant step forward in smart contract deployment methodology. By combining EIP-7702's code delegation capabilities with CREATE2's deterministic addressing, it solves the long-standing challenge of permissionless, fault-resistant factory deployment across EVM chains.

For developers working on cross-chain applications, DeFi protocols, or any system requiring consistent contract addresses, ERC-7955 offers a compelling alternative to existing deployment methods. While it requires EIP-7702 support and careful implementation, the benefits of truly permissionless, recoverable deployments make it a valuable addition to the Ethereum ecosystem.

As the standard matures and gains adoption, we can expect to see improved tooling, broader chain support, and integration into major development frameworks. The combination of permissionless operation, fault resistance, and universal applicability positions ERC-7955 as a foundational piece of infrastructure for the multi-chain future of Ethereum.

For teams looking to implement ERC-7955 or deploy contracts with consistent addresses across chains, the permissionless CREATE2 factory offers a robust, future-proof solution that eliminates many traditional deployment challenges.

Q: What chains support ERC-7955?

A: Any EVM-compatible chain that implements EIP-7702 support can use ERC-7955. This includes Ethereum mainnet and various L2 solutions once they upgrade to support EIP-7702.

Q: How does ERC-7955 compare to Nick's method?

A: Unlike Nick's method, ERC-7955 works with EIP-155 replay protection, adapts to current network conditions, and allows recovery from failed deployments.

Q: Can the factory address be changed?

A: No, ERC-7955 specifies a fixed factory address (0xC0DEb853af168215879d284cc8B4d0A645fA9b0E) to ensure consistency across all implementations.

Q: What happens if a deployment fails?

A: Unlike other methods, ERC-7955 deployments are recoverable. Failed deployments can be retried in new transactions without permanent consequences.

Q: Is ERC-7955 production-ready?

A: ERC-7955 is a proposed standard. While the specification is complete, adoption depends on EIP-7702 implementation across target networks and community acceptance.