Constants and Immutables
Gas-efficient values.
Constants and Immutables is a free Web3 & DApp Development Fundamentals lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Web3 & DApp Development Fundamentals learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Fixed Values Save Gas
Some values never change after a contract is deployed. For these, Solidity offers constant and immutable keywords that store the value in the contract bytecode instead of expensive storage slots.
Using them reduces gas and signals intent to readers.
Declaring Constants
A constant must be assigned at the point of declaration and known at compile time. Its value can never change.
By convention constants use UPPER_CASE names.
<code>uint256 public constant MAX_SUPPLY = 1000000;
string public constant NAME = 'MyToken';</code>How Constants Work
A constant does not occupy a storage slot. The compiler inlines its value everywhere it is used, so reading it costs almost nothing.
This makes constants ideal for configuration like decimals, caps, and fixed fees.
<code>uint8 public constant DECIMALS = 18;
function unit() public pure returns (uint256) {
return 10 ** DECIMALS; // inlined at compile time
}</code>Declaring Immutables
An immutable variable is set once, either at declaration or in the constructor, and then can never change.
Unlike constants, its value can depend on runtime data such as deployment arguments.
<code>address public immutable owner;
constructor() {
owner = msg.sender; // set at deploy time
}</code>Constant vs Immutable
The key difference is when the value is fixed:
constant- fixed at compile time, must be a literal expressionimmutable- fixed at deploy time, can use constructor inputs
Both are stored in bytecode, not in storage slots.
Immutable with Constructor Args
Immutables shine when each deployment needs different fixed parameters, like a token's total supply or an associated contract address.
<code>uint256 public immutable cap;
constructor(uint256 _cap) {
cap = _cap; // unique per deployment
}</code>Gas Savings
Reading a regular state variable requires an SLOAD (storage read), which is costly. Constants and immutables are read directly from bytecode, which is far cheaper.
Converting frequently-read fixed config to constant/immutable is an easy optimization.
<code>// Expensive: storage read each call
uint256 public feeStorage = 100;
// Cheap: read from bytecode
uint256 public constant FEE = 100;</code>What Cannot Be Constant
A constant cannot depend on anything computed at runtime. Values like block.timestamp, msg.sender, or storage reads are forbidden for constants.
For those, use immutable instead.
<code>// ERROR: not compile-time known
// uint256 constant T = block.timestamp;
// OK as immutable
uint256 immutable deployedAt;
constructor() { deployedAt = block.timestamp; }</code>Immutables Are Read-Only
After the constructor finishes, an immutable can never be reassigned. Any attempt to write to it outside the constructor is a compile error.
<code>address public immutable factory;
constructor(address f) { factory = f; }
function change(address x) public {
// factory = x; // ERROR: cannot assign
}</code>Common Use Cases
Typical patterns:
constantfor token decimals, max supply caps, and fixed fee ratesimmutablefor the owner, deployment timestamp, and linked contract addresses
Both improve clarity and reduce gas compared to mutable state.
<code>uint8 public constant DECIMALS = 18;
address public immutable deployer;
constructor() { deployer = msg.sender; }</code>Naming Convention
By widespread convention, constant names are written in UPPER_SNAKE_CASE, while immutable names often use normal camelCase or a leading underscore for constructor params.
Consistent naming makes audits faster.
<code>uint256 public constant MAX_HOLDERS = 500;
address public immutable treasury;</code>Quick Check
Test your understanding of constants and immutables.
Recap
You learned about gas-efficient fixed values:
constant- compile-time literal, inlined into bytecode, UPPER_CASEimmutable- set once at deploy time (often in the constructor), then read-only- Both avoid expensive storage reads (SLOAD)
Use constants for known literals and immutables for per-deployment configuration.
Frequently asked questions
Is the “Constants and Immutables” lesson free?
Yes — the full text of “Constants and Immutables” is free to read here on the web, and the Web3 & DApp Development Fundamentals course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Web3 & DApp Development Fundamentals course, upgrade to CoddyKit PRO.
What will I learn in “Constants and Immutables”?
Gas-efficient values. You practise Web3 & DApp Development Fundamentals with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Web3 & DApp Development Fundamentals?
No prior experience is required. Web3 & DApp Development Fundamentals on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Constants and Immutables” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Web3 & DApp Development Fundamentals lesson?
Yes. Every Web3 & DApp Development Fundamentals lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Value Types
- Reference Types
- Storage vs Memory
- Constants and Immutables