EIP-7997 Deterministic Factory Contract
No call decision · EVM & execution · EIP status Last Call · created 2025-08-03
Makes it an official requirement that the widely used CREATE2 factory exists at address 0x4e59b44847b379578588920cA78FbF26c0B4956C. As a result, contracts can be deployed to the same address on any EVM chain.
Why it is needed
There are now many EVM chains, and most developers want to deploy a contract at the same address on every chain. When addresses differ between chains, apps and wallets have to maintain separate per-chain address lists, and because smart contract accounts get deployed at different addresses on different chains, there have been real cases of lost funds. The CREATE2 opcode supports deployments with predetermined addresses, but the created address is computed from the address of the contract that executes the opcode, so a factory that exists at the same address on every chain is needed first. Until now, this factory has been deployed with a keyless transaction that anyone can broadcast as is, but that transaction has a fixed gas price and limit, so deployment was often impossible on chains with different gas rules. Gas schedule changes have started to cause the same problem on Ethereum itself and on devnets, so the proposal aims to guarantee the existence of the already widely used factory through the rules themselves.
What changes
Today
- Factory deployment depends on workarounds such as keyless transactions, a specific party's private-key signature, or intentional key leaks
- On chains whose gas parameters do not match, the factory cannot be deployed with a keyless transaction
- Smart contract accounts can be deployed at different addresses on different chains, causing confusion and lost funds
After EIP-7997
- The existence of a CREATE2 factory at address 0x4e59b44847b379578588920cA78FbF26c0B4956C becomes an official requirement
- New chains meet the requirement by including this account in genesis or deploying it with a regular transaction
- Using the same salt and init code on every EVM chain deploys to the same address
Who is affected
- App and wallet developers: Multichain deployment becomes possible without per-chain address customization, and the number of addresses that SDKs and interfaces must trust goes down.
- Users: Smart contract accounts can have the same address across multiple chains like EOAs, which improves the account abstraction user experience.
- Client teams: Do not add code that checks for this contract's existence at the fork boundary. On Ethereum mainnet, where the factory already exists, there is nothing to do.
- L2s and new chains: They must meet the requirement by including the account in genesis or by broadcasting a keyless transaction.
In depth
Requirement: Fixed Address and Runtime Code
FACTORY_ADDRESS is defined as 0x4e59b44847b379578588920cA78FbF26c0B4956C. The chain state MUST include an account at this address with a nonzero nonce and the runtime code specified in the original text (0x7fff...600cf3). However the requirement is met, the runtime code of the resulting account must exactly match the specified bytecode. The original text also includes the disassembly of this bytecode.
Ways to Meet the Requirement and Exclusion of Irregular State Transitions
The requirement can be met in two ways. On chains whose gas parameters allow it, deploy with a regular transaction (including the keyless creation transaction); otherwise, include the account in the genesis state with nonce 1. If the gas parameters of a chain that is already running no longer allow keyless deployment, the only way to place the contract at the expected address is a coordinated irregular state transition, which is outside the scope of this EIP. Also, client software MUST NOT check for the existence of this contract at the fork boundary.
Behavior of the Factory Contract
This contract executes the CREATE2 opcode (EIP-1014), using the first 32 bytes of the call input as the salt, the remaining data as the init code, and the value sent with the call as the value. If the input is shorter than 32 bytes, it tries to copy calldata of close to 2^256 bytes, so it reverts as a result. If contract creation fails (CREATE2 outputs 0), it reverts with empty return data, and if it succeeds it returns the address as exactly 20 bytes with no padding.
Why This Factory
This factory has been used nearly 25,000 times on Ethereum mainnet, has been deployed to hundreds of chains with keyless transactions, is included by default in several L2s, and is used as the default for deterministic deployment in development tools. The bytecode works with only EIP-1014, which was activated in Constantinople, and does not depend on the more recent PUSH0 (EIP-3855). Two known drawbacks were also reviewed. First, the created address is returned without padding, so it may need to be decoded differently from other calls that return an address. Second, return data is not passed on a revert, so an EVM trace may be needed to get diagnostic messages. Both problems have workarounds, so they were judged not to be decisive flaws, and it is also possible to use this factory to deploy an improved factory again.
Compatibility and Security Considerations
There are no backward compatibility issues. On chains that already have a factory at FACTORY_ADDRESS (Ethereum mainnet and most chains), meeting this requirement causes no change, and no other contract is expected to exist at this address. On the security side, deployments of contracts that read the execution environment (ORIGIN, NUMBER, etc.) can be intercepted by frontrunning and created with parameters chosen by an attacker. Therefore, it is recommended to deploy only fully deterministic contracts with this factory.
Status and Core Developer Call Decisions
The status of this EIP is Last Call, and the last-call-deadline is 2026-11-01. On the core developer calls, 07.20 ACDT #88 confirmed closing the EELS irregular state transition PR for EIP-7997, because checking for the factory's existence is unnecessary and would only add unwanted witness entries. Then 07.27 ACDT #89 confirmed closing both related PRs. This means the spec wording is already correct and clients must not check for the contract's existence at the fork boundary.