Deployment bytecode becomes contract code when the Ethereum Virtual Machine executes it and stores the bytes it returns.

Takeaways: Initcode is temporary constructor logic; runtime bytecode is what remains at the address. The constructor can write storage and assemble code, but it is not callable afterward. Deployment cost comes from execution, calldata, account creation, and the size of the returned code.

Initcode and runtime code are different

Initcode is the temporary program supplied during contract creation, while runtime bytecode is the program saved to the account after initcode finishes.

A Solidity compiler therefore produces creation bytecode containing two jobs: constructor logic and the runtime program. Constructor arguments are normally appended to that creation bytecode. The constructor can set initial storage, check conditions, copy embedded data, and insert immutable values into the final code. An Automated Market Maker might use this stage to record token addresses or a fee recipient before its functions become available.

The deployment path

A contract creation transaction supplies initcode to the EVM, which executes it in a new account context and treats its return data as the proposed contract code.

1. A transaction with no normal recipient starts creation, or an existing contract executes CREATE or CREATE2 with an initcode slice in memory.
2. The EVM runs the initcode. It may read constructor input, write storage, transfer value, or revert. The new address exists during this process, but it has no usable runtime code yet.
3. The initcode executes RETURN, specifying an offset and length in memory. Those returned bytes, not the whole creation program, become the runtime bytecode.
4. The client checks protocol limits and charges the code-deposit cost. If deployment succeeds, the account stores the code hash and the returned bytes; later calls execute those bytes.

If the constructor reverts, runs out of gas, exceeds a size limit, or returns invalid output, no usable contract code is installed. Storage changes made during the failed creation are reverted as well. This is why inspecting a transaction’s input does not tell you directly what code ended up at the address: the constructor may have generated, trimmed, or copied it.

Where the deployment cost goes

The deployer pays gas for every resource consumed before the account becomes usable.

The transaction pays calldata gas for the initcode bytes, execution gas for every constructor operation, and a code-deposit charge for each byte returned as runtime code. EIP-3860 also meters initcode in 32-byte words and limits its size. Under the current Ethereum Network rules, runtime code is limited to 24 KiB and initcode to 48 KiB.

Under EIP-1559, the base-fee portion is burned and the priority fee goes through the block-production market to the validator or proposer. Nothing automatically pays the contract creator for deploying code. The price shifts with network demand, the constructor’s work, the amount of initcode, and the size of the final code. A large ERC-20 Standard implementation can therefore be expensive even when its constructor does almost nothing.

Choosing CREATE or CREATE2

CREATE derives the address from the creator and its nonce, while CREATE2 derives it from the creator, a salt, and the hash of the exact initcode.

CREATE is the ordinary choice when the deployer can accept a nonce-dependent address. CREATE2 is useful for factories, counterfactual contracts, and deployments that must be planned before the contract exists. Its important detail is that the address commits to initcode, not merely to the runtime bytecode. Changing constructor arguments or embedded metadata changes the address even if the constructor eventually returns identical code.

The broader Frax Swap context is available at telegra.ph.