Using Solidity immutable variables to reduce gas costs

Why use immutable variables in Solidity

Immutable variables are declared with the immutable keyword, assigned exactly once in the constructor, and their values are embedded in the contract's creation bytecode. After deployment they behave like read‑only state variables but reading them costs less gas because the compiler replaces each read with a PUSH of the embedded value instead of a storage SLOAD.

Worked example

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Token {
    string public immutable name;
    string public immutable symbol;
    uint8 public immutable decimals;

    constructor(string memory _name, string memory _symbol, uint8 _decimals) {
        name = _name;
        symbol = _symbol;
        decimals = _decimals;
    }

    function getInfo() external view returns (string memory, string memory, uint8) {
        return (name, symbol, decimals);
    }
}

When the contract is deployed, the values passed to the constructor become part of the creation bytecode. The getter functions name, symbol and decimals are automatically generated as public view functions; each returns the embedded constant via a PUSH instruction.

Verifying the bytecode substitution

1. Compile the contract with solc --asm Token.sol (requires a locally installed Solidity compiler, version ≥0.6.5).
2. In the generated assembly look for PUSH opcodes immediately after the constructor code; they will contain the UTF‑8 encoded strings and the decimal value.
3. Alternatively, deploy the contract to a local testnet (e.g., Hardhat or Remix) and call eth_getCode on the deployed address; the runtime bytecode will show the same PUSH sequences.

No actual output is shown here; you can confirm the presence of the expected PUSH instructions by inspecting the assembly yourself.

Gas‑cost comparison

Calling the immutable getter name() typically costs around 3 gas (the exact number depends on the optimizer and EVM version) whereas reading a regular string state variable costs roughly 2100 gas for a SLOAD plus the cost of copying the data. The difference becomes noticeable when the getter is invoked frequently in loops or by other contracts.

Limits and common mistakes

• Size impact on deployment. Because the value is baked into the creation bytecode, each immutable adds its encoded size to the contract’s deployment transaction. Large strings, long arrays or big structs can make deployment prohibitively expensive.
• Not a replacement for constant. constant values are resolved at compile time and cannot depend on constructor arguments. If you need a value that is known only after deployment (e.g., an address passed in), you must use immutable.
• Reassignment error. Attempting to assign to an immutable outside the constructor yields a compile‑time error such as TypeError: Immutable variable ... cannot be assigned. The compiler prevents the mistake, but moving the assignment to a function (thinking it will work) is a common source of confusion.
• Libraries. immutable variables cannot be declared inside a library; doing so triggers ParserError: Expected ';' but got 'immutable'. Use internal or public state variables in the library if needed, or pass values as arguments.
• CREATE2 does not change immutables. The salt used with CREATE2 only affects the contract address; the immutable values are still set by the constructor arguments and cannot be altered by the salt or initcode.

Practical checklist

1. Declare the variable with immutable and assign it once in the constructor.
2. Keep the value reasonably sized (prefer short strings, small numbers, or fixed‑size arrays).
3. Verify the bytecode contains the expected PUSH instructions using solc --asm or a block explorer after deployment.
4. Use the built‑in gas profiler in Remix or Hardhat to compare getter costs against a regular state variable if you need quantitative proof.