Smart contract
A smart contract is deployed code and persistent state that applies deterministic rules when a blockchain transaction or another contract calls it.
Category: GovernanceHexagon category cue
System record
Start with the economic purpose, participants, resources, and entitlements before studying implementation detail.
Why it exists
Smart contracts let financial rules, custody conditions, claims, and multi-party state transitions execute through shared code rather than one operator's private system.
Traditional-finance analogy
Automated rulebook and transaction agent is the closest comparison recorded for this concept.
Where the analogy stops
- A smart contract executes the code that was deployed; legal intent, user expectations, and off-chain facts do not automatically alter its behavior.
- Public contracts can be composed and called by adversarial programs in one atomic transaction, creating execution paths unlike isolated back-office automation.
Main actors
- ActorUser or calling contract
- ActorDeveloper and deployer
- ActorAdministrator, guardian, or governance authority when present
- ActorAuditor, monitor, and integrator
Assets and claims
Assets — controlled or transformed resources
Assets are resources the mechanism moves, holds, values, or transforms.
- AssetAssets held, transferred, or approved to the contract
- AssetNative asset used for execution fees
Claims — entitlements and corresponding dependencies
Claims are rights to value, repayment, redemption, control, or another party's performance; each depends on an obligation or system that must honor it.
- ClaimContract-recorded balance, share, debt, or withdrawal entitlement
- ClaimConditional right produced by the contract state machine
A smart contract is a program in shared blockchain state that accepts calls and applies its encoded transition rules to assets, claims, and permissions.
Why it exists
Section titled “Why it exists”Financial arrangements repeatedly test conditions, update balances, enforce limits, and settle between participants. Smart contracts make those rules shared and executable so users and other programs can compose with them. The code narrows some discretionary trust, but it also makes software behavior, configuration, external data, and administrator authority part of the financial contract.
Traditional-finance analogy
Section titled “Traditional-finance analogy”An automated rulebook or transaction agent is a useful analogy. The analogy stops because deployed code follows machine state rather than interpreting legal intent, and public contracts can be called by unknown or adversarial programs in one atomic transaction. Immutable code can be hard to repair; upgradeable code adds a separate controller and change process.
Actors, assets, and claims
Section titled “Actors, assets, and claims”Users and other contracts call the program. Developers define it, deployers initialize it, and administrators or governance may retain powers. Auditors and monitors can inspect behavior but do not guarantee it. Contracts may hold assets or allowances and record shares, debts, withdrawal rights, votes, or conditional entitlements. Those entries are claims only to the extent that the state machine and its dependencies can honor them.
Mechanism and flows
Section titled “Mechanism and flows”- Code and initial state are deployed at an address or behind a governed upgrade mechanism.
- A transaction or another contract calls a public function with parameters.
- The execution environment evaluates authorization, current state, input, and called dependencies deterministically.
- Successful execution commits state changes and events; a revert rolls back the failed call context while still consuming execution resources.
- Later calls observe and build on the committed state.
Capital flow follows transfers and approvals. Claim flow follows minted shares, recorded debt, receipts, and redemptions. Information flow enters through calldata, block context, or explicit oracle calls—a contract cannot independently fetch arbitrary off-chain facts. Return flow belongs to the economic mechanism the code implements, not to code itself. Control flow follows roles, upgrade keys, pauses, parameter setters, and external dependencies. Risk flow reaches holders when any assumption breaks.
State and loss allocation
Section titled “State and loss allocation”| Stage | Assets | Claims and liabilities | Control question |
|---|---|---|---|
| Before call | Existing custody and allowances | Existing balances, debt, or shares | Who may call this transition? |
| During call | Temporary transfers and callbacks may occur | Intermediate accounting may exist | Can reentrancy observe an unsafe state? |
| Successful return | Final transfers persist | Final accounting persists | Were all invariants restored? |
| Revert | Failed call state rolls back | Failed call accounting rolls back | Did an external side effect escape the boundary? |
Smart contracts do not create return from nothing. Borrowers, traders, token issuance, reserve assets, or other counterparties pay any yield. When code creates excess claims, loses assets, blocks exits, or trusts a bad dependency, depositors, liquidity providers, debt holders, token holders, a reserve, or an explicit backstop absorbs the shortfall.
Beginner lens
Section titled “Beginner lens”Code is the rule executor, not a promise that the outcome is fair, safe, or legally enforceable. Ask what assets it can move, what claims it records, and who can change its rules.
Practitioner lens
Section titled “Practitioner lens”Inventory addresses, versions, upgrade and pause authority, oracle inputs, token assumptions, parameter bounds, integration dependencies, liquidity, incident procedures, and monitoring. A protocol name is not enough: the active deployment and configuration determine behavior.
Engineer or auditor lens
Section titled “Engineer or auditor lens”On Ethereum, contract code and state live at an address and execute in the EVM when called through transactions or internal messages. Ethereum contracts cannot pull web data by themselves; applications use transactions or oracle systems to place external information on-chain. Other execution environments can use different languages, account models, runtimes, and upgrade patterns.
Security review notes
Section titled “Security review notes”Review authorization, initialization, state-machine completeness, conservation, solvency, reentrancy, callbacks, unusual tokens, rounding, failure atomicity, upgrades, pauses, and recovery. Testing, audit, and formal verification cover identified code, properties, and assumptions; none should be described as absolute safety.
Common misunderstandings
Section titled “Common misunderstandings”- “Smart means intelligent.” A smart contract executes programmed rules; it does not reason about missing context.
- “Code is law.” Code controls on-chain execution, while legal rights and governance can exist outside it.
- “Audited means safe.” Review reduces uncertainty within a scope; unknown paths, integrations, configurations, and later upgrades remain.
Prerequisites and learn next
Section titled “Prerequisites and learn next”Read blockchain and transactions and gas first. Continue with settlement and finality before relying on contract results across systems. Review smart-contract risk for failure analysis.
Sources
Section titled “Sources”- Ethereum.org, Introduction to smart contracts — Ethereum contract, state, execution, and off-chain-data boundaries (accessed 2026-08-09).
- The supplied DeFi seed, sections 2, 7–12, and 14 — programmable primitives, system analysis, and the blockchain stage.
Machine-readable model
Key equations
Canonical expressions come from the structured concept record. KaTeX renders the notation, while the plain-text expression and variable table keep its meaning and units inspectable without JavaScript. Read the narrative above for the model's domain, assumptions, and rounding rules.
This concept does not require one canonical equation. Its mechanism and state transitions remain the authoritative explanation; do not invent a formula merely to make the topic look quantitative.
Assurance contract
Security properties
These structured statements define desired behavior. Their stable IDs can bind tests, invariants, specifications, audit findings, or proof results without turning descriptive review advice into an assurance claim.
Desired · not evaluated: No test, audit, or proof result is implied until scoped evidence is linked to this property.
Every state transition enforces its authorization, preconditions, accounting, and lifecycle rules
External calls and reentrancy cannot expose an unauthorized intermediate or final state
Asset and claim accounting remains conserved under success, revert, and adversarial call ordering
Upgrade, pause, recovery, and administrator powers are explicit, bounded, and observable
Knowledge check
Quiz
Answer in your own words, then open the model answer.
Can a smart contract read a current web price by itself?
Model answer
No. External data must enter through an on-chain transaction or another protocol mechanism such as an oracle, which adds its own trust assumptions.