Why is smart contract security different from normal software security?

Smart contract security is different because the code is public, often holds money directly, and usually cannot be changed once deployed. A bug in a web app can be patched overnight; a bug in a contract can be found by anyone reading the code and exploited before the team wakes up. Ethereum.org estimates losses from smart contract defects at over a billion dollars and cites the 2016 DAO hack as an early example.

Consider a fictional four-person studio, Larkspur Labs, building a simple savings pool where members deposit funds and withdraw their share. The developer, Kofi, leaves review notes before deployment: 'withdraw sends funds then sets balance to 0. setFee is public, will restrict later. using old compiler version from tutorial. price of reward token read from one small exchange pool. tests: tried deposit + withdraw once by hand, works'. Every line is a known vulnerability class.

What are the most common smart contract vulnerabilities?

The most common smart contract vulnerabilities are access control flaws, price oracle manipulation, logic errors, missing input validation and reentrancy, which head the OWASP Smart Contract Top 10 for 2025. Ethereum.org covers the same core classes.

Reentrancy

A contract sends funds or calls another contract before updating its own records. A malicious receiver calls back in while the old balance still shows, and withdraws again. Kofi's withdraw function, which pays out before setting the balance to zero, is the classic shape. The usual fix is to update state first and interact with other contracts last, often called checks, effects, interactions.

Access control

Sensitive functions that anyone can call. Kofi's public setFee function lets any stranger change the fee. Ethereum.org describes patterns such as an owner role, role-based access and multi-signature approval.

Integer overflow and underflow

Arithmetic that wraps past its limit, so a balance below zero becomes a huge number. Ethereum.org notes Solidity 0.8.0 and later reject this by default, while older code needs explicit checks, which is why Kofi's old compiler matters.

Oracle manipulation

Reading a price from a single thin market that an attacker can move, often with a flash loan, a loan borrowed and repaid within one transaction. Robust designs use decentralised oracles or time-averaged prices.

Logic and validation errors

Rules that do not match the intended design, or inputs that are never checked, such as a zero amount or an unexpected address.

How do teams test and audit smart contracts?

Teams test and audit smart contracts in layers, because no single method catches everything: automated tests, analysis tools, deployment to a test network, independent review and, for contracts holding significant value, an external audit and bug bounty.

1. Unit and property tests

Write tests for every function, including hostile cases such as a receiver that calls back in. Fuzzing tries thousands of random inputs automatically.

2. Static analysis

Ethereum.org names tools such as Slither, Mythril and Aderyn, which scan code for known risky patterns.

3. Test networks

Deploy to a public testnet before mainnet. Ethereum.org recommends Sepolia for application and contract development; testnet ether is meant to have no real value, so mistakes cost nothing.

4. Peer review and audited libraries

Use version control, independent reviewers on every change, and well-reviewed libraries such as OpenZeppelin Contracts rather than writing access control from scratch.

5. Audit, bounty and monitoring

Independent audits add scrutiny but, as ethereum.org notes, do not catch every bug. Bug bounties, emergency pause functions and event monitoring cover what remains.

What does a weak and an improved security review look like?

Weak review: 'Deposit and withdraw tested manually, works fine, ready to deploy.' A happy-path test shows the contract works for honest users, which is exactly what attackers are not.

Improved review: Reentrancy: withdraw now sets the balance to zero before sending, and a test uses a hostile receiver contract to try calling back in. Access control: setFee restricted to an owner role from an audited library, with a test that a stranger's call fails. Compiler: upgraded to a current 0.8 version so overflow checks are on. Oracle: single-pool price replaced with a decentralised price feed, plus a sanity limit on sudden moves. Testing: unit tests, a fuzzing run and a static analysis pass with every finding explained, then two weeks on Sepolia with a colleague trying to break it. External audit booked before any real funds are accepted.

What are the common smart contract security mistakes?

The most common mistake is testing only the happy path, as if every caller were honest. Others: leaving admin functions open to restrict later, copying tutorial code with an outdated compiler, trusting one price source, treating an audit as a guarantee, skipping the testnet stage, and deploying without a plan for pausing or upgrading.

Where does this lesson sit in Tosheo.ai?

This is a Code lesson in the Blockchain category and the blockchain course. This free page explains each step in prose; the full hands-on version, where you review and fix real contract code and run tests on a test network, is in the optional Code track after sign-up. Start with smart contracts explained if the basics are new. Tosheo.ai is not a full-time bootcamp or a professional auditor qualification, and nothing here is investment advice; contracts that hold real value need a specialist audit.

Sources and scope

ethereum.org, smart contract security (checked 19 October 2026) ↗

OWASP Smart Contract Top 10, 2025 (checked 19 October 2026) ↗

ethereum.org, networks and testnets (checked 19 October 2026) ↗