Smart Contract
A smart contract is a program deployed on a blockchain that executes automatically when its conditions are met — holding, transferring or issuing tokens according to its code — without a party able to stop, alter or reverse it once it runs; the term describes code, not a contract in the legal sense. Smart contracts issue every stablecoin and token and run every DeFi protocol; their flaws have cost billions, because code that holds money is money a bug moves.
- Also known as
- Smart contracts, On-chain contract, Programmable contract, Solidity contract
- Used at
- token issuance (the ERC-20 standard on Ethereum and its equivalents), stablecoins (minting, burning, freezing by the issuer), DeFi (lending, exchange, derivatives), tokenised securities and funds (issuance, transfer restrictions, distributions), NFTs, escrow and conditional payments, and, on permissioned chains, delivery-versus-payment settlement between institutions
- Binding
- the code is not law — a smart contract's legal effect depends on the contract law of the jurisdiction and the agreement it implements (the UK Law Commission's 2021 conclusion that smart legal contracts can be enforced within existing law; similar analyses elsewhere); securities, e-money and crypto-asset rules apply to what the contract issues or does; MiCA requires that smart contracts used by regulated services have access controls and a kill mechanism; liability for a defective contract falls on whoever the law finds responsible, which litigation continues to define
- Typical mechanics
- written in a language such as Solidity, compiled and deployed to an address on the chain; anyone (or only authorised addresses, if the code says so) can call its functions; each call is a transaction that pays a fee and executes deterministically on every validator; state (balances, ownership) lives on-chain; the code is usually immutable, so upgradeability must be designed in through proxy patterns, which reintroduce an administrator
- Typical failures
- reentrancy and logic bugs (The DAO, 2016, $60 million; many since), oracle manipulation, access-control errors (an admin function left open), upgrade-key compromise, and economic design flaws that were correct code implementing a bad idea; audits reduce but do not eliminate them, and formal verification is used for the most valuable contracts
- Parties
- developers, auditors (Trail of Bits, OpenZeppelin, Certik and others), the issuers and protocols that deploy, the users whose funds the code holds, the regulators, and the courts that decide, after the fact, what the code meant legally
How a smart contract works in practice
A stablecoin issuer deploys a token contract: functions to mint (callable only by the issuer's address), burn, transfer, and freeze an address (callable by the issuer for sanctions compliance). A holder transfers tokens by calling the transfer function; the contract checks the balance, checks neither address is frozen, updates the balances, and emits an event that wallets and exchanges read. When a regulator requires the freezing of an address, the issuer calls the freeze function and the tokens at that address cannot move. The contract is the product: its code defines what the token can do, its access controls define what the issuer can do, and its audit history is the evidence that both work. A tokenised bond runs the same way with more rules — transfers only between whitelisted investors, coupons distributed by a function the paying agent calls, redemption at maturity by code.
The engineering discipline is unlike ordinary software's. Deployment is (usually) final, so testing, audits and formal verification precede it; upgradeability is a design choice that trades immutability for an administrator who can change the code — and whose keys become the target. Every function that can move value is an attack surface; every external call is a reentrancy risk; every price the contract reads is an oracle to be manipulated. The failures are public and immediate: an exploit drains a contract in minutes, and there is no one to reverse it unless the code included a pause. For a fintech issuing or using smart contracts, the controls are the audits, the access-control design, the upgrade governance, the pause mechanism regulators now expect, and the monitoring that watches the contract's state in real time; for a buyer, the audit reports, the incident history and the key-management arrangements are the technology diligence.
For a founder, a smart contract is code that is also custody, and it must be built as if a mistake were a theft; for a buyer, the question is what the contract can do, who can change it, and who holds the keys.
Example
A fintech tokenises a money-market fund for institutional clients: a smart contract issues shares as tokens, restricts transfers to whitelisted wallets that have passed KYC, distributes daily yield by adjusting balances, and redeems on instruction. Before launch: two independent audits (14 findings, 3 high, all fixed), formal verification of the transfer-restriction logic, a multi-signature upgrade mechanism requiring three of five officers, a pause function held by the compliance officer, and real-time monitoring of every transaction against the whitelist. In month eight a client's custodian is compromised and an attacker attempts to transfer tokens to an unwhitelisted address; the contract rejects the transfer by design, the monitoring alerts, the pause is invoked while the client's wallet is replaced, and no tokens move. The incident report becomes the fund's strongest sales document and, in the acquirer's diligence a year later, the evidence that the controls work.
Common mistakes
- Deploying code that holds money with one audit and no formal verification of the value paths. - Immutable contracts with no pause, or upgradeable contracts with keys held by one person. - Reading "code is law" as a legal position; the courts decide what the code meant. - Oracles trusted without manipulation analysis. - Treating a smart contract as software rather than as custody with a public attack surface.