Using `immutable` Variables to Reduce Runtime Gas in Solidity

Why immutable matters

A normal state variable lives in storage. Reading it requires an SLOAD, which is relatively expensive because the EVM must access persistent contract storage. By contrast, an immutable value is assigned once in the constructor and then embedded directly into the deployed bytecode. At runtime, reading it is much cheaper than reading storage.

This makes immutable especially useful for:

• contract addresses such as routers, tokens, or registries
• protocol parameters set at deployment time
• admin or treasury addresses that never change
• fixed configuration values like fee denominators or precision constants

The key idea is simple: if a value never changes after deployment, do not pay storage costs every time you read it.

How immutable works under the hood

An immutable variable is assigned in the constructor, but unlike a regular storage variable, its value is not stored in a storage slot. Instead, the compiler places placeholders in the runtime bytecode and patches them with the final value during deployment.

That means:

• you can set it only once
• you cannot update it later
• reading it is cheaper than storage access
• it is still part of the contract’s deployed code size

This tradeoff is usually favorable when the value is read often and written never.

Example: storage vs immutable

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

contract StorageConfig {
    address public owner;
    uint256 public feeBps;

    constructor(address _owner, uint256 _feeBps) {
        owner = _owner;
        feeBps = _feeBps;
    }

    function getFeeBps() external view returns (uint256) {
        return feeBps;
    }
}

contract ImmutableConfig {
    address public immutable owner;
    uint256 public immutable feeBps;

    constructor(address _owner, uint256 _feeBps) {
        owner = _owner;
        feeBps = _feeBps;
    }

    function getFeeBps() external view returns (uint256) {
        return feeBps;
    }
}

Both contracts expose the same interface, but the second one avoids repeated storage reads for owner and feeBps.

When immutable is the right choice

Use immutable when the value is known at deployment and will never need to change.

Good candidates

Poor candidates

If a value might change in production, do not force it into immutable just for gas savings. A cheap read is not worth losing operational flexibility.

Gas savings in practice

The runtime benefit comes from replacing storage reads with code-level reads. In many contracts, the same configuration value is accessed in multiple functions, and those reads accumulate.

For example, a DEX adapter may use the same router address in swap, quote, and approveAndSwap. If the router is stored in contract storage, each call pays for a storage read. If it is immutable, the contract can access it at a much lower cost.

The savings are most noticeable when:

• the value is read in hot paths
• the function is called frequently
• the contract is part of a larger system with many internal calls
• the value is used multiple times in a single transaction

A single immutable read may not transform a contract by itself, but in aggregate it can produce meaningful savings across high-volume operations.

Best practices for using immutable

1. Assign values in the constructor only

An immutable variable must be initialized during deployment. Keep constructor validation strict so invalid addresses or parameters cannot be deployed accidentally.

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

contract Vault {
    address public immutable asset;
    address public immutable treasury;

    constructor(address _asset, address _treasury) {
        require(_asset != address(0), "asset=0");
        require(_treasury != address(0), "treasury=0");

        asset = _asset;
        treasury = _treasury;
    }
}

This pattern prevents deploying a contract with unusable configuration.

2. Prefer immutable for addresses and fixed parameters

Addresses are among the best candidates because they are commonly read and rarely changed. Fixed numeric parameters such as basis points denominators, minimum thresholds, or deployment-specific constants are also strong candidates.

3. Keep upgradeability in mind

If you plan to use a proxy-based upgrade pattern, be careful. immutable values are embedded into the implementation bytecode, not stored in proxy storage. That means they are tied to the implementation contract deployment, which may or may not match your upgrade model.

In upgradeable systems, prefer storage variables for values that need to be configurable across upgrades. Use immutable only when the value is truly fixed for the implementation’s lifetime and compatible with your proxy architecture.

4. Expose public getters when useful

Declaring an immutable variable as public generates an accessor automatically. This is often cleaner than writing a custom getter.

address public immutable router;

If you need to compute or normalize the value before returning it, a custom view function may still be appropriate.

5. Avoid overusing immutable for readability

Not every constant-like value should become immutable. If a value is better expressed as a compile-time constant, use constant instead. If it is operationally mutable, keep it in storage. Choose the simplest construct that matches the lifecycle of the data.

immutable vs constant vs storage

These three options solve different problems.

Use constant when the value is known at compile time

Examples:

• uint256 public constant BPS_DENOMINATOR = 10_000;
• address public constant DEAD = address(0xdead);

Use immutable when the value is deployment-specific

Examples:

• address public immutable token;
• address public immutable factory;

Use storage when the value must be mutable

Examples:

• address public owner;
• uint256 public feeBps;

This distinction helps keep your contract both efficient and maintainable.

Practical example: a fee collector contract

The following example shows a realistic use case where immutable improves performance. The contract collects fees in a specific ERC-20 token and forwards them to a treasury address that never changes.

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

interface IERC20 {
    function transferFrom(address from, address to, uint256 amount) external returns (bool);
}

contract FeeCollector {
    IERC20 public immutable paymentToken;
    address public immutable treasury;
    uint256 public immutable feeBps;

    constructor(address _paymentToken, address _treasury, uint256 _feeBps) {
        require(_paymentToken != address(0), "token=0");
        require(_treasury != address(0), "treasury=0");
        require(_feeBps <= 1_000, "fee too high");

        paymentToken = IERC20(_paymentToken);
        treasury = _treasury;
        feeBps = _feeBps;
    }

    function collect(uint256 amount) external {
        uint256 fee = (amount * feeBps) / 10_000;
        require(paymentToken.transferFrom(msg.sender, treasury, fee), "transfer failed");
    }
}

Why this is efficient

• paymentToken is read every time collect runs, but never changes.
• treasury is also fixed and used in every fee transfer.
• feeBps is a deployment parameter that may be read frequently for calculations.

Using immutable here avoids repeated storage reads while keeping the contract simple.

Common pitfalls

Assuming immutable is always cheaper overall

Although runtime reads are cheaper, immutable values are embedded in bytecode. That can slightly increase deployment complexity and code size. For a contract that reads a value only once or twice in its lifetime, the savings may not justify the design change.

Using immutable for values that need governance

A protocol may start with a fixed treasury address, but later require rotation due to key compromise, organizational changes, or a migration. If that possibility exists, use storage and a controlled update function instead.

Forgetting constructor validation

Because immutable values cannot be corrected after deployment, constructor checks are essential. Validate zero addresses, bounds, and invariants before assignment.

Mixing immutable with proxy assumptions

If your team uses proxies, document clearly which values are implementation-level and which are proxy-level. Misunderstanding this can lead to confusing behavior during upgrades.

Design checklist

Before choosing immutable, ask these questions:

1. Is the value known at deployment time?
2. Will it remain valid for the full lifetime of the contract?
3. Is it read frequently enough to justify optimization?
4. Does the contract need upgrade or governance flexibility?
5. Have you validated the value in the constructor?

If the answer to the first three is yes, and the last two are acceptable, immutable is likely a good fit.

Summary

immutable is one of the most practical gas optimizations in Solidity when used for deployment-time configuration that never changes. It reduces runtime storage reads, keeps code readable, and works especially well for addresses and fixed parameters that appear in hot paths.

The main discipline is architectural: choose immutable only for values with a genuinely fixed lifecycle. For mutable governance settings, keep storage. For compile-time values, use constant. When applied carefully, immutable gives you a clean performance win with minimal complexity.

Learn more with useful resources

• Solidity documentation: State Variables
• Solidity documentation: Constant and Immutable State Variables
• Ethereum Yellow Paper