A smart contract is a program stored at an Ethereum address. When a transaction calls one of its functions, network nodes execute the same instructions and calculate the same result. The contract can update its records, move assets it controls, call another contract, emit an event, or reject the request when conditions are not satisfied.
The word smart can be misleading. Contracts do not understand intentions, discover truth independently, or repair ambiguous agreements. They apply encoded rules to available inputs. Their value comes from predictable shared execution, while their danger comes from the same rigidity: flawed code can enforce the wrong result consistently and at scale.
What you will learn
- Trace a contract call from signed transaction to state update
- Explain storage, functions, events, and contract-to-contract calls in plain language
- Distinguish protocol enforcement from legal interpretation and external truth
- Review permissions, upgrades, and token approvals before interacting
Code and state at an address
A deployed contract has an address, executable bytecode, and persistent storage. Bytecode is the low-level instruction format Ethereum executes, usually produced by compiling a higher-level language such as Solidity. Persistent storage holds values that must survive between transactions, such as account balances, loan positions, ownership records, or configuration settings.
Contract functions define possible interactions. Some functions only read existing data and can be queried locally without changing Ethereum. Others write state and therefore require a transaction, network inclusion, and gas. Visibility rules and access checks determine which callers may use sensitive functions, but those checks are only as sound as the implementation.
What happens during a call
A user first prepares a message containing the destination contract, encoded function name and arguments, optional ETH value, and fee settings. The wallet displays a request for approval and signs it with the account's key. After broadcast, a validator may include the transaction in a block, and nodes execute it against the current state.
Execution is atomic at the transaction level. If a required condition fails and the call reverts, its state changes are undone, although the sender still pays for work already performed. A successful call commits all resulting changes together. This all-or-nothing property enables multi-step financial operations, but nested calls can still create surprising behavior and security vulnerabilities.
Assets, approvals, and composition
Contracts can hold ETH and can control tokens according to each token contract's rules. A common token pattern requires an owner to grant an allowance before another contract can transfer tokens on the owner's behalf. The approval and the later transfer are separate actions, which is why an unused or unlimited allowance can remain dangerous after one interaction ends.
One contract can call another during the same transaction. An application might borrow an asset, exchange it, deposit the result, and verify final collateral before completion. This composition makes reusable onchain services powerful, but it also joins their failure modes. A defect, pause, price error, or malicious upgrade in one dependency can propagate into an otherwise sound contract.
External facts require bridges called oracles
Ethereum can verify its own state, signatures, and computations, but it cannot directly observe a market price, weather event, shipment, or bank payment. An oracle is a mechanism that brings external information onchain. The contract then trusts the oracle's reporting method, update timing, data sources, and resistance to manipulation.
This boundary matters because deterministic code can still produce a wrong real-world outcome from a bad input. A lending contract may liquidate collateral exactly as programmed if its price feed reports an incorrect value. Designers reduce this risk with multiple sources, delay checks, bounded changes, and emergency controls, each of which introduces further trade-offs.
Immutability, upgrades, and review
Contract code at an address does not normally rewrite itself, but many systems use proxy patterns that route calls to replaceable logic. Upgradeability can repair defects and adapt features, yet it gives whoever controls the upgrade process substantial power. Timelocks, multisignature approvals, public notices, and constrained permissions can reduce that power without making it disappear.
Before signing, users should identify the actual contract address, requested function, assets at risk, token allowances, upgrade authority, pause controls, and reliance on oracles. Audits provide useful evidence but cannot prove absence of bugs. Source-code verification helps readers compare published code with deployed bytecode, although meaningful interpretation still requires expertise and context.
Common misconceptions
“Smart contracts are automatically safe because Ethereum executes them.”
Ethereum faithfully executes valid bytecode, including buggy or malicious logic; protocol correctness does not certify application design.
“A smart contract is the same as a complete legal agreement.”
Code enforces defined state transitions but may not capture identity, intent, jurisdiction, remedies, or ambiguous real-world circumstances.
“An audited contract cannot lose user funds.”
An audit is a scoped review at a point in time and can miss defects, economic attacks, configuration errors, or risky dependencies.
Risks and limitations
- Programming errors, economic design flaws, or unexpected contract composition can lock, misprice, or transfer assets incorrectly.
- Unlimited token allowances let an approved contract transfer more tokens later if that contract or its upgrade authority is compromised.
- Administrator keys, proxy upgrades, and pause controls can change expected behavior or concentrate control in a small group.
- Oracle manipulation, delayed updates, or unavailable external data can make otherwise correct contract logic act on false information.
Key takeaways
- A smart contract is code and persistent state stored at an Ethereum address.
- State-changing calls require signed transactions, gas, execution, and block inclusion.
- A reverted transaction undoes state changes but still consumes paid computational work.
- Composition extends functionality while linking the risks of several contracts and data sources.
- Users should inspect permissions, allowances, upgrades, and external dependencies, not merely audit labels.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.