Smart contracts in plain English
A smart contract is a program executed by a blockchain. On Ethereum, it consists of code and persistent data at a contract address. Users or other contracts call its functions through transactions, and every validating node reaches the same result from the same state and inputs.
The name does not mean that every smart contract is a legally enforceable contract, intelligent, autonomous, or safe. It is deterministic software. Legal rights can depend on separate terms, identity, jurisdiction, and off-chain facts.
A contract will faithfully execute a bug or malicious rule as readily as a well-designed rule.
Code, state, and address
Contract code defines permitted functions. Contract state records values such as token balances, owners, collateral, votes, or configuration. The address identifies the deployed contract on one network.
An address is not globally unique across chains. The same-looking address on Ethereum, a layer two, and another EVM-compatible chain can point to different code or nothing at all. Always pair address with network identifier.
Users normally interact through a web interface, but the blockchain only sees the signed transaction sent to the address. A polished website can direct a wallet to a malicious contract.
Deployment and execution
Developers write source code, often in Solidity or Vyper for Ethereum, compile it to bytecode, and deploy it in a transaction. Deployment consumes gas and creates an address.
A later transaction can:
- transfer value to the contract;
- call a function with encoded parameters;
- update state;
- emit log events; or
- call other contracts.
Execution can succeed, revert intentionally, or fail because of an error or insufficient gas. A revert normally rolls back state changes in that call, but the sender still pays for computation already performed.
Smart contract versus traditional contract
A traditional contract expresses obligations between identifiable parties and can be interpreted or enforced through legal institutions. A smart contract executes code under network rules.
The two can be connected, but code cannot resolve every ambiguity. A delivery can be defective, a person can lack legal capacity, or an oracle can report incorrect information. The blockchain does not automatically know those facts.
Describe a smart contract as automated transaction logic, not as a replacement for law. For material arrangements, identify both the code and the governing legal terms.
The vending-machine analogy
Ethereum documentation compares a smart contract to a vending machine: a defined input triggers a defined output. The analogy explains deterministic behavior but hides important complexity.
A financial contract can depend on changing prices, many users, external tokens, governance votes, upgradeable modules, and other protocols. Its output can also be manipulated by transaction ordering or insufficient liquidity.
Use the analogy only for the basic execution model. Real systems need threat modeling, testing, audits, monitoring, and emergency procedures.
Tokens and approvals
Token contracts record balances and implement transfer functions under a standard interface. An approval lets a spender contract transfer tokens up to a permitted amount.
An unlimited approval can remain active indefinitely. A malicious or later-compromised spender can use it without asking for a new approval transaction. Review the spender address, amount, network, and deadline before signing, and revoke unused permissions.
A token name or symbol is not unique. Verify the contract address from authenticated issuer documentation. Anyone can deploy a token called “USDC,” “ETH,” or another familiar label.
Oracles and off-chain data
Contracts cannot independently fetch a stock price, sports score, weather reading, or bank balance. An oracle supplies data through transactions or cryptographic proofs.
Oracle design creates risk:
- one provider can be wrong or unavailable;
- a thin market can be manipulated;
- stale data can trigger incorrect liquidations;
- update thresholds can lag fast moves; and
- governance can replace a feed.
Inspect data source, aggregation, update frequency, fallback behavior, and what the contract does when the oracle fails.
Upgradeability and administrator powers
Deployed bytecode is persistent, but many applications use a proxy whose storage points to replaceable logic. An administrator, multisignature wallet, governance vote, or timelock can authorize upgrades.
Upgradeability can repair bugs and adapt a product, but it also means current rules are not permanently fixed. A compromised key or rushed vote can replace safe logic with dangerous code.
Identify who can upgrade, pause, freeze, mint, seize, change fees, replace an oracle, or withdraw assets. Check signer count, timelock delay, and whether emergency powers bypass the delay.
Composability
Contracts can call other contracts like public software components. A lending protocol can use a token, decentralized exchange, oracle, and liquidation service in one workflow.
Composability makes development powerful and failures contagious. A safe core contract can lose money because a dependency depegs, pauses, changes its interface, or returns a manipulated price.
Build a dependency map. Do not evaluate only the contract where funds are deposited; evaluate every asset, oracle, bridge, and protocol on which the position relies.
Audits and verified source code
A block explorer can show source code that matches deployed bytecode. Verification helps inspection, but it does not prove the code is safe or that the displayed interface uses that address.
An audit reviews a particular code version, scope, and set of assumptions. Read the report date, commit hash, unresolved findings, exclusions, and whether deployment matches the audited version. A logo saying “audited” is insufficient.
Bug bounties, formal verification, long production history, limited permissions, and transparent incident response are useful evidence. None eliminates risk.
Common vulnerability classes
Smart-contract failures can involve:
- reentrancy, where external calls reenter state-changing logic;
- access-control errors;
- arithmetic or accounting mistakes;
- unsafe external calls;
- price-oracle manipulation;
- flash-loan-enabled economic attacks;
- signature replay or domain errors;
- front-running and transaction ordering;
- initialization and proxy mistakes; and
- governance or key compromise.
Security is not merely preventing a hacker from entering. A protocol can work as coded and still have incentives that make insolvency rational.
Transaction simulation and signing
Modern wallets can simulate expected asset changes. Simulation is helpful but can be stale, incomplete, or manipulated by conditions that change before inclusion.
Review:
- network and contract address;
- function and parameters;
- tokens leaving and arriving;
- approval amount and spender;
- minimum output and slippage;
- deadline and nonce;
- gas ceiling; and
- warnings about unknown or blind data.
A signature without a gas fee can still authorize a valuable action, such as a permit or marketplace order. Never equate “free to sign” with harmless.
Multisignature contracts
A multisignature contract can require a threshold of authorized signers before execution. It reduces reliance on one key and is common for treasuries and administration.
A 3-of-5 policy is only as independent as the five signers, devices, organizations, and recovery processes. If one person controls several keys, the visible threshold overstates protection.
Review signer identity, replacement process, modules, spending limits, and transaction history. A multisig also cannot correct malicious logic that every signer approves.
Fees, failure, and irreversibility
Contract interactions generally use more gas than a simple transfer because more computation and storage are involved. If execution reverts, the intended state changes roll back but gas remains consumed.
The network does not provide a credit-card chargeback. A contract can implement its own cancellation or refund path, but only the code and authorized parties can use it.
Test with a modest amount, especially on a new protocol or bridge. A successful small transaction does not prove a larger one is safe, but it catches wrong networks, addresses, and basic workflow errors.
Taxes and legal rights
Swaps, rewards, liquidations, token receipts, and contract fees can create U.S. tax events. The transaction hash records what occurred technically; it does not determine basis, ownership, income character, or legal classification by itself.
Preserve transaction records and the terms in effect. If a smart contract represents an off-chain asset, identify the issuer, custodian, redemption right, governing law, and insolvency treatment.
A contract-risk checklist
Before depositing meaningful value:
- verify chain and address independently;
- identify developer and deployment history;
- inspect verified source and audit scope;
- map upgrade, pause, mint, and withdrawal powers;
- understand every token, oracle, bridge, and dependency;
- calculate liquidation and slippage behavior;
- review incident history and bug bounty;
- limit approvals and exposure; and
- plan how to exit if the interface disappears.
Do not rely on total value locked, celebrity promotion, or a high yield as proof of safety.
Common smart-contract misconceptions
Smart contracts are not artificial intelligence. Public code is not automatically audited. “Immutable” does not apply when a proxy can upgrade logic. A decentralized application can have centralized keys and a centralized website.
The strongest question is not “Does it use a smart contract?” It is “What exact code and powers control my assets, what does the system depend on, and what remedy exists when something goes wrong?”