EIP-7997: Deterministic Factory Contract

A minimal `CREATE2` factory shared by EVM chains.

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 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), included in genesis, or added via irregular state transition.

Specification

• FACTORY_ADDRESS = 0x4e59b44847b379578588920cA78FbF26c0B4956C

The chain’s state MUST include FACTORY_ADDRESS with nonce 1 and this runtime code:

0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe03601600081602082378035828234f58015156039578182fd5b8082525050506014600cf3

A chain may satisfy this requirement by any 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, including the account in the genesis state, or inserting it via an irregular state transition. Regardless of the method used, the resulting FACTORY_ADDRESS account MUST have the nonce and runtime code specified above.

This is a contract that invokes the CREATE2 instruction (EIP-1014) 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 bytecode is equivalent to the following runtime Yul code when compiled for Constantinople:

calldatacopy(0, 32, sub(calldatasize(), 32))
let result := create2(callvalue(), 0, sub(calldatasize(), 32), calldataload(0))
if iszero(result) { revert(0, 0) }
mstore(0, result)
return(12, 20)

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).

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.

Citation

Please cite this document as:

Francisco Giordano (@frangio), Toni Wahrstätter (@nerolation), Nick Johnson (@Arachnid), "EIP-7997: Deterministic Factory Contract [DRAFT]," Ethereum Improvement Proposals, no. 7997, August 2025. Available: https://eips.ethereum.org/EIPS/eip-7997.