SoliditySolidity Basics (Part 1) — Variables, Functions & Your First Real ContractAfter a short two‑day pause in the 60‑Day Web3 journey, it’s time to hit play again and kick off the next phase with our first steps into Solidity. For the last 25 days, we’ve treated smart contracts like mysterious vending machines: you put in a transaction, and something happens on-chain. Today we finally lift the lid and start reading the language those vending machines are written in: Solidity.
This is Day 26, the start of Phase 3: Development in the 60‑Day Web3 journey. The goal for today is not to become a Solidity expert. The goal is to understand the basic building blocks — variables and functions — and then ship a tiny but real contract to Sepolia: a Web3 Journey Logger.
1. What is Solidity, really?Solidity is a high-level, contract‑oriented programming language used to write smart contracts that run on Ethereum and other EVM-compatible chains like Arbitrum, Optimism, and Polygon. Once compiled, your Solidity code becomes bytecode that lives at a specific address on-chain and is executed by every node that processes your transaction.
If you’ve seen JavaScript, C++, or TypeScript, Solidity will look familiar: curly braces, functions, variables, if conditions. But there are two crucial differences: you’re programming money and state, not just UI, and every operation costs gas while the code you deploy is mostly permanent.
That’s why starting with the basics — how data is stored and how users interact with that data — is so important.
2. Variables: the contract’s on-chain memoryThink of a smart contract as a tiny on-chain application with its own private database. Variables are the named boxes where this contract stores data.
In Solidity, you must always declare both the type and the name of each variable because the compiler wants to know exactly what will be stored where.
2.1 Types of variablesAt a high level, there are three levels of variables:
State variables
Local variables
Global variables
In this first step, the focus is on state variables, since they form your contract’s on-chain memory.
2.2 Common data types you’ll actually useHere are the basic types you’ll see in almost every contract:
bool
uint256
address
string
There are many more types such as int, bytes, mapping, struct, and arrays, but these four are enough to get started.
3. Functions: how users talk to your contractIf variables are the contract’s memory, functions are the doors and buttons users can press to read or update that memory.
Every time someone calls a function via a transaction or a UI like a dApp, the EVM executes the function’s logic step by step.
3.1 Function anatomyA typical Solidity function looks like this:
function setDay(uint256 _day) public {In this example, setDay is the function name, uint256 _day is the input parameter, public is the visibility specifier, and the body between braces updates the dayNumber state variable.
3.2 Visibility (who can call this?)Visibility controls who can call a function and from where:
public
external
Other options like internal and private are used for helper functions and will appear later as contracts become more modular.
Note: setEntry is marked public but usually called externally; external could be slightly cheaper.
Solidity requires you to be explicit about how a function interacts with state:
view
pure
Example:
function getDay() public view returns (uint256) {Instead of another generic “Simple Storage” example, this article builds a Web3 Journey Logger contract that ties directly into a learning challenge.
The contract will:
This small contract is enough to show how variables and functions come together in a real, personal use case.
4.1 What the contract should doThe Web3 Journey Logger has a few core behaviors:
These requirements map cleanly to a handful of state variables and two or three functions.
4.2 Full contract codeHere is a complete version of the Web3 Journey Logger contract:
// SPDX-License-Identifier: MITThis minimal contract demonstrates state variables, a constructor, a state‑changing function with a simple access control check, and a view function that returns multiple values.
5. Step‑by‑step: deploy to Sepolia with RemixTo make this more than theory, the contract is deployed on the Sepolia testnet using Remix and MetaMask.
5.1 Setup the walletA wallet such as MetaMask is needed to sign and send transactions:
This setup mirrors real mainnet deployment without risking real funds.
You can follow these steps!
Remix is a browser-based IDE for Solidity:
Remix automatically saves the file and makes it available to the Solidity compiler.
5.3 Compile the contractCompiling turns Solidity into bytecode that can be deployed:
If any errors appear, Remix highlights the problematic lines so they can be corrected before trying again.
5.4 Deploy to SepoliaOnce the contract compiles, it can be deployed to the testnet:
After mining, Remix shows a deployed contract instance and the transaction can also be viewed on Sepolia Etherscan using the transaction hash.
5.5 Interact with the contractThe deployed contract can now be read and updated from Remix:
By repeating this daily, the contract becomes a small on-chain journal of a Web3 learning journey.
6. Why this matters for developersEvery DeFi protocol, NFT marketplace, or DAO is ultimately just a more complex arrangement of variables and functions like the ones introduced here.
Understanding how state is stored, how functions expose or protect that state, and how contracts are deployed to a network is the foundation of secure smart contract development and auditing.
In the next steps of the journey, these basics expand into arrays, mappings, structs, access control patterns, and local development tools like Hardhat and Foundry, but they all build on the same core ideas introduced in this first Solidity article.
Further readingSolidity Basics (Part 1) — Variables, Functions & Your First Real Contract was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.