A smart contract is a program stored at an address on a blockchain that can run when a transaction invokes it. It applies rules written in its code and can update blockchain state or manage onchain assets, but it does not think like a person or guarantee that its programmed outcome is correct. source source
What a smart contract is
In plain language, a smart contract is software that lives within a blockchain environment. On Ethereum, for example, a contract has code and data stored at a specific blockchain address. Its code contains functions, and its data represents the contract’s state—the information it retains as the network processes interactions. source source
The word “contract” can be misleading. In this technical context, it names a program, not a conclusion that the program is automatically a legally enforceable agreement. Whether an arrangement has legal effect depends on facts and jurisdiction; this explanation does not assess that question.
A contract can apply programmed rules to assets or information onchain. For example, code might hold an asset and perform a specified action when invoked. The program’s behavior is limited to what its code and the blockchain environment support.
How smart contract execution works
A basic interaction follows a simple path:
- An instruction is submitted. A user or another program sends a transaction that invokes the contract, often providing data for the requested operation. On Ethereum, a user account can invoke a contract function by submitting a transaction to the deployed contract.
- The network processes it. The blockchain processes the transaction, and the contract’s code applies its programmed rules. Smart contracts are reusable programs deployed into blockchain state and invoked through transaction requests. source
- The outcome changes state or returns information. If the operation changes the contract’s persistent data or other onchain state, that result becomes part of the network’s state according to its protocol. A contract can also emit events for applications to process. source
This sequence describes an Ethereum-style interaction, not a universal implementation for every blockchain. Networks can differ in their execution and storage models.
Execution is not human judgment. The program evaluates the inputs and conditions it was given according to its code. It cannot independently decide that a result is fair, sensible, or what a person intended. A result may follow the code exactly and still be wrong for the people relying on it.
A simple example: conditional payment
Imagine a program intended to release a payment after it receives a record that a delivery condition has been met. This is an illustration, not a recommendation for building or using an escrow system. The contract can check the condition represented in its available data; it cannot observe a physical delivery by itself.
If the condition depends on an offchain fact—something that happens outside the blockchain—some mechanism must bring that information into the contract’s decision process. An oracle is one such connection between offchain data or services and onchain contracts. That connection introduces its own assumptions about the information, its timeliness, availability, and trustworthiness. source
The practical distinction is between a real-world event and a record of that event. The program can act on the record supplied to it; the record does not, by itself, prove that the underlying event happened as described.
What smart contracts can and cannot guarantee
A smart contract automates execution of its programmed rules. Automation does not prove that the code matches its author’s intent, that its inputs are accurate, or that its result is appropriate. Programmed behavior is only as correct as the code and inputs.
Contracts may also call or reuse other onchain components through public interfaces. This composability can make a contract depend on behavior beyond its own code. Each dependency adds assumptions about behavior, upgrades, permissions, availability, and economics. source
A blockchain record can show the state changes and events that the network recorded, but a record is not, by itself, evidence that the underlying inputs were true or that the action was secure, lawful, or reversible. These questions require evidence beyond the basic fact of onchain execution.
Smart contracts in decentralized applications
A decentralized application, or dApp, may combine one or more smart contracts with a frontend user interface. The contract carries out onchain program logic; the interface is a separate way for a person to interact with the application. Hosting, key management, indexing, and other supporting services can still create dependencies outside the contract.
So, when someone describes a feature as “powered by a smart contract,” the phrase identifies a part of the system—not necessarily the whole experience or every service involved. The useful question is what rules the contract actually applies, what information those rules rely on, and which other components the process depends on.
Sources and references
- Introduction to smart contracts — ethereum.org; retrieved 2026-10-19.
- Technical intro to Ethereum — ethereum.org; retrieved 2026-10-19.
- Anatomy of smart contracts — ethereum.org; retrieved 2026-10-19.
- Smart contract composability — ethereum.org; retrieved 2026-10-19.
- Smart Contract Overview — Chainlink Documentation; retrieved 2026-10-19.