CREATE3: Deploying Contracts to the Same Address Across Multiple Chains

This article explores CREATE3, its purpose, implementation, and key considerations for developers working with multi-chain decentralized applications (dApps).

Understanding Multi-Chain Contract Deployment

EVM-compatible chains have proliferated, creating demand for solutions that enable dApps to maintain identical contract addresses across different blockchains. This simplifies management and ensures consistent integration points for frontends, backends, and other contracts.

Current EVM deployment opcodes include CREATE and CREATE2. While EIP-3173 proposed adding CREATE3, its functionality can be implemented via smart contracts, eliminating the need for a new opcode.

Core Deployment Methods Compared

CREATE: The Foundational Approach

Purpose:
Deploys new contracts during contract execution.

Limitations:
Contract addresses depend on sender_address and sender_nonce, making identical multi-chain addresses difficult to achieve:

address = keccak256(rlp([sender_address, sender_nonce]))[12:]

CREATE2: Deterministic Address Generation

Purpose:
Generates addresses based on init_code rather than sender_nonce, making addresses predictable after compilation.

Challenges:

• init_code includes constructor parameters
• Varying parameters across chains result in different addresses

address = keccak256(0xff + sender_address + salt + keccak256(init_code))[12:]

CREATE3: Unified Multi-Chain Addressing

Purpose:
Generates identical addresses across chains regardless of init_code differences by relying solely on sender_address and salt.

CREATE3 Implementation Workflow

1. Prerequisite: Identical CREATE3 Factory addresses exist across all target chains
2. Deployment: Developer sends transaction with salt and init_code to CREATE3 Factory
3. Proxy Deployment: Factory uses CREATE2 to deploy CREATE2 Proxy with fixed init_code
4. Final Deployment: CREATE2 Proxy executes CREATE to deploy the target contract

Address Calculation:

new_address = keccak256(rlp([create2_proxy_address, 1]))[12:]
create2_proxy_address = keccak256(0xff + create3_factory_address + salt + keccak256(fixed_init_code))[12:]

Technical Deep Dive: Fixed Init Code

The CREATE2 Proxy uses optimized bytecode:

67_36_3d_3d_37_36_3d_34_f0_3d_52_60_08_60_18_f3

Key components:

• 36~f0: Handles init_code copying and CREATE execution
• Gas-saving techniques using RETURNDATASIZE (0x3d)
• Efficient address calculation via RLP encoding

CREATE3 Factory Deployment Options

1. New EOA Method:

   • Use fresh EOA with identical first transaction (nonce=0) across chains
   • Requires native tokens for gas on each chain

2. Existing Factory:

   • Leverage pre-deployed factories like create3-factory
   • Includes additional hashing for address uniqueness
   • Limited to chains where factory exists

Critical Considerations for Developers

1. Constructor Context:

   • msg.sender in constructors will be CREATE2 Proxy
   • Adjust ownership transfer patterns accordingly

2. Deployment Safety:

   • Verify init_code thoroughly to prevent address occupation
   • Account for additional gas costs from proxy deployments

3. Process Complexity:

   • Increased deployment steps require careful monitoring
   • Chain-specific parameter handling remains necessary

Frequently Asked Questions

Why would I need identical addresses across chains?

Identical addresses simplify:

• Contract management
• Frontend integration
• Cross-chain contract interactions

Does CREATE3 replace CREATE2?

No, CREATE3 builds upon CREATE2 functionality for specific multi-chain use cases where address consistency is paramount.

How does CREATE3 handle constructor parameters?

While parameters can vary across chains, they don't affect the final contract address thanks to the proxy deployment pattern.

What are the gas implications of CREATE3?

Expect higher costs due to:

• Proxy contract deployment
• Additional computation steps
• Multi-chain deployment requirements

Conclusion

CREATE3 represents an evolution in deterministic contract deployment, reducing address-generation variables from nonce to init_code to just sender_address and salt. While powerful, developers must carefully consider:

• Constructor logic adjustments
• Deployment process complexity
• Additional gas costs
• Chain-specific implementation requirements

👉 Explore advanced smart contract deployment strategies

The protocol offers significant advantages for multi-chain dApp developers while demanding greater attention to implementation details. By understanding these tradeoffs, teams can effectively leverage CREATE3 for streamlined cross-chain operations.

👉 Learn more about EVM development best practices