Solia saysCREATE derives a contract’s address from sender + nonce; CREATE2 derives it from sender + salt + init-code hash — letting you compute the address before deployment.
CREATE assigns keccak256(rlp(sender, nonce))[-20:] as the address, which changes every time the sender deploys (nonce increments). CREATE2 uses keccak256(0xff ‖ sender ‖ salt ‖ keccak256(initcode))[-20:] — fully deterministic in sender, salt, and code, regardless of nonce. That means you can compute a contract address before it is deployed.
This unlocks two patterns: counterfactual contracts (people interact with an address before it exists, and the contract is deployed when needed) and salt-mined vanity addresses. The demo computes both with a toy hash; the determinism property holds the same way under real keccak256.
Power-ups you unlock
CREATE address = keccak(rlp(sender, nonce))[-20:]
CREATE2 address = keccak(0xff ‖ sender ‖ salt ‖ keccak(initcode))[-20:]
CREATE2 is fully deterministic in sender, salt, and code
Enables counterfactual contracts and address precomputation
Salt mining = brute-force a salt that yields a vanity address
The Reentrancy Reaper attacks — common mistakes
Forgetting CREATE depends on nonce, so it changes every deployment
Computing CREATE2 with the deployed-code hash instead of the initcode hash
Salt-mining without considering the keccak collision space (huge)
Trusting an interaction with a counterfactual address with no commitment
Boss battleCompute CREATE and CREATE2 addresses for the same sender and show CREATE2 stays the same across redeploys.