What Is a Smart Contract? What Code on a Blockchain Can and Can't Do

Most explanations of smart contracts start with the word contract, which is where they go wrong. A smart contract is not a PDF with legal language attached to a blockchain. It is a small program that lives at an address on a network, holds whatever assets are sent to it, and does exactly what its code says when someone calls it. No clerk approves the transfer, no bank opens on Monday, and no one can ring up the developer and ask for a favour.

That last part cuts both ways, and it is the reason the topic is worth an hour of your attention. The same property that makes a contract a neutral referee makes it an unforgiving one. Understanding what actually runs, and what it costs, is the difference between using these systems and being used by them.

A definition that survives contact with reality

The term comes from Nick Szabo, a computer scientist and legal scholar who described a smart contract in a 1994 paper as a computerised transaction protocol that executes the terms of an agreement. His goal was narrow and practical: satisfy common contractual conditions, treat accidental and malicious exceptions the same way, and reduce the need to trust an intermediary. The idea sat mostly dormant for fifteen years because the payments infrastructure of the 1990s could not support it.

Bitcoin, launched in 2009, showed that a public network could agree on a shared ledger without a bank. But Bitcoin's scripting language was deliberately limited. It can express conditions on who may spend a coin, and not much else. Ethereum, proposed by Vitalik Buterin in a white paper in late 2013, asked the obvious follow-up question: what if the network could run any program at all? The project raised money in a 42-day crowdsale in 2014 and switched on its mainnet, called Frontier, on 30 July 2015.

Why the vending machine is the right picture

Szabo's favourite comparison was a vending machine, and it still works better than any diagram. The machine holds the goods, takes your coins, checks them against a fixed rule, and dispenses. It does not evaluate your intentions, your credit history or whether you have had a bad day. It is a contract with whoever holds the coins.

A smart contract is that machine with the rules written in public and the till auditable by anyone. Two consequences follow immediately. First, the outcome is the same for everyone who calls it in the same state, which is what allows strangers to transact at all. Second, if the rule is wrong, the machine will keep being wrong, cheerfully and at scale.

What actually happens when a contract runs

A contract does nothing until a transaction calls it. You sign a transaction, pay a fee, and the network's nodes each execute the same bytecode against the same stored data. The execution happens in the Ethereum Virtual Machine, a sandbox with 256-bit words and its own instruction set, and it is metered: every operation costs gas, and gas comes from the fee you attached.

The metering is not a billing convenience. It is the security model. Because every step has a price, no program can loop forever and stall the network. Run out of gas and the transaction reverts: the state changes disappear, the transfer never happens, and the fee is still spent. That asymmetry surprises newcomers. You pay for the attempt, not the result. Our guide to crypto gas fees goes through why the price per unit of gas swings so violently.

Along the way a contract can write to its own storage, call other contracts, and emit events — log entries that the chain records but the contract itself cannot read back. Wallets, block explorers and dashboards rebuild their picture of the world from those events. If a project's interface shows a number the contract never emitted, that number came from somewhere else.

Smart contracts explained without the "smart"

There is no intelligence in the word. A contract cannot learn, adapt or judge. Given the same inputs and the same stored data, it produces the same output on every machine on Earth, and that predictability is the whole product.

Two limits follow from it. A contract cannot see the internet. It has no way to ask an exchange what a price is or a weather service whether it rained, because every node must reach an identical answer, and a live web request cannot guarantee that. Anything from outside has to arrive as data that someone wrote to the chain, which means an oracle, a role that concentrates trust at the exact point the design was supposed to remove it. How that is handled, and what happens when it is handled badly, is the subject of our piece on crypto oracles and Chainlink.

The second limit is that a contract cannot start itself. No timer wakes it up and no condition triggers it from nothing. Someone or something must send a transaction, which in practice means a keeper network, a bot, or a person clicking a button. "Automatic" here means automatic once triggered.

The rules are public, which is the real innovation

Deploy a contract and the bytecode is visible to anyone who looks. Most teams publish the source and verify it, so the compiled code on chain can be matched against readable Solidity, the language Gavin Wood proposed in August 2014 and the Ethereum team led by Christian Reitwiessner then built out.

This is why standards matter so much. A token that follows ERC-20 can be listed by a wallet it has never heard of, because the interface is fixed. ERC-721 did the same for NFTs in 2018. The standard is not a guarantee of quality, only of shape, but shape is what makes an ecosystem possible.

Public code also has a hard ceiling. Since 2016, deployed contract code has been capped at 24,576 bytes. Anything larger must be split across multiple contracts that call each other, which is why reading a serious protocol means following a trail of addresses rather than one file.

Immutable until it isn't

A deployed contract cannot be edited. That sentence is true and also misleading, because most large protocols are upgradeable. The trick is a proxy: a small contract that holds the funds and forwards every call to an implementation contract, which can be swapped. Users talk to a fixed address while the logic behind it changes.

That pattern puts an enormous amount of power in whoever can trigger the swap. Good projects put the upgrade behind a multisig and a timelock measured in days, so holders can exit if they dislike what is coming. Weaker ones keep a single key. When you read that a protocol was "exploited" through an admin function, this is usually what happened: not a broken cipher, but a key that did what keys do.

Ethereum has also been chipping away at the older escape hatches. Since the Dencun upgrade in March 2024, a contract can only be deleted by the self-destruct instruction if it was created in the same transaction. And since the Pectra upgrade on 7 May 2025, an ordinary wallet can delegate its execution to contract code through EIP-7702, which blurs the line between a wallet and a contract and pushes account features like batching and recovery into wallets that were previously inert.

Where smart contracts break

The first major failure is still the clearest lesson in the genre. The DAO raised roughly 12.7 million ETH in 2016 and was drained of about 3.6 million ETH on 17 June of that year. The flaw was reentrancy: the contract sent funds before updating its own balance, so the recipient could call back in and repeat the withdrawal. The community response was to rewrite history at block 1,920,000 in July 2016, which split Ethereum into two chains. The code had done exactly what it was written to do.

Three failure modes cover most of what has happened since. Reentrancy and arithmetic errors are coding bugs. Oracle manipulation is a design bug: a contract trusts a price feed that a large trader can move for one block. Key compromise is an operations bug, and it is the least glamorous and most common. A contract is only as strong as the assumptions its authors made, and those assumptions are rarely written down in the same font as the marketing.

What they are actually used for

Stablecoins like USDT and USDC are contracts that hold reserves off chain and issue tokens on it, which is why the interesting question about a stablecoin is never the code but the attestation. Decentralised exchanges such as Uniswap are contracts holding pools of two assets and repricing them on every trade, with no order book and no counterparty to negotiate with. Lending markets accept collateral, enforce liquidation thresholds and pay interest from borrowers to suppliers, all in the same transaction flow.

Beyond finance, contracts run NFT collections, DAO treasuries, voting systems and a growing pile of tokenised funds and private credit. The common thread is not decentralisation for its own sake. It is that the rules are checkable by the person taking the other side of the trade.

How to check a contract before you trust it

• Is the source code verified on a block explorer, and does it match what the interface claims?
• Has it been audited, by whom, and was the audit published before or after the launch?
• Who can upgrade it or pause it, and is that power behind a multisig and a timelock?
• Where does its price data come from, and how easily could one actor move that source?
• How much value is actually locked in it, and how old is the contract?
• Does the interface promise a yield the code has no visible source for?
• Can you withdraw, and what does the withdrawal path require?

Most of these take minutes to answer and are impossible to fake for long. A contract that hides its admin keys is telling you something.

What code still cannot do

A smart contract cannot enforce anything in the physical world. It can release payment when a shipment is marked delivered, but it cannot check the box. It cannot rule on whether a clause was breached in spirit. It cannot keep your data private, because everything it stores is public by default. And it cannot undo a mistake, which is why the interface to a contract matters as much as the contract itself.

That is the honest summary. A smart contract is a small, permanent, public machine for moving value under fixed rules. Used where the rules are simple and the counterparties are strangers, it removes a real cost. Used where judgement, privacy or reversibility are essential, it just moves the risk somewhere less visible.

Both of those are worth knowing before you sign anything, on chain or off.