What smart contracts are and how they function
Smart contracts are blockchain-based programs that execute automatically as coded. Understanding their mechanics and limitations is crucial for users.
Jordan Fraser 5 min read
A smart contract isn’t a contract in the legal sense, and it isn’t especially smart; it’s a piece of software that lives on a blockchain and runs automatically when the conditions written into it are met. The name is older than the technology that made it practical, and understanding both halves clarifies what these programs actually do and don’t guarantee.
The core idea
A smart contract is code deployed to a blockchain that executes exactly as written whenever it’s triggered, without a person, company or intermediary approving each execution. A simple example: a smart contract could hold funds in escrow and release them to a seller automatically once a buyer confirms receipt, replacing the role a bank or escrow agent would normally play, enforced instead by code that every participant can inspect and that runs the same way for everyone. Once deployed, most smart contracts can’t be quietly changed, which is the source of both their appeal, no party can unilaterally alter the rules after the fact, and their risk, a mistake in the original code is just as hard to fix.
What actually happens when a smart contract runs
It helps to be concrete about the mechanics. A smart contract is stored on the blockchain as compiled code, at a specific address, much like a regular account has an address. When a user or another contract sends a transaction to that address, calling one of the contract’s functions, every node participating in the network independently executes that same code with the same inputs, and they all arrive at the same result, which is what gets recorded as the new state of the blockchain. That redundant, distributed execution is the source of the “trustless” property people associate with smart contracts: no single party runs the code on the user’s behalf, and no single party can quietly alter the result, because the outcome is whatever the code produces when thousands of independent computers run it. The cost of this redundancy is computational expense, which is why executing a smart contract requires paying a gas fee. A simple contract call is cheap; a contract that loops through complex logic or touches a lot of stored data costs more, because every node has to actually perform that work.
Older than blockchains, made practical by Ethereum
Computer scientist Nick Szabo coined the term “smart contract” in 1994, describing the general idea of a computerized protocol that executes contract terms automatically, years before a blockchain existed capable of running one in a trustworthy, decentralized way. Bitcoin’s scripting language supports only limited, narrow logic. Ethereum, launched in 2015, was purpose-built with a general-purpose virtual machine, the Ethereum Virtual Machine, specifically so developers could write and deploy arbitrary smart contract code, which is what turned Szabo’s decades-old concept into infrastructure other applications, from decentralized exchanges to lending platforms to NFT marketplaces, could actually be built on.
What smart contracts don’t guarantee
“Code is law” was an early framing for smart contracts: since the contract executes exactly as programmed, there’s no room for a differing interpretation the way there can be with a written legal contract. The practical problem is that “exactly as programmed” includes bugs. The 2016 DAO hack is the clearest illustration: an attacker exploited a flaw in the DAO smart contract’s code, not any weakness in Ethereum itself, to drain roughly 3.6 million ETH, worth around $50 million at the time, by repeatedly withdrawing funds before the contract’s balance was updated, a pattern now known as a reentrancy attack. The code executed precisely as written; the code was simply wrong. That incident led, controversially, to Ethereum’s community forking the chain to reverse the theft, a decision that split the network permanently into Ethereum and Ethereum Classic, and it remains the standard reference point for why smart contract auditing, and healthy skepticism of any protocol claiming to be trustless purely because it’s on-chain, matters as much as the blockchain underneath it.
Where smart contracts actually get used
The applications that made smart contracts more than a technical curiosity are worth naming specifically, since the term can otherwise stay abstract. Decentralized exchanges use smart contracts to hold pooled funds and execute trades automatically according to a pricing formula, without a centralized order book or a company matching buyers and sellers. Lending protocols use them to hold collateral, calculate interest and liquidate under-collateralized positions automatically, replacing the underwriting and enforcement functions a bank would normally perform. NFT marketplaces use them to enforce ownership records and, in many cases, automatically pay a royalty to an original creator every time an item resells. In each case, the appeal is the same: replacing a company or intermediary that could theoretically change the rules, freeze funds, or fail as a business, with code that behaves predictably and that anyone can inspect before relying on it, though as the DAO hack demonstrates, “predictably” only holds if the code was written correctly in the first place.
The practical takeaway
A smart contract removes the need to trust a specific person or company to honour an agreement, but it replaces that trust with trust in the code itself being correct, and in whoever, if anyone, retains the ability to pause or upgrade it. Reviewing whether a protocol’s contracts have been independently audited, and understanding that audited doesn’t mean risk-free, is a more useful habit than assuming “smart contract” alone implies safety.
That last point about upgrade ability deserves its own attention, because it directly qualifies the “code is law, no one can change the rules” pitch many protocols use to market themselves. Truly immutable contracts, ones with no built-in mechanism for anyone to alter their behaviour after deployment, are actually less common in practice than the marketing language suggests. Many production smart contracts are deliberately built with an upgrade mechanism, controlled by the development team, a decentralized governance vote, or some combination of both, precisely so bugs can be patched without requiring a disruptive hard fork of the kind Ethereum underwent after the DAO hack. That flexibility is often a reasonable, even necessary, engineering tradeoff, but it also means a contract with an upgrade mechanism carries a different risk profile than one without: the code isn’t the only thing that matters, so does who controls the key that can change it, and under what conditions they’re permitted to use that power.