Skip to content
Financial Context Wiki

Smart contract

Learn what a smart contract is, how blockchain nodes execute it, where external data and upgrade authority enter the design, and what users should verify before interacting.

Updated

For educational purposes only; not investment advice. Smart-contract transactions can cause irreversible loss.

Direct answer

A smart contract is a program deployed to a blockchain or similar distributed execution network. It contains code and, on many platforms, persistent state. A transaction or another contract can call its functions; network nodes execute the same rules and accept the resulting state change through the network’s validation and consensus process.

“Smart” does not mean that the program understands intent, and “contract” does not automatically make it a legally enforceable agreement. The term describes code that can enforce specified conditions within the capabilities and data available to its execution environment.

Smart contracts can:

  • hold or transfer digital assets under programmed conditions;
  • record and update application state; and
  • compose with other contracts to build exchanges, lending systems, games, governance tools, and other onchain applications.

Their predictability is limited to the implemented code and inputs. A contract can execute exactly as written and still produce an unwanted result because of a defect, a malicious design, compromised privileges, or incorrect external data.

How it works

A typical interaction follows these steps:

  1. Developers write and test source code, compile it when the platform requires compilation, and deploy the resulting program in a transaction.
  2. Deployment assigns the program an onchain identifier or address and may initialize its state and administrative roles.
  3. A user, application, or another contract sends a call containing a function selector, parameters, and sometimes assets.
  4. Each validating node executes the call according to the same virtual-machine and protocol rules. If a required condition fails, the call may revert while the transaction fee can still be charged.
  5. If the call succeeds and the network includes it, the resulting state changes and emitted events become part of the blockchain record.

Execution is deterministic only for information available within the agreed execution context. A contract cannot independently fetch weather, a market price, or a bank payment from the internet. Applications that need offchain facts use an oracle, signed message, bridge, or privileged operator, adding trust and failure assumptions beyond the contract code.

Deployed code is not always the whole system. Some contracts are immutable, while proxy and governance patterns can route calls to new logic or change parameters. Users therefore need to inspect upgrade keys, administrator powers, pause controls, oracle design, and connected contracts as well as the visible application interface.

Before signing an interaction, verify:

  • the network and full contract address from an independent trusted source;
  • the decoded function, parameters, asset amounts, and recipient;
  • token allowances or operator permissions created by the call;
  • whether the contract is verified, upgradeable, paused, or controlled by privileged accounts; and
  • that a small test covers the intended entry and exit path when practical.

Example

Consider an escrow contract for a digital service. A buyer deposits 1,000 USDC, and the contract records the buyer, seller, amount, and settlement condition. If the buyer approves delivery, the contract releases the funds to the seller. If the condition is not met within 24 hours, the programmed refund path becomes available.

The contract does not know whether the service was satisfactory unless the design supplies that fact. If approval comes from the buyer’s key, a compromised key can authorize release. If an oracle or administrator decides the outcome, that party becomes part of the trust model. A bug in access control or token handling can also defeat the intended escrow rule. Automatic execution removes some manual processing, but it does not remove the need to evaluate every dependency.

Risks and controls

  • Code defects: reentrancy, incorrect accounting, unsafe external calls, or edge cases can lose or lock assets. Prefer small, well-tested designs and review the deployed code rather than relying only on an audit badge.
  • Privilege and upgrade risk: an administrator may pause the system, replace logic, change fees, or move assets. Check who controls each role, whether a timelock or multisignature is used, and what can change.
  • Oracle and integration risk: correct code can act on stale, manipulated, or incorrectly scaled data, and failures in tokens, bridges, or other contracts can propagate through composition.
  • Transaction and approval risk: a malicious interface can present the wrong address, function, recipient, or unlimited allowance. Decode the request and limit permissions to the required scope.
  • Economic design risk: valid transactions can still trigger liquidation, price manipulation, incentive failure, or a run on limited liquidity. Code correctness is not economic solvency.
  • Operational risk: congestion, chain reorganizations, sequencer outages, or unavailable front ends can delay an action even when the contract remains deployed.
  • Irreversibility: public-chain transactions generally lack a chargeback mechanism. If funds are sent through the wrong function or to a hostile contract, recovery may be impossible.

An audit is evidence about a defined code version and scope, not a warranty. Check whether the deployed bytecode or verified source matches the reviewed version and whether later upgrades, dependencies, or configuration changes fall outside the audit.

Common misconceptions

  • “The code executes automatically without a transaction.” Most state-changing functions need a transaction or another onchain call; an external keeper may be required to trigger time-based actions.
  • “The code cannot change.” An immutable contract cannot rewrite its own deployed bytecode, but proxy, governance, and migration designs can change the logic users reach.
  • “Public code is safe code.” Visibility helps review, but it does not prove correctness, honest administration, or sound economics.
  • “An audit guarantees safety.” Reviews are bounded in time and scope and can miss defects or exclude operational and economic risks.
  • “A successful transaction means the intended action occurred.” Success means the called code did not revert; users must still check the destination, decoded events, asset movements, and resulting permissions.

Sources

Navigation

Search the wiki...