Track 3 · Ethereum & the EVM · lesson 6

Where contract addresses come from

7 min

A contract's address is not random and not chosen. It is computed — and with the right method, computed before the contract exists.

CREATE: deployer plus nonce

The ordinary way. The address is the hash of the deploying address and its nonce:

address = keccak256(rlp([deployer, nonce]))[12:]

Deterministic, and mildly alarming in its consequences.

Deploy from a fresh account and your first contract's address depends only on your address and a nonce of 0. Anyone can compute it in advance.

It also explains a confusing thing beginners hit constantly: deploying the same contract from the same fresh account on two different chains produces the same address on both. Same deployer, same nonce, same arithmetic.

Predict

Your deployer account has sent 5 transactions. What decides your next contract's address?

The contract's bytecodeYour address and the nonce, 5The block number it lands in

CREATE2: choose your address

CREATE2 swaps the nonce for a salt you pick, and adds the bytecode:

address = keccak256(0xff, deployer, salt, keccak256(bytecode))[12:]

No nonce means no ordering dependency. The same deployer, salt and bytecode always produce the same address — on any chain, at any time, whether or not the contract has been deployed yet.

That enables genuinely useful things:

Counterfactual deployment. Give someone an address, let them fund it, and deploy only when there is a reason to.
Identical addresses across chains, deliberately rather than by accident.
Smart accounts that exist as an address before anyone pays to create them.

The redeployment trick, and why it was closedOptional

CREATE2 once allowed something unsettling. A contract could selfdestruct, freeing its address, and a different contract could then be deployed to the same address with the same salt.

Users who had approved the original contract were now approving whatever replaced it.

The Cancun upgrade largely closed this by neutering selfdestruct outside the transaction that created the contract. Worth knowing anyway — it is a clean example of how a small composition of features can produce a hazard nobody designed.

Check

Why can CREATE2 produce a known address before deployment while CREATE cannot?

CREATE2 uses a salt you choose instead of a nonce that keeps movingCREATE2 registers the address in advanceCREATE2 addresses are assigned by the network

Worth remembering

CREATE derives an address from the deployer and its nonce — the bytecode is not involved.
The same account and nonce give the same address on every chain, which surprises people constantly.
A stray transaction from the deployer shifts every subsequent contract address.
CREATE2 uses a salt plus the bytecode, giving a stable, predictable address.
That enables counterfactual deployment and deliberate cross-chain address matching.