CREATE2 addresses: prefunding does not prove a deployed wallet
A CREATE2 address can receive assets before the intended contract is deployed. A balance at that address does not establish that deployment is possible, that initialization succeeded or that the intended owner can control the assets. Research the address formula and the deployment lifecycle separately.
An empty-code address also does not automatically identify an ordinary private-key account. The evidence can support an undeployed counterfactual address, a different account history or an unresolved case. Classification requires more than a balance and one current code query.
Reconstruct the address inputs
EIP-1014, Specification and Clarifications, defines CREATE2’s address construction using the deploying address, salt and initialization-code hash. It distinguishes initialization code from the runtime bytes the initialization produces, and describes the nonzero-nonce or nonempty-code collision conditions.
The formula is the final twenty bytes of Keccak-256 applied to 0xff, the twenty-byte deploying address, a thirty-two-byte salt and the thirty-two-byte Keccak-256 hash of initialization code. The outer preimage is therefore 1 + 20 + 32 + 32 = 85 bytes, regardless of the initialization code’s original length.
Preserve actual bytes, not just a factory brand or a readable salt. A text string containing hexadecimal characters is different from the bytes it represents. SHA3-256 from a library that implements that different hash must not be silently substituted for Ethereum’s Keccak-256.
What the factory field means
Identify the address executing CREATE2 in the relevant execution context. An interface’s transaction recipient or a proxy implementation label does not automatically supply that field. Save the actual deployment path or explain why it remains unverified.
Retain the complete initialization bytes, including any encoded constructor arguments. If an intended owner is encoded there, changing the owner can change the initialization-code hash and resulting address. Comparing only the runtime template would miss that difference.
The formula itself does not include a separate chain-ID field. The same input bytes on two compatible networks can produce the same address, but that does not establish equal factory state, code dependencies, asset identity or operational rights across those networks.
A hypothetical prefunded address
Assume a fictional network with CREATE2 enabled. Factory F, salt S and initialization byte sequence I derive address A. The exact inputs are retained in a private evidence packet; symbolic labels here do not stand for a real wallet or deployable instruction.
At H0, A has 5 ETH, empty code and nonce zero. An authenticated project statement says A is the intended wallet address. No successful creation trace or owner-policy evidence has yet been obtained.
| Stage | A balance | Code and creation evidence | Supported statement |
|---|---|---|---|
| H0 prefunding | 5 ETH | Empty code; nonce zero | Value exists at the derived address under the stated observation |
| H1 failed creation attempt | 5 ETH in this assumption | Attempt reverted; no resulting runtime code | Deployment success has not been established |
| H2 separately successful creation | 5 ETH, assuming no other flow | Successful creation and verified resulting code | Specified code now exists at A |
| Control review | Not determined by balance | Initialization and authorization rules checked separately | Only the inspected control policy is supported |
The example assumes no additional value, fees charged to A or other balance movements between those observations. Therefore the five ether is not new deployment revenue at H2: it was already present at H0.
Neither the formula nor the 5 ETH proves that the factory exposes a usable creation path for I and S. Factory permissions, constructor requirements, gas and environmental dependencies still need evidence. An address calculator cannot perform those checks by producing a plausible result.
Creation evidence and control evidence differ
Inspect a proposed or completed creation through the actual execution path and resulting state. Distinguish an application request, an attempted CREATE2 operation, successful initialization and the expected runtime code. A generic outer transaction success flag may not prove every nested creation succeeded.
Then inspect ownership initialization and the functions that can move the held assets. A nonempty runtime bytecode proves code exists, not that the intended owner controls it. A contract with the wrong owner or no applicable asset-release path can be deployed successfully and still fail the research claim.
Simulations are conditional evidence. Preserve their input state and assumptions, and do not call a successful simulation a completed deployment. A later state change can invalidate the conditions under which the simulated result was obtained.
Different boundary: successful creation can leave empty runtime code
Initialization code can finish without returning useful runtime code. An empty-code observation alone therefore cannot prove that an address has never undergone successful creation. Examine nonce, historical traces and applicable rules together.
Under the collision conditions described in EIP-1014, a nonzero destination nonce can prevent a further creation even if current code is empty. A prefunded balance by itself is not one of those stated collision tests. These distinctions explain why code, nonce and balance belong in separate columns.
Do not extend this observation into a universal recovery claim. Historical destruction rules and other account changes require their own version-specific investigation. This worksheet establishes the evidence needed to distinguish address derivation from a usable deployed wallet.
Keep expected initialization and observed runtime as distinct byte objects. Hashing I into the address does not mean I is the code later returned by a code query. A report comparing those two hashes directly can manufacture a deployment mismatch even when initialization behaved exactly as specified. Record which object each hash describes before drawing a control conclusion.
If the initialization reads external state, preserve that dependency in a simulation or historical replay. Identical initialization bytes do not by themselves establish that every environment returns identical runtime or owner settings. The formula fixes an address construction; successful, intended behavior still needs execution evidence.
A reproducible address-and-control checklist
| Check | Retain | Failure interpretation |
|---|---|---|
| Fix the network and rules | Chain identity and activation context | Matching addresses do not establish matching state |
| Identify the deploying address | Actual CREATE2 context | A displayed factory name is insufficient |
| Reconstruct the formula | Salt, complete initialization bytes and hash method | A changed argument can target another address |
| Observe prefunding | Balance, nonce, code and block hash | Balance alone does not establish deployment |
| Verify creation | Trace, result and runtime identity | Attempt or simulation is not completed creation |
| Verify control | Initialization and actual authorization paths | Deployed code is not proof of intended ownership |
Reopen the record after a factory-policy change, corrected initialization bytes, creation attempt or newly recovered historical state. Report derived address, observed assets, deployment status and control status independently. That preserves the useful prefunding evidence while preventing a future-wallet promise from being presented as a currently operational custody arrangement.
FAQ
Does sending assets to the predicted address prove the wallet exists?
No. The transfer can establish value at the address while creation and control remain unresolved.
Does empty code prove another CREATE2 deployment will succeed?
No. Nonce and collision conditions, factory access and initialization requirements also matter.