smom-dbis-138/docs/operations/status-reports/CREATE_VS_CREATE2_ADDRESSES.md

CREATE vs CREATE2: Can We Match Ethereum Mainnet Addresses?

Question: If we use CREATE to deploy WETH9, will it have the same address as Ethereum Mainnet?

Answer: ❌ NO - It will NOT have the same address.

---

How CREATE Calculates Addresses

The CREATE opcode calculates the contract address using:

address = keccak256(rlp([deployer_address, nonce]))

Where:

• deployer_address: The address that sends the deployment transaction
• nonce: The transaction count (nonce) of the deployer address on that specific chain

---

Why CREATE Cannot Match Mainnet Addresses

Problem 1: Different Deployer Address

• Ethereum Mainnet WETH9: Deployed by a specific address (the original deployer)
• Your Deployment: Deployed by your address (different from original)
• Result: Different deployer = different address calculation

Problem 2: Nonce is Chain-Specific

Even if you could use the same deployer address, the nonce is chain-specific:

• Ethereum Mainnet: Deployer's nonce = X (number of transactions on Mainnet)
• ChainID 138: Deployer's nonce = Y (number of transactions on ChainID 138)
• Result: Different nonce = different address

Problem 3: Chain Context

The RLP encoding and address calculation are done in the context of the specific chain, so even with identical parameters, the chain context matters.

---

Example Calculation

Ethereum Mainnet WETH9

Deployer: 0xOriginalDeployer
Nonce: 0 (first transaction from that address on Mainnet)
Address: 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2

Your Deployment on ChainID 138 (CREATE)

Deployer: 0xYourAddress (different!)
Nonce: 0 (first transaction from your address on ChainID 138)
Address: 0xDifferentAddress (will be different)

Even if you somehow used the same deployer address:

Deployer: 0xOriginalDeployer (same)
Nonce: 0 (on ChainID 138, not Mainnet)
Address: Still different (because nonce is chain-specific)

---

Comparison: CREATE vs CREATE2

Aspect	CREATE	CREATE2
Address Formula	keccak256(rlp([deployer, nonce]))	keccak256(0xff || deployer || salt || keccak256(bytecode))
Deterministic	❌ No (depends on nonce)	✅ Yes (if parameters match)
Cross-Chain	❌ No (nonce is chain-specific)	✅ Yes (if deployer/salt/bytecode match)
Can Match Mainnet	❌ No	⚠️ Possibly (if originally deployed with CREATE2)

---

Can We Match Ethereum Mainnet WETH9 Address?

Using CREATE: ❌ NO

• Different deployer address
• Nonce is chain-specific
• Impossible to match

Using CREATE2: ❌ NO (for WETH9)

• WETH9 on Mainnet was deployed with CREATE (not CREATE2)
• Even with CREATE2, we can't replicate a CREATE-deployed address
• Impossible to match

---

What About WETH10?

Using CREATE: ❌ NO

• Same issues as WETH9
• Impossible to match

Using CREATE2: ⚠️ POSSIBLY

• If WETH10 on Mainnet was deployed with CREATE2
• Need: Same bytecode + same deployer + same salt
• May be possible if we have the original deployment parameters

---

Conclusion

Using CREATE will NOT give you the same address as Ethereum Mainnet.

The only way to potentially match a Mainnet address is:

1. The contract was originally deployed with CREATE2
2. You use CREATE2 with the exact same parameters (bytecode, deployer, salt)

For WETH9, this is impossible because it was deployed with CREATE.

For WETH10, it's possibly if it was deployed with CREATE2 and we can replicate the parameters.

---

Recommendation

Since we cannot match Ethereum Mainnet addresses:

1. Use CREATE2 for deterministic addresses (same address across deployments if parameters match)
2. Use CREATE for simplicity (current method, but addresses will differ)
3. Document the addresses clearly so users know they're different from Mainnet

The choice depends on whether you need:

• Deterministic addresses: Use CREATE2
• Simplicity: Use CREATE (current method)