What Is a Smart Contract?

A smart contract is a program stored on a blockchain at its own address that runs exactly as written whenever someone sends it a transaction. Because every node executes the same code and records the result, no single party can change the outcome. Smart contracts power tokens, decentralized exchanges and lending markets, but they cannot fix their own bugs.

Where the idea came from

The term “smart contract” was coined by computer scientist Nick Szabo in the 1990s to describe agreements enforced by code rather than by courts. The idea became practical when Ethereum launched in July 2015 with a programming environment built into the blockchain itself. Today most smart contracts run on Ethereum and on networks that copied its design.

A vending machine, and where the analogy stops

Szabo’s own favorite illustration was a vending machine. Put in the right money, choose an item, and the machine releases it; no shopkeeper has to approve the sale, and the rules are built into the machine. A smart contract works the same way: send the right transaction, meet the conditions in the code, and the outcome follows automatically.

The analogy breaks in two places. A vending machine’s owner can open it, fix it or take it away; many smart contracts cannot be changed by anyone once deployed. And a vending machine holds a few dollars of snacks, while a single smart contract can hold billions of dollars of other people’s money, which makes every flaw in its rules far more consequential.

How a smart contract works

1. A developer writes the code, usually in a language such as Solidity, and compiles it for the Ethereum Virtual Machine (EVM).
2. The code is deployed in a transaction. It receives its own address, like a wallet, and can hold funds.
3. Users call its functions by sending transactions to that address, for example “swap this token” or “repay this loan.”
4. Every node runs the same code and must reach the same result. If any condition in the code fails, the whole transaction is reverted.
5. The caller pays for the computation in gas. Each operation has a set cost, which stops programs from running forever. See the gas limit.

Figure: What happens when you call a smart contract on Ethereum.

A simple example: an escrow contract

Imagine two strangers trading a used laptop for 1 ETH. Neither wants to go first. An escrow contract can sit between them:

1. The buyer sends 1 ETH to the contract, which records it and locks it.
2. The seller sees the locked payment on the blockchain and ships the laptop.
3. When it arrives, the buyer calls the contract’s “confirm” function, and the contract releases the 1 ETH to the seller.
4. If the buyer never confirms and never disputes, a timeout rule in the code can release the funds to the seller after a set period; if the seller never ships, another rule can refund the buyer.

No company holds the money, and neither party can take it outside the rules. But the contract cannot see whether a laptop was actually delivered or was broken on arrival. Anything that happens off the blockchain has to be reported to the contract by someone, which is where disputes, arbitrators or oracles come in.

Gas: why running code costs money

Every step a contract performs, from adding two numbers to storing a value, has a fixed cost in units of gas. The caller sets a maximum amount of gas and pays a price per unit, so the total fee is the gas used multiplied by the price. Storing data permanently is among the most expensive operations, which is why developers work hard to keep contracts lean.

Two consequences surprise newcomers. A transaction that fails partway still pays for the gas it used before failing, because the network did the work. And the same action can cost very different amounts depending on how busy the network is, because the price per unit of gas rises with demand.

What smart contracts are used for

• Tokens: most tokens, including major stablecoins, are smart contracts that track balances and handle transfers.
• Decentralized exchanges: pools of tokens that price and execute swaps automatically.
• Lending: contracts that accept collateral, issue loans and liquidate positions when collateral falls too far.
• Multi-signature wallets: funds that move only when several approved keys sign.
• Bridges: contracts that lock assets on one chain so they can be represented on another; see what a cross-chain bridge is.
• Staking and governance: contracts that hold staked coins, distribute rewards and count votes on protocol changes.

Standards: why tokens work everywhere

Much of what users take for granted depends on shared standards, agreed sets of functions that contracts implement in the same way. The ERC-20 standard defines how fungible tokens report balances and handle transfers and approvals, which is why a wallet or exchange can support a new token without custom work. ERC-721 does the same for non-fungible tokens, giving each token a unique ID and an owner. Because contracts follow these templates, one wallet can display thousands of different tokens and one exchange contract can trade any of them. Standards also concentrate risk: the “approve” function that lets a contract spend your tokens is part of ERC-20, and it is the same function drainers exploit.

What makes them different from normal software

A normal app runs on servers controlled by a company, which can change the rules or shut it down. A smart contract runs on a public network: its code is visible, its execution is checked by thousands of nodes, and, unless it was built to be upgradeable, nobody can alter it after deployment. That is the source of both its trust and its risk.

Contracts can also call one another. A lending contract can read prices from an oracle contract, accept a token issued by another contract and send liquidated collateral to an exchange contract, all in one transaction. This composability lets developers build on each other’s work, and it also means a failure in one contract can ripple through every contract that depends on it.

Upgradeable contracts and admin keys

Because deployed code cannot change, many teams use an upgradeable design. Users interact with a fixed “proxy” contract that forwards calls to a separate logic contract, and the team can point the proxy at new logic to fix bugs or add features. This is practical, but it reintroduces trust: whoever controls the upgrade can change the rules, including how funds are handled.

Well-run projects limit that power. Common safeguards include requiring several independent signers for any upgrade, imposing a timelock so changes are announced days before they take effect, and eventually removing upgrade rights altogether once the code is mature. Checking which of these are in place is one of the most useful things a user can do.

Where smart contracts fail

Bugs are permanent. A flaw in deployed code can be exploited by anyone who finds it, and the network will execute the exploit faithfully. The 2016 DAO hack, in which an attacker exploited a flaw in one of Ethereum’s earliest large contracts, became so serious that it led to a hard fork of the network. See what happened in the DAO hack.

They only know what is on the chain. A contract cannot check a stock price or the weather by itself. It depends on blockchain oracles for outside data, and bad data leads to wrong outcomes.

Admin keys can override them. Upgrade powers that allow fixes also allow abuse, and stolen keys give attackers the same powers. The Ronin bridge hack showed how much can depend on a handful of keys.

Users can be tricked into approving them. Many thefts do not break any code at all. A malicious site asks a user to approve a contract to spend their tokens, and the contract then does exactly what it was allowed to do. See what a wallet drainer is.

Code is not a legal contract. A smart contract executes instructions; whether it creates legal rights depends on the law where the parties are. See blockchain myths.

Audits, bug bounties and formal verification

Because mistakes are so costly, serious projects layer several defenses. Independent security audits review the code before launch, though an audit is a snapshot of one version and cannot guarantee that no bugs remain. Bug bounty programs pay researchers who find and responsibly report flaws, which gives talented people a legitimate alternative to exploiting them. For the most critical code, formal verification uses mathematical methods to prove that a contract behaves according to its specification. Each method reduces risk; none removes it, and code that has held large amounts safely for years still carries the strongest evidence.

Reading a contract on a block explorer

You do not need to write code to learn a lot about a contract. On a block explorer, a contract’s page usually shows its balance, its transaction history and, if the developers published it, a “verified” source code tab that lets anyone compare the code with what is deployed. Explorers often list the contract’s read functions, which show its current settings, and its write functions, which show what it can do. Unverified code, very recent deployment or a large balance controlled by an unknown address are all reasons for extra caution. See what a blockchain explorer is.

Smart contracts beyond Ethereum

Many other networks run smart contracts. Some are compatible with the Ethereum Virtual Machine, so the same code and tools work across them with minor changes. Others use different virtual machines and programming languages, which can offer speed or cost advantages but means contracts and audits do not transfer directly. The same questions about code quality, upgrade powers and dependencies apply on every network.

How to judge a smart contract before using it

• Has the code been audited, by whom and how recently?
• Is the contract upgradeable, who controls the upgrade keys, and is there a timelock?
• How long has it been running, and how much value has it safely held?
• Does it depend on oracles or bridges, and which ones?
• What exactly does your wallet ask you to approve when you use it?

No answer makes a contract risk-free, but each one tells you where the risk sits.

Frequently asked questions

Can a smart contract be changed after it is deployed?

Only if it was designed to be. Immutable contracts run unchanged forever; upgradeable ones can be modified by whoever controls the upgrade mechanism, which is why that control matters so much.

Are smart contracts legally binding?

Not automatically. A smart contract enforces its own code, but whether it creates enforceable legal obligations depends on the law that applies to the people involved and on any agreement around it.

Do I need to know how to code to use smart contracts?

No. Most people use them through wallets and websites without seeing any code. Knowing what you are approving, and where the contract’s risks lie, matters far more than reading it line by line.

For the network most smart contracts run on, read what Ethereum is.

This article is educational content and does not constitute financial, investment, legal or tax advice. Digital assets are volatile and you may lose the amount you invest.

Sources

• Introduction to smart contracts — ethereum.org
• Ethereum history (July 2015 launch) — ethereum.org
• DigiCash (Nick Szabo coined the term “smart contracts”) — Wikipedia
• Gas and fees — ethereum.org Developer Docs
• Upgrading smart contracts (proxy patterns, timelocks, multisig control) — ethereum.org Developer Docs
• Token standards (ERC-20, ERC-721) — ethereum.org Developer Docs