Track 4 · Solidity foundations · lesson 12

Constructors and immutability

8 min

A constructor runs exactly once, during deployment, and then ceases to exist — it is not part of the deployed bytecode and can never be called again.

Badge.solComplete

Loading editor…

Set the name from the argument, and record the creator.

Run the code to see what happens.

Nudge

Both state variables need a value, and both values are already in scope.

Show me the approach

The argument is `startingName`. The deployer is `msg.sender` — during construction, that is whoever sent the deployment transaction.

Show me the code

Assign `name = startingName;` and `creator = msg.sender;`.

Explain the solution

`creator` is `immutable`, so it must be set exactly once during construction and can never change. Immutables are baked into the bytecode rather than stored, which makes reading them far cheaper than a normal state variable — a free optimisation for anything set once at deploy.

Three ways to fix a value

uint256 public constant MAX_SUPPLY = 10000;      // known when you write it
address public immutable creator;                 // known when you deploy it
address public owner;                             // can change later

constant — fixed at compile time. Costs nothing to read; the value is inlined wherever it appears.
immutable — set once in the constructor, never again. Baked into the bytecode at deployment, so reading it is far cheaper than storage.
plain state variable — lives in storage, costs ~2,100 gas to read cold.

Reach for immutable for anything set once at deploy and never changed: an owner, a token address, a start time.

It is a free optimisation — same code, cheaper reads — and it is also a security statement. A reader can see at a glance that this value can never be changed by anyone, including the deployer.

Predict

Why is reading an `immutable` cheaper than reading a normal state variable?

It is written into the contract's bytecode, so there is no storage read at allThe compiler caches it in memory on first readImmutable values are smaller

The constructor is not on-chain

This surprises people. Deployment bytecode and runtime bytecode are different things: the deployment bytecode runs the constructor, then returns the runtime bytecode, which is what gets stored at the address.

The constructor is discarded. There is nothing to call.

Why a contract can be at an address before it has codeOptional

During construction, the contract has an address but no runtime code yet. If the constructor calls out to another contract, and that contract checks addr.code.length == 0 to decide "is this an EOA or a contract?", it gets the wrong answer.

That check is a real pattern — used to block contracts from minting an NFT, for example — and this is exactly how it gets bypassed. Do the whole thing from inside a constructor and you look like a plain account.

You will use this trick in track 7.

Check

Can you call a constructor again after deployment to reinitialise a contract?

Yes, if it is marked publicNo — the constructor is not part of the deployed codeOnly the original deployer can

Worth remembering

A constructor runs once at deployment and is not part of the deployed bytecode.
`constant` is fixed at compile time; `immutable` is fixed at deployment; a plain state variable can change.
Immutables are patched into the bytecode, making them much cheaper to read than storage.
During construction a contract has an address but no code, which defeats `code.length == 0` checks.
Upgradeable proxies replace constructors with `initialize()` — and an unprotected one is a known way to lose a contract.