Ethereum Contract Creation: Init Code and the Resulting Address

An Ethereum contract creation transaction has no ordinary destination address. It carries compiled contract code, and a successfully deployed contract has an address of its own. Those statements describe different parts of creation: what the transaction specifies and what deployment produces.

The distinction becomes clearer when you separate three things: the transaction’s destination field, the code involved in initialization, and the receipt’s contractAddress field. This article explains their relationship through a hypothetical record, without requiring a deployment procedure. For broader background, see our introduction to smart contract code, state, and calls.

Why a creation transaction has no normal destination

In the transaction object described by Ethereum’s JSON-RPC documentation, to normally identifies the receiver. For a contract creation transaction, that field is null. Here, null means there is no ordinary receiver address in that field; it is not itself an address.

Ethereum’s deployment documentation describes creation through a transaction containing compiled contract code without a specified recipient. This gives the missing destination a concrete context: the transaction concerns creation rather than a request directed to an existing recipient.

Keep the representation and the concept separate. A description of the transaction may say that no recipient is specified, while the returned JSON-RPC object represents its destination as to: null. Read that field according to its documented role. There is no need to replace it mentally with the address that appears after successful creation.

Init code and deployed code describe different stages

For this conceptual explanation, init code means the code involved in the creation stage. Deployed code means the final contract code stored after creation. This terminology is an explanatory deduction from the documented creation process, rather than a complete specification of the creation payload.

The premises come from the Solidity contracts documentation: a constructor executes once when a contract is created, a constructor can run initialization code, and the final contract code is stored after the constructor has executed. Solidity also explicitly excludes constructor code and internal functions called only from the constructor from the deployed code.

These details support a useful distinction between code used during creation and code that remains deployed. They do not justify treating the constructor alone as the entire init code, or assuming that the transaction’s compiled payload is simply an unchanged copy of the final deployed code.

Imagine labeling two folders in a classroom exercise: one for creation-stage code and another for final deployed code. The labels help organize the explanation. They do not show individual instructions, the full payload layout, or how any particular compiler output compares byte for byte. At this level, the important point is the different role each stage serves.

Where the resulting contract address appears

Once deployed, a contract has an Ethereum address. In the documented transaction receipt, contractAddress reports the address created by contract creation; otherwise, that field is null. The destination field and the created-address field therefore need separate readings.

A transaction’s hash identifies the transaction. Identifying that transaction does not, by itself, establish that creation succeeded or supply its resulting contract address. The receipt supplies the creation-result field discussed here.

Execution status also matters. For receipts that use status, the documentation defines 1 as success and 0 as failure. The same documentation separately describes historical pre-Byzantium receipts using root; the status explanation here concerns receipts that contain status.

A pending transaction has no available receipt. Consequently, the hypothetical completed record below should not be assumed to exist while a transaction remains pending. A missing receipt alone is not a complete diagnosis of a transaction’s circumstances. These field definitions come from Ethereum’s JSON-RPC documentation.

A hypothetical creation record, read carefully

Suppose an invented classroom example contains a creation transaction and its matching receipt. Stipulate that creation completed successfully. Use the labels Transaction T and Address C as placeholders; neither is an actual hash or address, and no address calculation is implied.

• Transaction identifier: Transaction T.
• Transaction destination: to: null.
• Transaction input: compiled creation-stage code, stipulated for this exercise.
• Matching receipt status: 1, meaning success.
• Matching receipt contractAddress: Address C.

The supported deduction is that the null destination and the reported created address are consistent. Its premises are the stipulated successful creation and the documented meanings of to, status, and contractAddress. The destination describes the receiver field of the transaction; Address C describes the creation result in the matching receipt.

This deduction is limited to the setup given. It does not establish that an arbitrary submitted transaction completed successfully, and it does not specify the value of every receipt field after failed creation. The example also supplies no actual code from which to analyze the hypothetical contract’s behavior.

A checklist for reading a creation record

Use these questions when studying a supplied transaction record. They organize the evidence needed for this particular interpretation:

1. Which field are you reading? Distinguish the transaction’s to field from the receipt’s contractAddress.
2. What does the destination show? In the documented creation transaction object, expect null rather than an ordinary receiver address.
3. Which code stage is being described? Keep initialization and final deployed code distinct, especially when constructor code is discussed.
4. Is a receipt available? Pending transactions do not have an available receipt.
5. What outcome is supported? Where status is present, read its success or failure value alongside the created-address field.
6. What assumptions remain? Keep hypothetical labels, stipulated success, and missing details visible in the explanation.

For surrounding transaction fields, our guide to reading an Ethereum transaction in a block explorer provides related context. The focus here remains the relationship between a creation transaction, its initialization stage, and its resulting address.

This educational article was prepared with AI assistance. The invented record is a reading exercise.