--- eip: 7997 title: Deterministic Factory Contract description: A minimal `CREATE2` factory shared by EVM chains. author: Francisco Giordano (@frangio), Toni Wahrstätter (@nerolation), Nick Johnson (@Arachnid), Jochem Brouwer (@jochem-brouwer) discussions-to: https://ethereum-magicians.org/t/eip-7997-deterministic-factory-predeploy/24998 status: Review type: Standards Track category: Core created: 2025-08-03 requires: 1014 --- ## Abstract The availability of a well-known `CREATE2` factory at `0x4e59b44847b379578588920cA78FbF26c0B4956C` is made a formal requirement to enable deterministic deployments at identical addresses across EVM chains. This benefits developer experience, user experience, and security, in particular for multi-chain and cross-chain applications, including account abstraction. ## Motivation There are now a large number of EVM chains where users want to transact and developers want to deploy applications, and we can expect this number to continue to grow in line with Ethereum's rollup-centric roadmap and the general adoption of programmable blockchains. Most applications support multiple chains and aspire to support as many as possible, and their developers widely prefer to deploy contracts at identical addresses across all chains as a *multi-chain deterministic deployment*. This kind of deployment reduces the number of addresses that must be distributed to use the application, so that it no longer scales with the number of supported chains. This simplification has many benefits throughout the stack: interfaces and SDKs need to embed and trust fewer addresses, and other contracts that depend on them can be implemented without chain-specific customization (which in turn makes them amenable to multi-chain deployment). This kind of deployment is also highly desirable and important for account abstraction. Without it, a user's smart contract accounts are deployed at different addresses on different chains, and each account is tied to a single chain. This limitation is difficult to explain to users and has caused loss of funds. If smart contract accounts cannot be multi-chain like EOAs, they offer downgraded UX and are more prone to error. There is currently no native or fully robust way to perform multi-chain deterministic deployments. While `CREATE2` enables deterministic deployments, the created address is computed from that of the contract that invokes the instruction, so a *factory* that is itself multi-chain is required for bootstrapping. Four workarounds are currently known to deploy such a factory: 1. A keyless transaction crafted using Nick's method that can be posted permissionlessly to new chains. 2. Private keys held by some party used to sign creation transactions for each chain as needed. 3. A private key intentionally leaked so that any party can permissionlessly create an [EIP-7702](./eip-7702.md) signed delegation and deploy a factory from the leaked account. 4. Factories already deployed on other chains (by any of the previous methods) inserted in a new chain at genesis or via a hard fork. Keyless transactions have been the most successful approach. However, since such transactions have a fixed gas price and limit, they have often been impossible to deploy on chains where those gas parameters are insufficient or invalid. The same issue has begun to affect Ethereum itself and its devnets due to changes to the gas schedule. This EIP formalizes the guarantee that an already widely used keyless `CREATE2` factory should be available on EVM chains, whether deployed by an ordinary transaction (including its keyless transaction), or included in genesis. ## Specification * `FACTORY_ADDRESS` = `0x4e59b44847b379578588920cA78FbF26c0B4956C` The chain's state MUST include `FACTORY_ADDRESS` with nonzero nonce and this runtime code: ``` 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe03601600081602082378035828234f58015156039578182fd5b8082525050506014600cf3 ``` A chain may satisfy this requirement by either of the following means that results in the account above: deploying the factory with an ordinary transaction (for example, its keyless creation transaction) where the chain's gas parameters permit it, or including the account in the genesis state with a nonce equal to `1`. Regardless of the method used, the resulting `FACTORY_ADDRESS` account MUST have the runtime code specified above. If the chain is already running with gas parameters that no longer allow deployment via the keyless transaction, the only way to add the contract at the expected address is a coordinated irregular state transition, which is outside the scope of this EIP. Client software MUST NOT check for the existence of the contract at the fork boundary. This is a contract that invokes the `CREATE2` instruction ([EIP-1014](./eip-1014.md)) with a salt equal to the first 32 bytes of the call's input data, init code equal to the remaining data, and value equal to the call's value. If input data is smaller than 32 bytes, the contract will attempt to copy close to 2^256 bytes of calldata and should revert as a result. If contract creation fails (`CREATE2` outputs `0`), the call reverts with empty return data. When successful, the address is returned in exactly 20 bytes of data with no padding. The above runtime bytecode disassembles to the following: ```asm push32 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe0 calldatasize add push1 0x00 dup2 push1 0x20 dup3 calldatacopy dup1 calldataload dup3 dup3 callvalue create2 dup1 iszero iszero push1 0x39 jumpi dup2 dup3 revert jumpdest dup1 dup3 mstore pop pop pop push1 0x14 push1 0x0c return ``` ## Rationale ### Choice of factory The factory at `0x4e59b44847b379578588920cA78FbF26c0B4956C` has been used close to 25000 times on Ethereum Mainnet, deployed to hundreds of chains using its keyless transaction, included in multiple L2s by default, and used as the default factory for deterministic deployments in developer tools. The bytecode is compatible with any EVM chain that has activated EIP-1014, which Ethereum included in Constantinople. In particular, it does not depend on the more recent `PUSH0` ([EIP-3855](./eip-3855.md)). Two known downsides of this factory were considered. First, the address of the created account is returned with no padding, and may need to be decoded differently to other address-returning calls. Second, returndata is not propagated in case of revert, and an EVM trace may be required for obtaining a diagnostic error message. Both issues were considered non-blocking due to the existence of workarounds, including the possibility of using this factory to deploy further improved factories. Notably, if such factories are fully deterministic and permissionlessly deployable (and only require baseline EVM features), they are guaranteed to exist or be deployable at the same address on the same set of chains. ## Backwards Compatibility No backwards compatibility issues are introduced. On chains that already have the factory at `FACTORY_ADDRESS` (Ethereum Mainnet and most others), satisfying this requirement is a no-op. No other contract is expected at this address. ## Security Considerations ### Frontrunnable deployments The deployment of contracts that read the environment (`ORIGIN`, `NUMBER`, etc.) may be frontrun and created with attacker-chosen parameters. It's recommended to use this factory to deploy fully deterministic contracts only. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).