Solidity contract structure is the arrangement of a source file, its version directive, contract declaration, stored values and executable functions. Following OSSolidity.001: EVM and Smart Contracts, this beginner lesson moves from the virtual-machine concept to a small source file you can inspect in Remix. The objective is understanding the parts, not deploying real-money applications.

Learning objectives

• Recognize the SPDX comment and compiler version pragma.
• Locate the contract body, state variable and function bodies.
• Compile and inspect a simple contract in a local Remix VM.

UX Alchemy explains SPDX, pragma solidity and the contract declaration. Focused contract-structure tutorial, published December 2025.

Source-file header: SPDX and pragma

The official Solidity language reference recommends an SPDX license identifier near the beginning of every source file. // SPDX-License-Identifier: MIT states a common permissive license for the source; it does not make an unsafe contract trustworthy. The declaration is a comment, not an executable EVM command. License choice must reflect the author’s actual rights.

Next, pragma solidity ^0.8.20; declares compatible compiler versions: at least 0.8.20 but below 0.9.0. The caret does not freeze a specific compiler binary. Solidity 0.8.38 was released in October 2026, so selecting that version in a suitable teaching environment satisfies this example. For reproducible production builds, document the exact compiler release and settings.

The Techzeen demonstrates writing, compiling and interacting with a first Solidity smart contract in Remix (October 2025).

Contract members and state

A contract Counter { ... } declaration groups a program’s members inside braces. Solidity contracts resemble classes, but after deployment their behavior is executed under Ethereum’s rules. The language specification describes members such as state variables and functions; more advanced events, inheritance, structs and modifiers belong in later lessons.

The line uint256 public count = 0; declares a 256-bit unsigned integer stored as contract state. public causes the compiler to generate a count() getter. It does not make the value confidential: blockchain data is generally observable. The location and visibility rules are different from familiar local variables in ordinary compiled programming languages.

A function has a name, parentheses and a body. increment() modifies state and therefore normally requires a transaction. readCount() is marked view because it reads state without changing it. Calling the public getter can read the same value; the additional function makes the difference between declarations explicit.

Working example: Counter.sol

Copy the complete teaching contract into a file named Counter.sol. Its SPDX comment, compiler pragma, contract header, state variable and two functions are intentionally short. The code is an educational counter, not a secure production authorization system.

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

contract Counter {
    uint256 public count = 0;

    function increment() public {
        count = count + 1;
    }

    function readCount() public view returns (uint256) {
        return count;
    }
}

Local Remix exercise

Open the official Remix IDE, choose a compiler compatible with the pragma, then compile. In the Deploy & Run panel select the local Remix VM environment rather than a public chain. Deploy Counter, inspect count and readCount, call increment, and read both values again. Expected results are zero initially and one after the first successful increment.

Eric Tech walks through Remix and Solidity variables, functions and visibility; the tutorial includes topics beyond this beginner lesson (June 2024).

Knowledge check

1. What is the role of an SPDX comment, and what does it not guarantee?
2. Does ^0.8.20 lock the compiler to 0.8.20?
3. Which statement declares persistent contract state?
4. Why is increment different from readCount?
5. Who can invoke increment in this teaching contract?

Answers and safety notes

SPDX describes a source license, not contract safety. The caret allows compatible 0.8.x releases. uint256 public count is the state declaration. increment writes, while readCount reads. Without access-control checks, any caller can invoke increment.

The important security boundary is easy to miss: anyone able to call increment() can update this example’s counter. A public state variable has an auto-generated reader, not an automatic access-control rule for unrelated methods. Do not send funds, store secrets or copy this toy contract into a real financial product. Related Bitcoin smart-contract research uses different execution assumptions.

Language syntax and network design should remain separate: the same contract may be compiled for compatible Ethereum Layer-2 environments, but deployment configuration, transaction fees and security assumptions vary. Later lessons will address parameter types, visibility, persistent versus temporary data, contract calls and safe testing.

References and next topic

For references, use the Solidity documentation’s source-file layout and contract structure pages, the official Remix deployment guide, and the October 2026 compiler release notes. Open-source licensing is a useful companion topic.

Next in the full curriculum rotation: SQL. The next Solidity-track installment will introduce elementary data types and function parameters, without skipping or renumbering any subject.

Editor’s Note: We volunteer daily to ensure the credibility of the information on this platform is Verifiably True. If you would like to support our work and help further secure the integrity of our research initiatives, please scan the QR code below to donate 5,000 sats.

For mobile scanning, open this lesson on a laptop or larger screen and scan the original QR image using a compatible Bitcoin wallet. Verify the receiving address before sending 5,000 sats: 3C9o19EH5HSiwEPyCTmEKzxhNCbo2X6TTb.

BitcoinVersus.tech is not a financial advisor. This media platform reports on financial subjects purely for informational purposes.