Same Address on Every EVM Chain: EOAs, CREATE2 and CREATE3

EOAs: one key, one address everywhere

An EOA address is the last 20 bytes of keccak256 of the public key, and the public key depends only on the private key. No chain ID enters the calculation, so the same key controls the same address on Ethereum, Arbitrum, Optimism, Base, Polygon PoS and every other chain that uses Ethereum's account model. The derivation steps are in how Ethereum addresses are derived.

This has practical consequences. Funds sent to your address on the wrong EVM chain are still yours if you hold the key, and you can recover them by adding that network to your wallet. A vanity EOA is a vanity address on every chain at once. Since EIP-155, signed transactions include a chain ID, so a transaction you sign for one chain cannot be replayed on another, but an EIP-7702 authorization signed with chain ID 0 is valid on any chain, so read such requests carefully.

Contracts with CREATE: same address only with the same nonce

CREATE derives a contract address from keccak256(rlp([sender, nonce]))[12:]. To repeat an address on another chain you must deploy from the same account at the same nonce. Teams used to reserve a fresh deployer key and keep its nonces in lockstep across chains, which breaks as soon as one chain receives an extra transaction.

The failure mode is serious: the nonce that would have produced your address on a new chain can be consumed by an unrelated transaction, or the address can stay empty for years until someone deploys there. Anyone who controls the deployer key on that chain decides what code ends up at that address.

Contract factories face the same issue: a factory's nonce starts at 1 and increments with each deployment, so a factory that has deployed different numbers of contracts on two chains will put its next contract at different addresses.

CREATE2 through a shared deterministic deployer

CREATE2, specified in EIP-1014, computes keccak256(0xff ++ deployer ++ salt ++ keccak256(init_code))[12:]. If the same deployer contract exists at the same address on every chain, the same salt and init code give the same contract address everywhere, regardless of who sends the transaction or what nonces are in use.

The most widely used deployer is Arachnid's deterministic deployment proxy at 0x4e59b44847b379578588920cA78FbF26c0B4956C. It is itself deployed by a presigned transaction from a one-time keyless account, so anyone can publish it on a new chain. Calldata sent to it is a 32-byte salt followed by the init code. Because that presigned transaction carries no EIP-155 chain ID, chains that enforce replay protection cannot receive it this way, which is why Safe maintains a separate singleton factory deployed per chain.

CreateX, at 0xba5Ed099633D3B313e4D5F7bdc1305d3c28ba5Ed, is a newer factory that supports CREATE, CREATE2 and CREATE3. It offers salt guards: if the first 20 bytes of the salt equal msg.sender, only that sender can deploy with it, and setting the 21st byte to 0x01 mixes the chain ID into the salt so the address cannot be reproduced on other chains.

CREATE3: address independent of the bytecode

CREATE2 ties the address to the exact init code, so changing a constructor argument per chain changes the address. CREATE3 is a pattern, not an opcode: a factory uses CREATE2 to deploy a tiny proxy with fixed bytecode, and that proxy immediately uses CREATE at its nonce 1 to deploy the real contract. The final address therefore depends only on the factory address and the salt.

That flexibility cuts both ways. CREATE3 lets you deploy different code to the same address on different chains, which is convenient for chain-specific constructor parameters but removes the guarantee that one address means one bytecode. Always verify the deployed code on each chain rather than assuming it from the address.

Practical workflow with Foundry

Foundry uses the deterministic deployment proxy by default. When a Forge script deploys with new Contract{salt: salt}(...), Foundry routes the deployment through 0x4e59b44847b379578588920cA78FbF26c0B4956C, so running the same script with the same salt and bytecode on several chains yields one address. The cast create2 command mines salts for that deployer, with options such as --starts-with, --ends-with, --matching, --case-sensitive and --init-code-hash.

Pin the compiler version, optimizer runs and metadata settings in foundry.toml before mining, since any change alters the init code hash. After deployment, confirm on each chain's explorer that the address holds the expected verified bytecode. If you need a vanity contract address, the EOA vs CREATE2 vanity guide explains the formula you are mining against.

# mine a salt for the default deterministic deployer
cast create2 --starts-with 0000 --init-code-hash <keccak256 of init code>

# deploy in a Forge script with the mined salt
# new MyContract{salt: SALT}(args);
forge script script/Deploy.s.sol --rpc-url $RPC_URL --broadcast

The 20 million OP incident of 2022

In June 2022 the Optimism Foundation sent 20 million OP tokens to a multisig address supplied by market maker Wintermute. The Safe multisig existed at that address on Ethereum mainnet but had not been deployed on Optimism. According to the Optimism Foundation's statement reported by The Block, an attacker deployed the multisig address on Optimism first with different initialization parameters and took control of the tokens.

SlowMist's analysis attributes this to transaction replay: the Safe proxy factory's original Ethereum deployment transaction had no chain ID, so the attacker replayed it on Optimism to recreate the factory at the same address, then created proxies until reaching the expected address with parameters they controlled. Wintermute accepted responsibility for the error. The lesson is that an address being yours on one chain says nothing about who controls it on another until you deploy there yourself.

Checklist for cross-chain deployments

Use these rules whether you deploy a vanity contract or an ordinary one.

• Deploy through a factory that already exists at the same address on every target chain, and confirm it on each chain's explorer first.
• Use permissioned salts so nobody can front-run your salt, as described in EOA vs CREATE2 vanity.
• Never send assets to a contract address on a chain where that contract is not yet deployed.
• Check chains with custom VMs: ZKsync's documentation states that EraVM bytecode uses a different CREATE and CREATE2 address derivation from Ethereum.
• Remember that a mined leading-zero address carries over to every chain with the same deployer, keeping the gas benefit from leading-zero addresses.

Explore the related mechanism

• EOA Vanity Address vs CREATE2 Vanity Contract Address — How a vanity wallet (EOA keypair search) differs from a vanity contract address mined with a CREATE2 salt, with the EIP-1014 formulas.
• How Ethereum Addresses Are Derived from a Private Key — From secp256k1 private key to Keccak-256 hash, last 20 bytes and EIP-55 checksum, with an ethers v6 example and why it is one-way.
• Open the complete workflow guide to place these checks in order.
• Open the address generator when you have chosen a compatible format and pattern.

Sources and editorial method

The technical references below support the concepts discussed in this article. Examples and comparison worksheets are explanatory, not measured service benchmarks.

• Arachnid/deterministic-deployment-proxy on GitHub
• pcaversaccio/createx on GitHub
• The Block: Attacker snipes 20 million OP tokens intended for Wintermute
• SlowMist: Key to the theft of 20 million OP tokens, transaction replay
• Foundry reference: cast create2

Read how these articles are prepared.