What Is a Smart Contract? A Beginner’s Guide in Plain English

That is the whole idea, and it is worth understanding properly, because smart contracts are the engine behind almost everything in Web3 that goes beyond simply sending coins: decentralized finance, NFTs, DAOs, and most of the apps people actually use on a blockchain. If a blockchain is the notebook, a smart contract is the set of rules taped to the inside cover — rules that enforce themselves.

This guide explains what smart contracts are, where they run, how they work, what they are used for, and — most importantly — what can go wrong. It does not teach you to write code, and it contains no code examples. It is written for someone who wants to understand the technology well enough to use it wisely, not to program it.

If you need the foundations first, our Blockchain 101 guide explains the notebook, and our guide to how blockchains work explains how the network agrees on what is true.

The Vending Machine: An Analogy From 1994

The clearest way to understand a smart contract is an analogy that is older than the blockchain itself. In 1994, the computer scientist and legal scholar Nick Szabo coined the term “smart contract” and described it as a computerized protocol that executes the terms of a contract automatically. His favorite example was a vending machine.

Think about an ordinary purchase. You want a drink. In a shop, the deal involves a cashier, a till, and a whole system of trust: you hand over money, the cashier hands over the drink, and if there is a dispute, a manager or a court sorts it out. A vending machine collapses all of that into a mechanism. You put in the right coins, press the button, and the machine checks the payment and drops the drink. No cashier, no argument, no one to trust. The rule — if the right money goes in, the drink comes out — is built into the machine itself.

A smart contract works the same way, except the machine is a blockchain and the drink is a digital asset or an action. The rule is written in code: if this condition is met, then do that. When someone sends the right transaction, the network runs the code, and the outcome happens automatically. When the condition is not met, nothing happens. Nobody has to interpret the agreement, nobody can stall it, and nobody can quietly change the terms after the fact.

Szabo wrote about this in 1994 and explored it further in 1996 — years before any blockchain existed that could run such programs. Bitcoin, launched in 2009, proved that value could move on a public network without a trusted middleman, but Bitcoin’s scripting was deliberately limited. It was Ethereum, launched in 2015, that turned Szabo’s idea into a working platform: a blockchain designed from the start to run arbitrary programs. Ethereum’s own documentation still uses Szabo’s vending machine comparison today, and it credits him with coining the term.

Three things to notice about the analogy, because each one matters later:

• The machine does not think. It follows rules. A smart contract is not intelligent; it is literal. It does exactly what its code says, including the mistakes.
• The machine cannot be argued with. Once the rules are set, they run the same way for everyone, every time. That is the point — and also the risk.
• The machine only knows what it is given. A vending machine knows the coins you inserted. It does not know whether you are thirsty, whether the drink is fairly priced, or whether the weather changed. A smart contract, likewise, only knows what is on the blockchain, plus whatever outside information is deliberately fed into it.

Where Smart Contracts Run, and Who Executes Them

A smart contract is a program that runs on a blockchain. On Ethereum, the most widely used smart contract platform, the contract is a collection of code and data that lives at a specific address on the chain — much like a wallet address, except that instead of being controlled by a person with a private key, it is controlled by its own code.

Here is how the pieces fit together, according to Ethereum’s own developer documentation:

The contract lives at an address. When a developer deploys a contract, the network gives it its own address. The contract can hold a balance of cryptocurrency, receive transactions, and send funds — just like a user account. The difference is that no person holds its keys. It runs as programmed.

It sits idle until called. A smart contract does nothing on its own. It waits. When a user — or another contract — sends it a transaction that calls one of its functions, the network executes that code. If the conditions are met, the contract acts. If not, nothing happens.

Every computer on the network runs the same code. When a transaction calls a contract, the nodes that maintain the blockchain each execute the code independently and arrive at the same result. That is what makes the outcome trustworthy without a middleman: anyone can check the code, anyone can verify the result, and the shared record shows exactly what happened.

Running code costs a fee. On Ethereum, computation is not free. Every action a contract takes costs “gas” — a fee paid to the network for the work of executing and recording the transaction. Simple actions cost little; complex ones cost more. Ethereum’s documentation notes that a contract has a maximum size of 24KB, and that every action costs fees, so complex logic is expensive. For a beginner, the practical point is this: interacting with a smart contract always costs something, and the cost rises with congestion on the network. Check the fee before you confirm anything.

The contract cannot be deleted by default. Once deployed, a smart contract’s code generally cannot be changed or removed. Ethereum’s documentation states this plainly: smart contracts cannot be deleted by default, and interactions with them are irreversible. This immutability is a feature — it guarantees the rules cannot be changed after people have relied on them — and it is also the source of the biggest risks in this technology, which we will come to.

Contracts can call other contracts. A smart contract can interact with other smart contracts, which can call further contracts in turn. This is called composability, and it is why the ecosystem grows so fast: developers build new apps on top of existing contracts instead of starting from scratch. It is also why a problem in one contract can cascade into many others.

The Lifecycle, in Four Steps

1. Written. A developer writes the rules in a smart contract language — Solidity is the most common one on Ethereum — defining what the contract should do: what conditions trigger which actions, who can do what, and what happens to the funds.
2. Deployed. The compiled code is published to the blockchain in a special transaction, which costs a fee. The network assigns the contract an address. From this moment, the code is live and, by default, unchangeable.
3. Called. Users and other contracts send transactions to the address. Each call executes the code with the parameters given, and the network records the result.
4. Executed. Every node runs the same code and reaches the same result. The contract’s stored data is updated, funds move if the code says so, and the outcome becomes part of the permanent record.

Notice what is missing from this list: no approval step, no human review, no customer service. Between deployment and execution, there is no one in the loop. That is the design. Whether it is a good design depends entirely on whether the code is correct.

Smart Contracts vs Traditional Contracts

It helps to see the contrast side by side, because the differences explain both the excitement and the danger.

The most important row is the last-but-one. A traditional contract is interpreted by humans, who can consider what the parties meant. A smart contract has no notion of intent. If the code contains a flaw, the network will execute the flaw faithfully, at full speed, with no one able to stop it mid-flight. That is not a theoretical concern. It is the story of the most famous incident in smart contract history.

What Smart Contracts Are Used For

Once you can write rules that enforce themselves, a surprising number of things become possible. Here are the main uses, each in plain terms.

Lending and borrowing. A smart contract can hold collateral, issue a loan, charge interest, and liquidate the collateral automatically if its value falls too far. No bank, no loan officer, no paperwork. This is the core of decentralized finance, and it is why stablecoins — which our companion stablecoin guide explains in full — matter so much: lending needs a stable unit to price loans in. Our guide to DeFi covers the ecosystem, and our look at decentralized lending risks is worth reading before you put money into any of it. (Its price predictions are from 2025 and should be ignored; the risk discussion is the useful part.)

Trading without an exchange. A smart contract can hold pools of tokens and let people swap one for another at a price set by a formula — no order book, no company in the middle. These are called decentralized exchanges, and they run entirely on contracts. You keep control of your funds until the moment of the swap, which is the attraction — and you also bear the risks of the contract’s code.

NFTs. A non-fungible token is, under the hood, a smart contract that tracks who owns a unique digital item — art, a collectible, a game item, a membership, a ticket. The contract defines the rules: how many exist, who can mint new ones, how ownership transfers, and whether the creator gets a royalty on resale. Our guide to NFTs beyond art walks through the applications in more depth.

DAOs: organizations run by code and votes. A DAO — a decentralized autonomous organization — uses smart contracts to manage a shared treasury and make decisions by token-holder vote. Members propose actions, vote on them, and the contract executes the result automatically: releasing funds, changing a rule, or admitting a new member. Our practical guide to building a DAO explains how one is put together. The idea is powerful; the execution, as the next section shows, is where things have gone wrong.

Escrow, insurance, and royalties. Any arrangement that can be reduced to “if X happens, pay Y” is a candidate: hold payment in escrow until delivery is confirmed, pay an insurance claim automatically when a defined event occurs, split streaming royalties between collaborators the moment revenue arrives. The pattern is always the same — conditions written in advance, execution without a middleman.

Identity, voting, and records. Beyond money, contracts can manage registries: who owns what, who voted for what, who is entitled to access something. These uses are earlier and less proven than the financial ones, but they follow from the same property: a shared, tamper-resistant record with rules that enforce themselves.

The Oracle Problem: Contracts Cannot See the Real World

There is one hard limit that beginners should understand early, because it shapes everything else. A smart contract can only see what is on the blockchain. It cannot check the price of a stock, the weather in Chicago, the result of an election, or whether a package was delivered. Those facts live off-chain.

To bridge the gap, the ecosystem uses oracles: services that fetch real-world data and feed it onto the chain, where contracts can read it. A lending contract that needs to know the price of ether uses a price oracle. An insurance contract that pays out when a flight is cancelled uses a flight-data oracle.

This creates an obvious dependency: a contract is only as reliable as the data it receives. If an oracle is compromised, delayed, or simply wrong, every contract that trusts it inherits the error. Oracle manipulation has been behind several major DeFi exploits, where attackers distorted a price feed and then used the distorted price to drain a lending protocol. The blockchain itself executed everything correctly. The data was the problem.

The honest summary: smart contracts are excellent at enforcing rules about things that happen on-chain, and they depend on trusted intermediaries — oracles — for everything else. The “no middleman” story has an asterisk, and the asterisk is the oracle.

What Can Go Wrong: The Risks, Honestly Stated

This is the most important section in the guide. Smart contracts fail in ways that traditional software rarely does, because the usual safety nets — undo, customer support, a court order — mostly do not exist. Here are the risks, with the real history behind them.

Bugs Are Forever (Mostly)

Because a deployed contract generally cannot be changed, a bug in the code is not a bug you can patch on Tuesday. It is a standing invitation, visible to everyone — the code is public — until someone exploits it or the funds are moved.

The defining case is The DAO, in 2016. The DAO was an early decentralized investment fund on Ethereum, launched in April 2016. It raised about $150 million worth of ether from more than 11,000 participants — around 14 percent of all ether in existence at the time. Its withdrawal function contained a flaw: it sent ether to the caller before updating the caller’s balance. An attacker exploited this with a “reentrancy” attack — a malicious contract that called the withdrawal function again and again, each time before the balance was updated, draining the same funds repeatedly. On June 17, 2016, about 3.6 million ether — roughly $50 to $60 million at the time — was drained into a structure the attacker controlled.

No credentials were stolen. No server was breached. The contract simply did what its code said, and its code was wrong. The community’s response was extraordinary and controversial: a hard fork of the Ethereum blockchain on July 20, 2016, to reverse the theft — a decision that split the network into two chains, Ethereum (ETH) and Ethereum Classic (ETC), a split that persists today. The lesson is not that hard forks will save you; they are a last resort that a community may or may not agree to. The lesson is that a single ordering mistake — sending funds before updating a balance — cost tens of millions of dollars, and that no one could stop it while it was happening.

Audits Help. They Do Not Guarantee Safety.

You will often see that a project has been “audited” — a security firm reviewed the code and published a report. Audits are valuable. They catch real bugs. But an audit is a point-in-time review by humans, of code that is often complex, and auditors miss things. Many hacked projects were audited. Some were audited more than once.

Also worth knowing: an audit report is only as meaningful as its scope. A project may advertise an audit that covered one version of the code while the deployed version is different, or that covered one contract while the vulnerability was in another. Before trusting an audit claim, check which contracts were reviewed, when, and whether the findings were fixed. If you cannot find the report, treat the claim as marketing.

The Upgrade Tension

Immutability is both the promise and the problem. If code cannot change, bugs cannot be fixed. Developers have responded with upgrade patterns — most commonly “proxy” contracts, where a fixed address points to code that can be swapped out. This solves the patching problem and creates a new one: whoever controls the upgrade can change the rules, which reintroduces exactly the trusted middleman the technology was meant to remove. Before using a contract, it is worth asking: can this contract be upgraded, and if so, who holds that power? A contract that can be changed by a single person is not meaningfully different from a traditional service — whatever its marketing says.

Scams Built on Contracts

Not every smart contract risk is a bug. Some contracts work exactly as designed — and the design is the scam. Common patterns:

• Rug pulls. A project launches a token, attracts buyers, and then the developers drain the liquidity or mint unlimited tokens and sell them. The contract did what it was written to do; the developers simply wrote it to benefit themselves.
• Fake tokens. Anyone can deploy a token with the name and symbol of a famous project. Buying the wrong one — from a lookalike address — is a common loss.
• Unlimited approvals. When you interact with a contract, your wallet may ask you to approve it to spend your tokens. Approving an unlimited amount to a malicious or buggy contract can drain your wallet. Check what you are approving, and prefer limited approvals where the wallet offers them.

The Human Layer

Finally, the risks that have nothing to do with code: phishing sites that mimic real apps, fake support agents, and social engineering. A smart contract cannot protect you from approving a transaction you do not understand, or from sending funds to an address a scammer gave you. The technology removes some middlemen and leaves you, alone, as the final check. That is the trade-off of the whole system, and it is worth being honest about.

For a fuller treatment of how to protect yourself, our blockchain security best practices and our guide to how proof-of-work and proof-of-stake secure the network cover the ground from different angles.

How to Keep Learning (Without Learning to Code First)

You do not need to program to understand smart contracts well enough to use them. But if you want to go deeper, here is a sensible path — in order, and without shortcuts.

1. Understand the blockchain first. If the notebook metaphor is still fuzzy, you are not ready for contracts. Re-read the Blockchain 101 guide and the how-blockchains-work guide until the ideas of blocks, consensus, and addresses feel solid.

2. Read Ethereum’s own introductions. Ethereum.org publishes a plain-language introduction to smart contracts and a separate page on smart contract security, written for non-developers. They are the most authoritative free starting point, and they are where several facts in this article come from. Read them before you read anyone’s hot take.

3. Learn to read a contract’s public record. You do not need to read code to check the basics: on a blockchain explorer, you can see a contract’s address, when it was deployed, how many transactions it has handled, and whether its code is published and verified. A contract with unverified code — where the published code does not match what is actually deployed — is a reason to pause.

4. Understand wallets and keys before you interact with any contract. Every interaction with a contract is a transaction signed by your wallet. If you are not confident about seed phrases, hot and cold wallets, and approvals, read our crypto wallet beginner’s guide first — it covers the ground this article assumes.

5. Only then, if you want to build, learn the language. Solidity is the standard language for Ethereum contracts. Learning it is a real undertaking — months, not a weekend — and it should come with learning security from the start, not as an afterthought. The common advice from security researchers is blunt: do not deploy a contract that holds other people’s money until you understand reentrancy, access control, and upgrade patterns, and have had your code reviewed. This guide will not teach you to write code, and you should be wary of any article that promises to do so in a few pages.

Before You Interact With a Smart Contract: A Checklist

• ☐ I understand what this contract is supposed to do, in plain language — not just what its website claims.
• ☐ I checked the contract’s address on a blockchain explorer, and it matches the official address published by the project.
• ☐ I know whether the contract’s code is verified and whether it has been audited — and I know an audit is not a guarantee.
• ☐ I checked what approval my wallet is asking for, and I am not granting unlimited spending to a contract I do not fully trust.
• ☐ I know the gas fee before I confirm, and I am not being rushed.
• ☐ I am using an amount I can afford to lose while learning, not funds I need.
• ☐ I understand that the transaction is irreversible once confirmed.

Frequently Asked Questions

Are smart contracts legally binding?
Usually, no — not by themselves. A smart contract is code that executes automatically. Whether it counts as a legal contract depends on the jurisdiction, the intent of the parties, and whether the arrangement meets the legal requirements of a contract. Some projects pair smart contracts with traditional legal agreements; the code handles execution, the paperwork handles enforceability. Do not assume that because something ran on a blockchain, a court will enforce it — or that a court can undo it.

Can a smart contract be changed after deployment?
By default, no. That immutability is the point. Some contracts are built with upgrade mechanisms, usually proxy patterns, that let an authorized party swap in new code. That flexibility comes at a cost: whoever controls the upgrade controls the rules. Always ask whether a contract you use is upgradeable and who holds that power.

Do smart contracts only exist on Ethereum?
No. Ethereum is the best known, but many other blockchains support smart contracts, each with its own languages, tools, and trade-offs. The concepts in this guide — code at an address, called by transactions, executed by the network, immutable by default — apply broadly, even if the details differ.

Can a smart contract hold real money?
It can hold cryptocurrency, which is real value to the people who use it. It cannot hold dollars in a bank account, own property in the traditional legal sense, or sign a paper document. The boundary between on-chain and off-chain is real, and oracles are the bridge — with all the limitations that implies.

What is the difference between a smart contract and a dapp?
A dapp — a decentralized application — is the user-facing app, the website or interface you interact with. Underneath it, one or more smart contracts do the actual work on the blockchain. Think of the dapp as the storefront and the contract as the vending machine inside. When people say “the dapp was hacked,” the problem is often in the contract, the website, or the connection between them.

If smart contracts are so risky, why does anyone use them?
Because they do something nothing else can: enforce an agreement automatically, transparently, and without asking anyone’s permission. For people who cannot rely on courts or banks — or who simply do not want to — that is worth a great deal. The risks are real, but so is the capability. The right response is not to avoid the technology, but to understand its limits before you trust it with anything important.

The Short Version

A smart contract is a program that lives on a blockchain at its own address. When someone sends it a transaction, the network runs its code, and the outcome happens automatically — no middleman, no interpretation, no appeal. The idea dates to Nick Szabo in 1994, who compared it to a vending machine: the right input in, the agreed result out. Smart contracts power lending, trading, NFTs, and DAOs, but they only know what is on the chain — everything else arrives through oracles, which can be wrong. And they do exactly what their code says, including the mistakes: in 2016, a flaw in The DAO’s withdrawal code let an attacker drain about 3.6 million ether, and the only fix was a hard fork that split Ethereum in two. Audits help but do not guarantee safety, and upgradeable contracts reintroduce the trusted party the technology was meant to remove. Understand the rules before you play by them — and never interact with a contract you do not understand, with money you cannot afford to lose.

Sources and Update Time

• Ethereum.org, “Introduction to smart contracts”: a smart contract is a program that runs on the Ethereum blockchain, a collection of code and data at a specific address; smart contracts cannot be deleted by default and interactions with them are irreversible; smart contracts are public and can be thought of as open APIs. https://ethereum.org/developers/docs/smart-contracts/
• Ethereum.org, “Smart contracts: what are they and their benefits”: Nick Szabo coined the term “smart contract”; in 1994 he wrote an introduction to the concept and in 1996 an exploration of what smart contracts could do; the vending machine is the standard metaphor — specific inputs guarantee predetermined outputs; contracts follow “if this, then that” logic and execute deterministically. https://ethereum.org/smart-contracts/
• Ethereum.org, “Technical intro to Ethereum”: smart contracts compared to a vending machine; developers upload programs to the network and users request execution for a fee; a contract can be a maximum of 24KB. https://ethereum.org/developers/docs/intro-to-ethereum/
• The DAO hack, June 2016: reentrancy vulnerability in the withdrawal function drained approximately 3.6 million ETH (roughly $50–60 million at the time); the Ethereum community executed a hard fork on July 20, 2016, reversing the theft and splitting the chain into Ethereum (ETH) and Ethereum Classic (ETC). Multiple independent security sources agree on the mechanism, the amount, and the dates.
• Ethereum.org, “Smart contract security” and “Oracles”: contracts alone cannot get information about real-world events; oracles feed external data in, and a contract is only as reliable as the data it receives.
• Fact-check date: 2026-11-11. This article is educational only and is not investment, legal, or technical advice. Smart contract platforms and their documentation change over time; check ethereum.org and the official documentation of any project before interacting with its contracts.