Smart contracts: how they work and how they fail
In short: A smart contract is a program stored on a blockchain that runs exactly as written when someone calls it. That makes it transparent and automatic, but also unforgiving: bugs are public and often cannot be patched easily. Secure development, testing, independent audits and monitoring are essential.
Code that lives on the chain
A smart contract is a program stored at an address on a blockchain. Anyone can send it a transaction, and every node runs the same code to reach the same result. The name is a little misleading: it is not a legal contract, and it is only as smart as its code. The idea is simply that rules ("release the payment when both parties confirm") are enforced by software that no single party controls.
Ethereum made smart contracts popular. Its contracts run on the Ethereum Virtual Machine (EVM) and are usually written in Solidity. Every operation costs gas, a fee paid by the caller, which stops infinite loops and pays validators for computation. Many other chains also run EVM-compatible contracts, and permissioned platforms such as Hyperledger Fabric use similar ideas under the name "chaincode".
What they are used for
- Tokens: rules for creating and transferring digital tokens, following standards such as ERC-20.
- Escrow and multi-party approval: funds move only when agreed conditions are met.
- Decentralised applications: exchanges, lending and voting systems that run without a central server.
- Business workflows: in permissioned chains, sharing steps of a supply chain or trade process between companies.
Smart contracts cannot fetch outside data on their own. They depend on oracles, services that bring in data such as prices or delivery events. An oracle becomes a point of trust and a target.
How smart contracts fail
A well-known example is reentrancy. A contract sends funds to another contract before updating its own records. The receiving contract calls back in and asks again while the balance still looks unchanged. The classic defence is the checks-effects-interactions pattern: check the conditions, update your own state, and only then interact with outside contracts. Reentrancy guards add a lock so a function cannot be entered twice at once.
| Flaw | Why it matters | Defence |
|---|---|---|
| Reentrancy | Funds drained by repeated calls | Checks-effects-interactions, reentrancy guards |
| Missing access control | Anyone can call admin functions | Explicit role checks, well-reviewed libraries |
| Oracle manipulation | Fake prices trigger wrong payouts | Multiple data sources, time-averaged prices |
| Arithmetic errors | Wrong balances or rounding losses | Modern compiler checks, careful maths, tests |
| Upgrade mechanism abuse | An admin key can replace all the logic | Multisig admin, timelocks, transparency |
Secure development practices
- Use mature, widely reviewed libraries rather than writing token or access logic from scratch.
- Write unit and property-based tests, including attack scenarios, on a local test chain.
- Run static analysis tools and fix every finding you cannot justify.
- Get an independent audit for anything that will hold value, and publish the scope.
- Deploy to a public test network first and run a bug bounty.
- Plan for incidents: pause functions, monitoring, and protected upgrade keys.
Tip: "code is law" cuts both ways. If the code allows something, the chain will do it, even if it was never the developer's intention. Treat contract code like firmware that cannot easily be recalled.
Common mistakes include deploying unaudited code, keeping the upgrade key on a single laptop, and trusting one price source. For exams, remember that smart contracts are deterministic programs, that they need oracles for outside data, and that immutability makes secure design before deployment critical. Testing should always use local or public test networks, never other people's live contracts.
Practice
Why do smart contracts need oracles?
What is the checks-effects-interactions pattern?
Why is an upgradeable contract a security trade-off?
Key takeaways
- A smart contract is a program on a blockchain that runs exactly as written.
- Ethereum contracts run on the EVM, are often written in Solidity and cost gas.
- Oracles bring in outside data and become a trust point.
- Common flaws: reentrancy, access control, oracle manipulation, upgrade abuse.
- Test, analyse, audit and monitor, because deployed code is hard to fix.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.