Once a blockchain transaction calls deployed code, there is no operator deciding whether the requested function feels reasonable. The network executes the program under its rules. That program is commonly called a smart contract.
It receives transactions, checks conditions and changes onchain state according to its code. “Smart” refers to automation; “contract” describes only part of its possible context. Legal enforceability and the parties’ intent remain separate questions.
Smart contracts make tokens, exchanges, lending markets and governance systems possible. They also make software defects financially consequential because public functions may control assets and can be called by strangers.
How a smart contract runs
A developer writes source code in a language supported by the target network and compiles it into instructions the network can execute. Deployment stores that code or a reference to it at an address. Users and other contracts send transactions to call its functions.
Each validating node executes the same transaction under the same protocol rules. If the call succeeds, the resulting state change can be included in a block. If a condition fails, the call may revert, although the sender can still pay a network fee for the computation attempted.
On Ethereum, contracts cannot initiate activity on their own. An account, automated service or another contract must call them. The official Ethereum introduction describes them as programs at blockchain addresses rather than intelligent agents.
What smart contracts can do
A contract can issue and transfer tokens, hold collateral, calculate an exchange rate, distribute payments, enforce voting rules or coordinate a multisignature account. Contracts can call one another, creating applications from reusable components.
This composability underpins decentralised finance and DAOs. It also means an application may inherit risks from several contracts that its interface does not make obvious.
What they cannot know
A blockchain contract can read onchain state. It cannot independently know a market price, weather result, delivery status or court judgment. An oracle or authorised party must bring external information onchain.
The oracle problem is not solved merely by adding a data feed. The application must evaluate data sources, update frequency, manipulation resistance, downtime and what happens when sources disagree. Deterministic code will execute an incorrect input consistently.
Likewise, a token representing a physical asset does not prove ownership of that asset unless the surrounding legal and operational system recognises the link. Smart contracts can automate performance; they cannot eliminate every dispute or offchain dependency.
Immutable code, upgradeable systems
Code deployed directly at an address may be difficult or impossible to replace. Many applications instead use proxy patterns: users interact with a stable address that delegates execution to logic an administrator or governance process can upgrade.
Upgradeability can repair defects and add features, but it introduces authority. Users should ask who controls the upgrade key, whether a multisig and timelock are used, and whether an emergency pause exists. “The contract is onchain” does not answer those questions.
Verified source code is also not the same as an audit. Verification shows that published source corresponds to deployed bytecode. An audit examines selected security properties at a point in time and may miss defects. The deployed version, configuration and integrations still matter.
Common smart-contract failures
- Access-control errors: sensitive functions are callable by the wrong account.
- Reentrancy and unsafe external calls: another contract regains control before state is safely updated.
- Oracle manipulation: a temporary or artificial price causes improper borrowing or liquidation.
- Accounting and precision errors: rounding, decimals or share calculations transfer value unexpectedly.
- Signature mistakes: messages can be replayed, mis-scoped or presented deceptively.
- Denial of service: gas costs, loops or dependencies prevent an expected action.
- Upgrade and key compromise: authorised control is abused or stolen.
Ethereum’s security guidance emphasises access control, testing, handling failures and oracle design. Our overview of smart-contract languages and runtimes explains why network and execution environment must be chosen before a language.
How a user can inspect a contract interaction
Start from a verified official source and confirm the chain and contract address. A block explorer can show whether source code is verified, whether the address is a proxy and which transactions or events it has produced. These signals help but do not certify safety.
When a wallet opens, read whether the request is a transaction, token approval or offchain signature. Check the spender, amount and permission scope. Unlimited approvals are convenient but increase the loss possible if the approved contract or interface is compromised. Hardware signing can protect a private key while still authorising a malicious request displayed to the user.
For developers, security starts with a small specification: assets controlled, trusted roles, invariants, external calls and failure behaviour. Tests, static analysis, fuzzing, independent review, monitoring and a documented incident process address different failure classes. None is a guarantee by itself.
Before trusting one, a user should be able to identify the assets it controls, the people who can change it and the external data it consumes. Those three facts reveal more than the promise that the code will “run automatically.”
Editorial note: this guide was fully reviewed and rewritten on September 3, 2026.
