State

State is your contract’s permanent memory, the data it stores and remembers forever. Think of it like saving information to a database: once it’s written, it stays there until someone changes it.

Every smart contract needs to remember things. A voting contract remembers how many votes each option has. A membership contract remembers who’s on the list. A game contract remembers each player’s score. All of these are examples of stored data.

Types of Stored Data

There are a few different kinds of data your contract can remember:

  • Numbers: Scores, balances, counts, ages, quantities
  • Wallet Addresses: Who owns something, who sent a message, who’s allowed in
  • True / False: Is the contract paused? Has this person voted? Is the door locked?
  • Text: Names, descriptions, messages
  • Lists: A collection of items, like a list of members or a series of scores
  • Mappings: A way to connect one piece of data to another, like “this wallet address has this balance”

Constant and Immutable

Some stored data should never change after it’s set. Solidity gives you two ways to lock a value in place, and both save gas compared to regular state variables.

Constant means the value is baked in at the time you write the contract. It can never be changed, not even during deployment. Use this for values you know ahead of time: a maximum token supply, a version number, or a fixed fee percentage. Think of it like a printed sign that was decided before the building was constructed.

Immutable means the value is set once during deployment (in the constructor) and then locked forever. Use this for values that depend on who deploys the contract or when it’s deployed: the deployer’s wallet address, a launch timestamp, or a linked contract address. Think of it like an engraving on a cornerstone: it’s carved during construction and never changed.

The key difference: constant values are known before deployment, immutable values are decided at deployment time. A variable cannot be both constant and immutable.

Toggle these options on any stateVariable node to lock its value.

Try It Yourself

The interactive panel below works just like the real editor. Complete each task to explore the different types of stored data.

Task 1 of 3 Store a Number

Add a number to your contract's memory.

1 Add a Number
2 Name it "score"
3 Done!
Click the + Number chip below to add a number.

Contract Data

Values your contract remembers permanently

No stored data defined yet. Use the buttons below to add one.

What You Learned

By completing the tasks above, you explored three common patterns for storing data:

  • A single value (like “score”): great for tracking one piece of information, such as a total count or a price
  • A mapping (like “balances”): perfect for associating data, such as connecting each user to their balance
  • A list (like “members”): ideal for keeping an ordered collection, such as a roster of wallet addresses
  • Constant values are baked in at write time and never change, saving gas for known-ahead-of-time values
  • Immutable values are set once during deployment and locked forever, ideal for deployer-specific data

These are the building blocks you’ll use to give your contract a memory. In the full editor, you can mix and match as many as you need.

Key Concepts

  • Stored data: Information your contract saves permanently. It persists even after someone stops interacting with the contract.
  • Visibility: Controls who can see the data. Public lets the outside world check it; private keeps it only accessible within the contract; internal makes it accessible to this contract and any contracts that inherit from it (like a family secret).
  • Constant: A value decided before deployment that never changes. Saves gas.
  • Immutable: A value set once during deployment (in the constructor) and locked forever. Saves gas.
  • Lists: An ordered collection of items that can grow or shrink over time.
  • Mappings: A way to pair one piece of data with another, like connecting a name to a phone number.