CREATE3 explained: deterministic smart contract deployment

It is a deployment pattern that composes CREATE2 and CREATE so the final contract address depends on a factory address and a salt, not on the target's bytecode. The technique enables deterministic smart contract deployment across multiple EVM-compatible chains even when the underlying creation code drifts.

Why CREATE and CREATE2 Break Under Cross-Chain Pressure

The EVM exposes exactly two creation instructions: CREATE (0xf0) and CREATE2 (0xf5). CREATE derives the new address from the deployer and the deployer's account nonce. CREATE2 replaces the nonce with a salt and the keccak256 hash of the init code.

Two constraints follow.

CREATE alone forces nonce synchronization across every chain. One emergency transaction on a single network, and every future address on that chain diverges until nonces are padded elsewhere.

CREATE2 binds the predicted address to the exact creation bytecode. Change a constructor argument, recompile, or shift the compiler metadata hash embedded in Solidity output, and the address shifts with it.

Neither primitive satisfies the integration requirement 1inch describes for its own multi-chain deployments: a stable address that survives bytecode drift and remains reproducible from any deployer transaction.

How CREATE3 Composes the Two

The CREATE3 pattern removes the init-code hash from the dependency surface. The final address derives from the factory address and the salt. The factory itself uses CREATE2 internally. Construction arguments and bytecode changes no longer perturb the predicted address.

Two conditions must still hold to reproduce the same target address across chains:

• The factory contract must be deployed at the same address on every target chain.
• The factory's deployed bytecode must match the reference chain, byte for byte.

The 1inch walkthrough frames CREATE3 as a wrapper, not a new opcode. It traces address derivation through the factory contract rather than through the deployer's nonce or the init-code hash. That decoupling is the entire point of the pattern.

Audit Checklist Before Reuse

Before reusing a CREATE3 address on a new chain, verify each of the following:

• The factory address is reproduced on the target chain, not assumed.
• The factory's deployed bytecode matches the reference chain exactly.
• The salt is generated and stored without any chain-specific state dependency.
• The target contract's storage layout is identical across deployments. CREATE3 stabilizes the address. It does not stabilize storage.

The pattern is a deterministic deployment primitive. It is not a compatibility layer. Both invariants must hold for a safe cross-chain rollout, and a missed invariant on either side reproduces the same kind of silent failure that CREATE2 already exhibits on bytecode drift.

Capital continues to move into adjacent tooling plays across the broader stack, including Astute's €1M pre-seed to automate B2B creator partnerships.