Solidity for Beginners: Write and Deploy Your First Smart Contract on a Testnet

You’ve read about smart contracts. Maybe your company is exploring tokenized assets, or you’re a developer curious about Web3 jobs. Now you want to actually write one, and every tutorial either assumes you already know Ethereum inside out or stops at “Hello World” without explaining what could go wrong.

This guide walks you through writing, testing and deploying a small but realistic Solidity contract, a tip jar that accepts payments and lets only the owner withdraw. You’ll do it on a testnet, so it costs nothing real. Along the way you’ll pick up the security habits that separate hobby code from code you’d trust with money.

If smart contracts themselves are new to you, read what a smart contract is first. It takes 10 minutes and makes the rest of this much easier.

What Solidity is and why it’s the starting point

Solidity is a statically typed, curly-brace programming language for writing smart contracts on Ethereum and other EVM-compatible blockchains, including most Ethereum layer 2 networks. If you know JavaScript, TypeScript, C++ or Java, the syntax will feel familiar.

A few things make Solidity different from everyday programming:

• Code is public and hard to change. Once deployed, a contract’s code generally can’t be edited.
• Every write costs gas. Storing data and running logic on-chain costs fees, so efficient code matters.
• Mistakes can be expensive. A bug can lock or lose funds, with no customer support line to reverse it.

The Solidity documentation recommends using the latest released compiler version when you deploy, because older versions generally don’t receive security fixes. Check the current release on soliditylang.org before you start.

What you need before you start

Ethereum.org calls Sepolia the recommended default testnet for application development. Older testnets such as Goerli and Holesky are deprecated, so ignore tutorials that still point to them. Use a separate wallet for development, never the one that holds real funds. If you’re unsure about wallet safety, our hot vs cold wallet guide explains the basics.

Step 1: Open Remix and create a file

Remix runs entirely in your browser, and the Solidity docs suggest it for trying code without installing anything.

1. Go to remix.ethereum.org.
2. In the File Explorer, create a new file called TipJar.sol inside the contracts folder.
3. Paste in the code from the next step.

Step 2: Write the contract

Here’s the full contract. Read it once, then we’ll break it down.

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

contract TipJar { address public immutable owner; uint256 public totalTips;

event TipReceived(address indexed from, uint256 amount, string message);
event Withdrawn(address indexed to, uint256 amount);

error NotOwner();
error NoTip();
error NothingToWithdraw();
error TransferFailed();

constructor() {
    owner = msg.sender;
}

function tip(string calldata message) external payable {
    if (msg.value == 0) revert NoTip();
    totalTips += msg.value;
    emit TipReceived(msg.sender, msg.value, message);
}

function withdraw() external {
    // Checks
    if (msg.sender != owner) revert NotOwner();
    uint256 amount = address(this).balance;
    if (amount == 0) revert NothingToWithdraw();

    // Effects
    emit Withdrawn(owner, amount);

    // Interactions (always last)
    (bool ok, ) = owner.call{value: amount}("");
    if (!ok) revert TransferFailed();
}

} ```

What each part does

• License and pragma. The first line declares the license. pragma solidity ^0.8.24; tells the compiler to accept version 0.8.24 or any later 0.8.x release.
• State variables. owner stores who deployed the contract. immutable means it’s set once in the constructor and can never change. totalTips keeps a running total.
• Events. TipReceived and Withdrawn write logs that apps and block explorers can read. They’re cheaper than storing data and give you an audit trail.
• Custom errors. Declaring error NotOwner(); and using revert NotOwner(); stops execution and undoes changes. The Solidity docs note custom errors are usually much cheaper than string error messages.
• Constructor. Runs once at deployment and records the deployer as owner.
• tip. The payable keyword lets the function receive ETH. It rejects empty tips and logs the message.
• withdraw. Only the owner can call it. It sends the whole balance to the owner.

Since Solidity 0.8.0, arithmetic is checked by default, so totalTips += msg.value reverts instead of silently overflowing. That one change removed a whole class of bugs that hit early contracts.

Step 3: Compile and test in the Remix VM

1. Open the Solidity Compiler tab, choose a recent 0.8.x version and click Compile TipJar.sol. Fix anything flagged in red, and read the yellow warnings too.
2. Open the Deploy & Run Transactions tab. Set the environment to Remix VM. The Remix docs say it’s an in-browser sandbox with 10 test accounts preloaded with 100 ETH each, and no wallet approvals needed.
3. Click Deploy. Your contract appears under Deployed Contracts.
4. Test the happy path: in the Value field enter 1 and pick ether, type a message in tip and click it. Then click totalTips to see the result.
5. Test the failure paths, which matter more: - Call tip with a value of 0. It should fail with NoTip. - Switch to a different account and call withdraw. It should fail with NotOwner. - Switch back to the owner account and call withdraw. The balance should move to the owner.

Testing what should fail is the habit that catches real bugs. Professional teams write automated tests for every one of these cases.

Step 4: Deploy to the Sepolia testnet

1. Add the Sepolia network in your development wallet and get free test ETH from a Sepolia faucet. Ethereum.org’s networks page links to faucets.
2. In Remix’s Deploy & Run tab, switch the environment to your browser extension wallet and make sure it’s on Sepolia.
3. Click Deploy and approve the transaction in the wallet popup.
4. Copy the contract address once it’s mined, and look it up on a Sepolia block explorer such as Sepolia Etherscan.
5. Call tip from a second wallet, then withdraw from the owner, and watch the events appear on the explorer.

Many explorers let you verify your source code, which publishes it next to the deployed bytecode so anyone can read what the contract does. Make that a habit too.

Security habits to build from day one

Most costly smart contract failures come from a handful of known mistakes. The Solidity documentation’s security section covers them. Build these habits now:

• Checks, effects, interactions. Validate inputs, update your own state, and only then call other contracts or send ETH. The docs explain that any external call hands control to another contract, which could call back into yours before your function finishes. That’s a reentrancy attack.
• Use msg.sender, never tx.origin, for permissions. The docs warn that a malicious intermediary contract can trick tx.origin checks.
• Nothing on-chain is secret. Even private variables can be read by anyone inspecting the chain. Never store passwords, keys or personal data.
• Avoid unbounded loops. Loops that grow with stored data can exceed the block gas limit and freeze functions.
• Keep contracts small and reuse vetted code. Well-reviewed libraries such as OpenZeppelin Contracts cover tokens and access control, so you don’t reinvent them.
• Take warnings seriously and get reviews. Peer review finds issues you’ll miss. Before real money is involved, budget for a professional smart contract audit.
• Limit what’s at risk. Keep balances low in new contracts and plan how you’d respond to a bug.

General secure coding best practices apply too: least privilege, input validation and code review.

Key takeaway: Treat every testnet contract as if it held real money. Habits like checks-effects-interactions, owner checks with msg.sender and testing the failure paths cost nothing to learn now and can save a fortune later.

Where to go next

Once your tip jar works, level up in this order:

1. Add features. Let the owner transfer ownership, or set a minimum tip. Write a failing test for each before you code it.
2. Learn a local framework. Hardhat and Foundry let you write automated tests, run a local chain and script deployments. Remix can connect to both.
3. Use version control. Keep your contracts in Git from the start so every change is tracked and reviewable.
4. Study real code. Read verified contracts on block explorers and the official Solidity examples.
5. Learn the ecosystem. Understand oracles for off-chain data and token standards before building anything financial. Our explainer on DeFi shows where these pieces come together.

If you’re considering a career move, our tech careers guide covers where blockchain skills fit among in-demand roles.

Conclusion

Your first Solidity contract doesn’t need to be clever. It needs to work, fail safely and teach you how the pieces fit: state, functions, events, errors and gas. Write it in Remix, test it in the VM, deploy it to Sepolia and break it on purpose. If you build the security habits now, everything you write later starts from a safer place.

Sources

• Solidity documentation — language overview, use of the latest compiler release and Remix for trying code
• Solidity docs: Expressions and control structures — checked arithmetic since 0.8.0, require, revert and custom errors
• Solidity docs: Security considerations — reentrancy, checks-effects-interactions, tx.origin, gas limits and public data
• Remix documentation: Deploy and run transactions — Remix VM accounts and wallet environments
• Ethereum.org: Networks — Sepolia as the default testnet for app development and deprecated testnets