What Is a Smart Contract, and What Can Go Wrong?

A smart contract is one of the more misleading terms in crypto, because it borrows a legal word for something that is not, strictly speaking, a contract. It is a program stored on a blockchain that runs automatically when certain conditions are met, without a bank, broker, or court in the loop. That automation is the appeal, and it is also the source of most of the risk. This guide explains what a smart contract actually does, where the idea gets used in practice, and the main categories of things that go wrong when the code does not behave the way its authors intended.

What a smart contract actually is

Strip away the name, and a smart contract is a piece of software deployed to a blockchain, most commonly Ethereum or a similar programmable network. Once deployed, its code sits at a fixed address and typically cannot be changed, unless the developers built in a specific upgrade mechanism in advance. Anyone can send it a transaction, and the network of validators executes the code exactly as written, updating the blockchain’s shared state as a result. There is no customer service line and, in most cases, no way to reverse an outcome once it has been confirmed.

This differs from a traditional agreement in a fundamental way. A paper contract describes intent in natural language, and a court or arbitrator interprets that intent if a dispute arises. A smart contract has no interpreter. It does exactly what its code says, even when that diverges sharply from what the parties assumed would happen. The phrase “the code is law,” popular in the early days of Ethereum, captures this literally: the outcome is whatever the program computes, not what anyone believes is fair. In practice, this idea has real limits, which the later sections of this guide address.

Where smart contracts actually get used

The concept sounds abstract until it is tied to concrete examples. Three use cases account for most of the activity on programmable blockchains today.

• Decentralized exchange swaps. Protocols built on automated market maker designs let users trade one token for another directly against a pooled reserve, with the exchange rate set by a formula rather than an order book. The smart contract holds the funds and executes the swap in a single transaction.
• Lending and borrowing. DeFi lending protocols use smart contracts to accept collateral, issue loans, track interest, and, if collateral value falls too far, trigger automated liquidation, all without a loan officer reviewing the request.
• Token issuance. Most tokens beyond a blockchain’s native asset, including the majority of assets built on Ethereum, are themselves smart contracts that define supply, transfer rules, and ownership records.

In each case, the appeal is the same: transactions settle automatically, according to public rules that anyone can inspect in advance, without requiring participants to trust a specific institution.

The practical limits of “code is law”

Treating code as the final word sounds clean in theory, but it runs into friction as soon as the code diverges from what people intended. A widely cited example is the 2016 collapse of a project called The DAO, where an attacker exploited a flaw in the contract’s logic to withdraw a large share of pooled funds using functions that, technically, were operating exactly as written. The Ethereum community’s response, a contentious network split that produced Ethereum and Ethereum Classic, remains a live illustration that “the code is law” is a design philosophy, not a law of physics. When the outcome is disruptive enough, participants can still choose to intervene at the level of the underlying network.

Outside such extreme cases, the more common tension is quieter. A contract might execute flawlessly and still produce a result nobody wanted, because the code did not anticipate a particular sequence of transactions, a particular market condition, or a particular combination of inputs. There is generally no built-in appeals process for that.

What can go wrong: the main categories

Reports of smart contract failures tend to fall into a handful of recurring categories, and distinguishing between them matters, because they call for different kinds of scrutiny before relying on a protocol.

• Bugs and exploits. Errors in the code itself, such as flawed access controls, integer overflows, or logic that lets a function be called in an unintended order (a pattern behind many reentrancy exploits), can allow an attacker to drain funds or mint tokens without authorization. These are coding mistakes, and once a contract is live and immutable, they are often difficult or impossible to patch.
• Oracle manipulation. Smart contracts cannot see outside their own blockchain. When a contract needs external data, such as an asset’s price, it relies on an “oracle” service to feed that information in. If an attacker can distort the price an oracle reports, even briefly, they can trick a lending or trading contract into acting on false information, a technique behind a number of high-profile DeFi losses.
• Admin key and upgrade risk. Many contracts include a backdoor by design: an administrator key or a multisig wallet that can pause the contract, change parameters, or upgrade the code. This flexibility helps teams fix bugs quickly, but it also means the system is not fully autonomous. If that key is compromised, or if the team holding it acts maliciously, users face losses that have nothing to do with a flaw in the core logic.
• Economic design flaws. Not every failure is a coding error. A contract can be implemented exactly as intended and still fail because its economic assumptions were wrong, for example an incentive structure that works under normal conditions but breaks down during extreme volatility or a liquidity crunch. This category is harder to audit for, because the code is not “buggy” in a technical sense; the underlying model of how participants would behave was simply incomplete.

Audits, bug bounties, and their limits

Given these risks, most serious projects commission a third-party security audit before launch, and many run ongoing bug bounty programs that pay independent researchers to report vulnerabilities. Both practices meaningfully reduce risk. An audit performed by an experienced firm typically catches common bug patterns, and a well-funded bug bounty gives white-hat researchers a financial incentive to find flaws before attackers do.

Neither is a guarantee. An audit is a review of the code as it existed at a specific point in time, conducted under time and budget constraints, and it cannot prove the absence of every possible flaw, only the absence of the flaws the reviewers thought to look for. Contracts that have passed multiple audits have still been exploited, sometimes through a vulnerability outside the audited scope, sometimes through an economic attack rather than a code-level bug. Treating an audit badge as a certificate of safety, rather than one input among several, is a common and costly mistake.

For anyone using a protocol built on smart contracts, a reasonable baseline includes checking whether the contract has been audited, by whom, how long ago, whether an admin key exists and who controls it, and how the protocol has handled stress in the past. None of this eliminates risk, but it replaces blind trust with an informed judgment, which is the more realistic standard smart contracts were ever able to offer. Readers building this habit across a portfolio may find a broader risk framework, such as the one outlined in roo2ya’s methodology, useful as a starting point, alongside general research practices like DYOR.

This article is for informational purposes only and is not financial advice.