An address can be calculated before a contract is deployed. That capability is useful for coordinating software, yet it creates a simple reading trap: a predictable destination can look more established than the evidence supports. The calculation identifies an address from inputs. Deployment, runtime behaviour and security review require additional evidence.
Follow the evidence
Trace how the event could reach markets, then inspect a competing explanation.
Compare explanations
Switch lenses to see what each account explains—and what remains uncertain.
Imagine an invented deployment plan that publishes a factory address, a salt and a specific initialization-code file. Two reviewers using the same formula and exact inputs should derive the same proposed address. That reproducibility is useful: it allows disagreement about the input bytes to be detected before anyone relies on the destination. It does not show that the deployment transaction has succeeded. It does not show what a contract presently stores or what privileges its operators have. It also does not convert an attractive interface or a familiar-looking address into evidence that the code has been independently examined. Configuration can matter at the byte level. Where constructor inputs form part of the initialization code, changing those bytes changes an input to the calculation. A reviewer should therefore preserve the complete creation input rather than comparing only a project name or an advertised runtime source file. This is an implementation question that the published formula makes visible, not a performance claim about a token.
Imagine an invented deployment plan that publishes a factory address, a salt and a specific initialization-code file. Two reviewers using the same formula and exact inputs should derive the same proposed address. That reproducibility is useful: it allows disagreement about the input bytes to be detected before anyone relies on the destination. It does not show that the deployment transaction has succeeded. It does not show what a contract presently stores or what privileges its operators have. It also does not convert an attractive interface or a familiar-looking address into evidence that the code has been independently examined. Configuration can matter at the byte level. Where constructor inputs form part of the initialization code, changing those bytes changes an input to the calculation. A reviewer should therefore preserve the complete creation input rather than comparing only a project name or an advertised runtime source file. This is an implementation question that the published formula makes visible, not a performance claim about a token.
Record the network, deployer, salt and initialization-code hash used in a calculation. Then check the actual destination on that same network and examine the relevant deployment transaction if one exists. Matching a calculated address is one check; establishing that the expected contract was deployed and behaves as represented is a larger review. If a project publishes source code or an audit, connect those materials to the deployed artifact rather than assuming that an address match does that work. Also examine any documented upgrade or administrative arrangement when the intended question concerns future control. This article makes no claim about the safety of sending assets to a proposed destination. EIP 1014 is the historical protocol specification reviewed on 8 October 2026. Its address calculation is the focus here. This article does not treat every historical detail about contract lifecycle behaviour as a statement of all later Ethereum rules.
EIP 1014 defines the inputs
EIP 1014 specifies CREATE2’s address derivation using the 0xff prefix, the deploying address, a 32-byte salt and the hash of the initialization code. A Keccak-256 hash of that combined input is reduced to its final 20 bytes to form the address. Ethereum Improvement Proposal 1014 — Skinny CREATE2
The proposal distinguishes initialization code from the runtime bytecode it produces. Initialization code runs during creation and returns the code stored for later calls. The address formula commits to the initialization-code hash; substituting a runtime-code hash is not the calculation specified in the proposal. Ethereum Improvement Proposal 1014 — Skinny CREATE2
A reproducible calculation answers a narrow question
Imagine an invented deployment plan that publishes a factory address, a salt and a specific initialization-code file. Two reviewers using the same formula and exact inputs should derive the same proposed address. That reproducibility is useful: it allows disagreement about the input bytes to be detected before anyone relies on the destination.
It does not show that the deployment transaction has succeeded. It does not show what a contract presently stores or what privileges its operators have. It also does not convert an attractive interface or a familiar-looking address into evidence that the code has been independently examined.
Configuration can matter at the byte level. Where constructor inputs form part of the initialization code, changing those bytes changes an input to the calculation. A reviewer should therefore preserve the complete creation input rather than comparing only a project name or an advertised runtime source file. This is an implementation question that the published formula makes visible, not a performance claim about a token.
Check chain state separately from the proposed address
Record the network, deployer, salt and initialization-code hash used in a calculation. Then check the actual destination on that same network and examine the relevant deployment transaction if one exists. Matching a calculated address is one check; establishing that the expected contract was deployed and behaves as represented is a larger review.
If a project publishes source code or an audit, connect those materials to the deployed artifact rather than assuming that an address match does that work. Also examine any documented upgrade or administrative arrangement when the intended question concerns future control. This article makes no claim about the safety of sending assets to a proposed destination.
EIP 1014 is the historical protocol specification reviewed on 8 October 2026. Its address calculation is the focus here. This article does not treat every historical detail about contract lifecycle behaviour as a statement of all later Ethereum rules.