What a smart contract actually is
Week 2 Part 3 told you a contract is an account made of code. That is accurate and it is not yet useful.
The plain-English version
A smart contract is a program deployed at an address on the blockchain. People and applications interact with the functions it exposes, and the network executes the same rules for each call.
Some functions may be open to everyone, while others use permission checks. Some contracts are immutable; others include admin or governance controls that can change parts of their behaviour.
The name is misleading twice over: it is not a legal contract, and it is not especially smart. It is a small program with unusual properties.
Learning objectives
- Explain what a smart contract is without using the word "contract"
- Describe what state, functions and events are, and how they relate
- Explain why "code is law" cuts both ways
- Recognise the shape of a contract before you can write one
Core
What makes it unusual
An ordinary program runs on a computer someone controls. A smart contract is executed by the network's nodes according to its deployed code and rules.
| Dimension | Ordinary program | Smart contract |
|---|---|---|
| Runs on | A server someone owns | Every node, identically |
| Who can change it | The owner, any time | It may be immutable, or changeable through an admin or upgrade mechanism |
| Who can read the code | Whoever is given it | Deployed bytecode is public; human-readable source is easiest to inspect when verified |
| Who can call it | Whoever is allowed | Functions may be open or restricted by their rules |
| If it has a bug | Patch and redeploy | It keeps running the bug |
That fourth row is the one people underestimate. A deployed contract is public infrastructure whether or not you intended it to be. Anyone can call any function you left callable, in any order, at any time, including in ways you never imagined.
"Code is law" cuts both ways
When deployed code cannot be changed, the same immutability that stops someone rewriting your balance also stops anyone fixing a mistake. There is no support line, no rollback, and no "obviously that wasn't the intent."
This is why Part 5 exists, and why real deployments get audited.
The three things a contract has
Almost every contract you will ever read is made of these.
State it remembers, functions it can run, events it announces outward. Note the arrow: nothing happens until something calls in from outside.
State is what the contract remembers between calls. It is stored on-chain, and changing it costs gas. Updates become part of the chain's history, even when the current value changes. A token contract's state is mostly one big table of who owns how much.
Functions are what the contract can do. They split exactly the way Week 2 Part 4 described:
| Request type | Read | Write |
|---|---|---|
| Changes state | No | Yes |
| Costs gas | No | Yes |
| Needs a signature | No | Yes |
| Example | "What is my balance?" | "Send 10 tokens to Ben" |
Events are announcements. The contract cannot read them; applications outside can. Standard ERC-20 token transfers are typically surfaced through Transfer events that wallets and explorers index.
A contract needs a trigger
Worth repeating from Week 2 Part 3, because it explains so much:
Execution needs a trigger
A contract has no key of its own and does not sign or submit an ordinary transaction by itself. It cannot run on a timer or see the internet; something else must trigger its execution.
When a protocol appears to act automatically — a loan liquidated the moment collateral drops — something off-chain is watching and sending that transaction. Often a bot or service is paid a fee for doing it.
How a DApp uses a contract
A DApp is not just a smart contract. It is usually a user interface connected to a wallet, a route to a blockchain node, and the contract that holds on-chain rules and state.
The RPC provider is a doorway to a node. It transports requests and responses; it does not own the contract or control the user's key. Larger applications may add an indexer, a traditional backend/database or decentralised storage, but those are supporting layers rather than requirements for the basic model.
Most of a DApp is ordinary web software. A frontend can be compromised while the contracts remain sound: a hijacked website may show a malicious transaction request while the contract executes exactly as written. This is why Week 0 insisted on bookmarks over search results, and why a hardware wallet showing the transaction on its own screen can be valuable.
“show me 42 votes”
- The user opens a page and the frontend asks for the current vote count.
- The frontend sends a read request through an RPC provider. In Ethereum terms, this is commonly an
eth_call. - The node executes or reads the request against the current chain state and returns the result.
- The frontend renders the answer. No state changes, transaction or user signature is normally required, so the user does not normally pay a transaction fee for this read.
“vote”
- The user clicks Vote, and the frontend prepares a call to the contract's
vote()function. - The wallet shows what is being requested. The frontend cannot secretly sign for the user; the wallet controls the signing authority.
- The user approves and signs. The signed transaction travels through an RPC provider to the network.
- The network processes it. The contract runs, its state may change, and it may emit events.
- The frontend or an indexer later reads the result and refreshes the display.
One small UI example
Imagine a voting DApp that shows 42 votes:
| User action | Path | What the learner should notice |
|---|---|---|
| Read the count | Frontend → RPC → votes() → response → render 42 | The app is asking what the contract currently remembers; no transaction is sent |
| Click Vote | Frontend prepares vote() → wallet approval → signed transaction → RPC → network → contract | The wallet authorises the action, and the contract may update the state to 43 |
The contract is the on-chain rule-set and state, not the whole application. The frontend makes it usable; the wallet authorises writes; the RPC connects the application to a node; and the network records the result. Week 2 Part 4 explained RPC and read/write mechanics, while Part 5 explained the network layers underneath. This section puts those pieces together inside an actual DApp.
What contracts are good at, and bad at
| Good at | Bad at |
|---|---|
| Holding and moving assets by rules | Anything needing outside data |
| Enforcing conditions nobody can override | Anything private |
| Coordinating strangers without a middleman | Anything needing human judgement |
| Being verifiable by anyone | Being changed after a mistake |
| Composing with other contracts | Large computation — gas makes it expensive |
The right-hand column is the useful one. Most failed blockchain projects tried to do something in the right column.
Landscape
- Deployment — the transaction that puts a contract's code on-chain and gives it an address. That address is where later calls find the program
- Constructor — code that runs once at deployment, then never again. It sets the contract's starting values
- ABI — the description of how to call a contract's functions. Applications use it to turn a human action into the right request; see Part 2
- Verified source — publishing the source so anyone can check it matches the deployed bytecode. This makes the intended code easier to inspect, not automatically safe
- Immutable vs upgradeable — some contracts can be replaced behind a proxy. An upgrade can fix bugs, but also gives the upgrade controller continuing power
- Composability — contracts calling contracts. It lets applications combine building blocks, but connected failures can spread
- Reentrancy — a classic bug class where a called contract calls back before the first finishes. If state is updated too late, an attacker may repeat an action before the balance is corrected; see Part 5
Worked example
A vending machine is the analogy everyone uses. It is worth using carefully, because the way it breaks is the instructive part.
Where it holds. Put in the right coins, the machine gives you the item. No shopkeeper decides whether you deserve it. The rules are visible and identical for everyone.
Where it breaks:
| Vending machine | Smart contract |
|---|---|
| Owner can restock, fix, or unplug it | Its deployed rules may be immutable, or may include upgrade controls |
| Only the person standing there uses it | Anyone who can reach an open function can call it |
| Jam it and you lose a dollar | A flaw can drain everything at once |
| Physical presence limits abuse | The attacker can be a program, calling a million times |
The lesson the analogy hides
A vending machine's bugs are bounded by physics. A contract's bugs are bounded by nothing.
That is why every remaining page this week keeps returning to security — not because contracts are dangerous to learn, but because deploying one is publishing something that anyone can poke, forever.
Further exploration — optional, not assessed
- ethereum.org — Introduction to smart contracts — the same ground, more formally
- ethereum.org — Anatomy of smart contracts — state, functions, events and modifiers in detail
- Open any verified contract on Etherscan and skim its Read Contract tab. You are not expected to follow it yet — notice that you can see it at all
Sources and attribution
- ethereum.org — Introduction to smart contracts — Reuse (CC BY 4.0), adapted
- ethereum.org — Anatomy of smart contracts — Reuse (CC BY 4.0), adapted
- ethereum.org — Dapps — Reuse (CC BY 4.0), adapted
- ethereum.org — JSON-RPC API — Reuse (CC BY 4.0), adapted
- ethereum.org — Interacting with smart contracts — Reuse (CC BY 4.0), adapted
- Web3 Internship Handbook — Reuse (permission granted); DApp interaction structure adapted with permission