EIP-1014: CREATE2 — knowing an address before the contract exists
A contract's address used to be derived from the deployer's nonce — a counter that changes with every deployment, so you could never predict where a contract would land. CREATE2 derives the address from the deployer, a salt you choose, and the code itself: no nonce. Now you can compute an address, fund it, and hand it out before the contract is deployed at all.
- contract creation & addresses
- keccak256
Constantinople, February 2019. Among its opcodes was one that reads like a footnote — a second way to create a contract — but it quietly unlocked counterfactual wallets, state channels, deterministic factories, and much of how account abstraction assigns addresses. The problem it solves is a chicken-and-egg riddle: can you know a contract’s address before you’ve deployed it? With the original CREATE, the answer was no, and that “no” blocked a whole class of designs. EIP-1014 is CREATE2, and it turns that “no” into “yes.” Let’s derive it.
The problem: CREATE’s address depends on the nonce
When a contract (or account) deploys another with the original CREATE, the new contract’s address is keccak256(rlp(sender, nonce))[12:] — a hash of who deployed it and their nonce A per-account counter: for an EOA it's the number of transactions sent; for a contract it's the number of contracts it has created. It increments with every deployment, so it's different each time and depends on ordering. . The nonce is the catch: it ticks up with every deployment, so the same deployer creating two contracts gets two different, order-dependent addresses. You cannot compute the address ahead of time unless you know exactly how many contracts the deployer will have made first — and once a contract lives at an address, its nonce has moved on, so you can never put another there.
→ Step 2: replace the nonce with inputs you control.
CREATE2: address from sender, salt, and code
CREATE2 The Constantinople opcode (0xf5) that deploys a contract at an address derived from the deployer, a caller-chosen salt, and the init code — deterministically, with no dependence on the nonce. drops the nonce entirely and derives the address from three things you can decide ahead of time: the deployer, a salt A 32-byte value the deployer chooses freely, mixed into the CREATE2 address derivation. Varying the salt yields a different address for the same code; fixing it makes the address reproducible. you pick, and the init code (the exact bytecode being deployed). Because none of these is a moving counter, the same inputs always produce the same address — and, crucially, you can compute it without deploying anything.
- 1 a constant prefix that keeps CREATE2 addresses from ever colliding with CREATE's
- 2 the deployer and a value you choose — both known ahead of time
- 3 commits to the exact bytecode; change the code and the address changes
→ Step 3: use the address before the contract is real.
The payoff: counterfactual deployment
Here’s the move that CREATE2 makes possible. You compute the address, and then you use it before deploying — hand it out, send ETH to it, treat it as real — even though there’s no contract there yet. This is counterfactual deployment Computing a contract's CREATE2 address ahead of time and interacting with it (funding it, referencing it) before deploying — then deploying only when needed. The contract's existence is 'counterfactual' until that moment. . The address can be funded and referenced while it’s empty; later, whoever needs it runs CREATE2 with the same salt and init code, and the contract materializes at exactly that address — with the funds already waiting.