What Is a Smart Contract and How Do They Work

Key Takeaways:

• A smart contract is a program that runs on a blockchain: code plus state at a fixed address, executed deterministically and irreversibly once deployed.
• Ethereum popularized the concept in 2015 with Turing-complete Solidity; Bitcoin offers only a limited scripting language for multisig, escrow, and time locks.
• The defining risk is immutability. The DAO lost roughly $50 million in Ether in June 2016, and later parity and arithmetic bugs pushed cumulative losses into the hundreds of millions of dollars.
• Contracts cannot read real-world data on their own; oracles bridge the gap, enabling parametric crop insurance and automated trade settlement.
• Running code on a blockchain does not by itself create a legally binding agreement; a smart legal contract pairs natural-language terms with machine-readable clauses.

What a Smart Contract Actually Is

Ethereum’s developer documentation defines a smart contract as “a program that runs on the Ethereum blockchain,” a collection of code and data that resides at a specific address. It is one of two kinds of Ethereum account: it holds a balance and can be the target of transactions, but no single user controls it. Once deployed, the program runs as written, and interactions with it are irreversible.

Nick Szabo, a computer scientist, coined the term in the 1990s and used the vending machine as his example: insert the right inputs and a defined output is guaranteed. Chainlink dates the coinage to 1994, while Wikipedia notes Szabo was using the term by 1996. Bitcoin’s 2009 launch is often considered the first protocol-level smart contract, since a transfer only executes when the holder signs with the matching private key and holds enough funds. Bitcoin added multisignature transactions in 2012, and Ethereum shipped in 2015 as a network built to run many independent programs at once.

The US National Institute of Standards and Technology describes the concept as a collection of code and state deployed to a blockchain network through cryptographically signed transactions. The code executes there, and its effects cannot be altered without modifying the ledger itself. This allows mutually distrusting parties to reach a tamper-proof result without a central administrator, and it also means every bug becomes a permanent feature.

What the Code Looks Like

Solidity is the most widely used language for these programs on Ethereum, and the ethereum.org documentation shows a minimal example modeled on Szabo’s vending machine. The contract keeps a cupcake balance, lets the owner restock, and sells cupcakes to anyone who sends enough Ether:

pragma solidity 0.8.7;

contract VendingMachine {
 address public owner;
 mapping (address => uint) public cupcakeBalances;

 constructor() {
 owner = msg.sender;
 cupcakeBalances[address(this)] = 100;
 }

 function refill(uint amount) public {
 require(msg.sender == owner, "Only owner can refill.");
 cupcakeBalances[address(this)] += amount;
 }

 function purchase(uint amount) public payable {
 require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake");
 require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock");
 cupcakeBalances[address(this)] -= amount;
 cupcakeBalances[msg.sender] += amount;
 }
}

Two properties distinguish this from ordinary server code. The program is permissionless: anyone can deploy one, paying gas for the deployment transaction just as they would for a simple transfer, though deployment costs far more. And it is composable: because every contract is public and callable, one program can invoke another or even deploy new ones, which is why Ethereum’s documentation compares them to open APIs.

Deployment is a one-way door. The program cannot be deleted by default, and its source is usually public, so anyone can read the exact logic before choosing to interact. That transparency builds trust, but it becomes a liability when a bug is discovered, because the flawed code keeps running exactly as written. Ethereum’s docs also describe multisignature contracts, where a transaction requires N of M signatures to execute, distributing control so a single lost or stolen key cannot drain the funds.

The Limits and the Oracle Workaround

Blockchain programs are intentionally isolated from the outside world. A contract cannot read the current price of an asset, check the weather, or confirm a shipment arrived, because pulling in external data could break the consensus that keeps the network secure. Ethereum’s docs state plainly that relying on external information would jeopardize consensus, which is why the limitation exists by design.

The workaround is an oracle: a service that ingests off-chain data and publishes it on-chain so contracts can read it. Chainlink describes this as the difference between a plain smart contract and a hybrid one, where on-chain code is paired with off-chain infrastructure feeding it real-world inputs. That pairing makes parametric crop insurance feasible, where a contract pays out automatically when rainfall data crosses a threshold, with no manual claim.

There is also a strict size limit. A single contract on Ethereum can be at most 24KB, or it will run out of gas during deployment. Projects needing more logic split functionality across multiple contracts, or use the Diamond pattern defined in EIP-2535 to route calls to several implementation contracts behind one proxy.

The Security Problem: Code That Cannot Be Patched

Because the deployed program is immutable, a discovered flaw cannot be quietly fixed. The canonical case is The DAO, a decentralized investment fund drained of roughly US$50 million worth of Ether in June 2016 through a reentrancy bug; the exploit moved about 3.6 million Ether, around a third of the fund’s holdings, and the community resolved it with a hard fork that rewrote history to return the funds, as documented in Wikipedia’s account of the incident. Later failures, including the Parity multisignature wallet bugs and integer underflow and overflow attacks in 2018, pushed cumulative losses from these exploits into the hundreds of millions of dollars.

Solidity’s own security documentation lists the recurring pitfalls. Reentrancy is the best known: when one contract calls another, control passes to the called code, which can call back before the first contract has finished updating its state. The documented defense is the Checks-Effects-Interactions pattern:

function withdraw() public {
 uint share = shares[msg.sender];
 shares[msg.sender] = 0; // Effects first: zero the balance
 (bool success, ) = payable(msg.sender).call{value: share}("");
 require(success); // Interactions last
}

Two other classes deserve attention. Authorization via tx.origin is a documented trap, because a phishing contract can inherit the identity of the user who initiated the transaction; the docs direct developers to use msg.sender instead. And randomness is nearly impossible to source honestly on-chain, since every value a contract can see is also visible to block builders who might exploit it. The same applies to anything marked private: all state is public on the ledger.

The immutability problem has a partial answer in upgradeable contracts, where a proxy contract points users to a newer implementation. That preserves the appearance of immutability while letting owners swap logic behind the scenes, but it reintroduces a trusted operator and a governance risk. Audits are the standard front-line defense; Chainlink calls them a core part of development precisely because a deployed bug cannot always be fixed in time.

Platforms and Tooling

Not every chain can run arbitrary logic. Ethereum implements a Turing-complete language, which is why it became the dominant venue for complex contracts. Bitcoin, by contrast, uses a deliberately Turing-incomplete scripting language that supports multisignature accounts, payment channels, escrow, and time locks but cannot express general-purpose programs. Wikipedia lists Cardano, Solana, Tron, Tezos, and Avalanche among the platforms built to host smart contracts, each with its own trade-offs in throughput, finality, and developer ecosystem.

On the tooling side, OpenZeppelin publishes the most widely used library of audited, reusable Solidity contracts, covering ERC token standards and common security patterns. The project is MIT-licensed and remains actively maintained, with 27,231 stars and 12,405 forks on GitHub as of September 2026. OpenZeppelin’s own site states that trillions of dollars in total value have moved through contracts built on its library, a self-reported figure worth treating as an indicator of scale rather than an audited accounting. For teams building on Ethereum’s scaling layer, the trade-offs between rollup architectures are covered in our explanation of Layer-2 rollup solutions.

What a Smart Contract Is Not: The Legal Gap

An automated program is not automatically a binding legal agreement. Wikipedia distinguishes a smart contract from a smart legal contract: the latter is a traditional, natural-language agreement whose selected terms are also expressed and implemented in machine-readable code. Running code on a blockchain does not by itself create a contract enforceable in court.

That gap is closing unevenly. The US Senate noted in a 2018 report that with smart contracts, “the program enforces the contract built into code,” and several states including Arizona, Iowa, Nevada, Tennessee, and Wyoming have passed legislation recognizing their use.

The deeper limitation is what code cannot express. Chainlink points out that lending protocols almost exclusively rely on overcollateralization, requiring a borrower to lock up more than they borrow, because no program can force a person to repay an unsecured loan. Agreements that depend on judgment, intent, or renegotiation still need human and legal layers stacked on top of the automation.

How to Evaluate a Smart Contract Project in 2026

The practical question for an engineer or product owner is where the technology genuinely helps. Automated contracts pay off when the terms are objective, the inputs can be verified on-chain or through a trusted oracle, the state changes are simple value transfers, and the counterparties do not trust each other enough to rely on a shared intermediary. Chainlink’s example of global trade settlement, where a supplier is paid in full on time or at a reduced rate if goods arrive late, captures the ideal shape: a rule stated as an if-then condition and verified by data.

They fit poorly when the agreement depends on subjective judgment, when the underlying asset or event cannot be digitized, or when the parties want the flexibility to renegotiate. In those cases a conventional contract with a few automated clauses, the smart legal contract model, usually serves better than a fully self-executing one.

The checklist that separates sound deployments from risky ones is short. Confirm the source is audited and the audit findings are public. Understand whether the contract is upgradeable and who holds the upgrade keys. Verify that any external data comes from a mechanism you trust. And assume the code will be attacked, because it is public, valuable, and cannot be patched once live. The same lesson about immutable, attackable code surfaced when attackers used a Polygon smart contract to resolve malware command-and-control addresses, as covered in our breakdown of the 2026 GitHub supply chain campaign.

Related Reading

More in-depth coverage from this blog on closely related topics:

• CodeFreedom for Open Source AI Control
• Google 2024 Financial Trends and Insights
• What is Speculative Decoding in vLLM
• Fable Game Reboot: New Gameplay Features
• Python Interpreter Development Guide

Sources and References

Sources cited while researching and writing this article:

• Introduction to smart contracts | ethereum.org
• What Are Smart Contracts in Blockchain? | Chainlink
• EIP-2535
• Wikipedia’s account of the incident
• Security Considerations — Solidity 0.8.37-develop documentation