A smart contract is software deployed on a blockchain that runs programmed rules when invoked. It can apply those rules to onchain assets or state, but its behavior depends on its code, inputs, and network; calling it a “contract” does not by itself make it a legally enforceable agreement. This explainer describes the general idea and uses Ethereum only for examples where stated.

What is a smart contract?

In everyday conversation, “contract” often means an agreement between people or organizations. In blockchain technology, a smart contract is a program: it contains rules that determine how the network processes an invocation. On Ethereum, deployed smart-contract code can perform the operations defined by its program, based on the parameters and state that exist when it is called. A Solidity contract, specifically, consists of code—including functions—and data representing its state.

The name should not be mistaken for a legal conclusion. Smart-contract code is not necessarily equivalent to a legally enforceable agreement merely because it is called a contract. This is a technical explanation, not an assessment of any particular arrangement or jurisdiction.

A contract is also not the same thing as a complete application. An Ethereum decentralized application, or dApp, combines a smart contract running on a decentralized network with a frontend user interface. The contract is the onchain program; an application may include additional components that present information and let users interact with it.

How smart contract execution works on a blockchain

A contract does not simply run because it exists. On Ethereum, a user account can invoke a smart-contract function by submitting a transaction to the deployed contract. A state-changing Ethereum transaction is a signed instruction that can transfer value or invoke contract code and change network state. Its fields include a destination and may include value or contract data, along with authorization and fee parameters. source

At a high level, the transaction is submitted to the network, processed under its protocol rules, and included in the network’s agreed history if accepted. Ethereum nodes use a consensus mechanism to agree on new blocks and the continuing chain. The exact execution and validation rules belong to the particular blockchain, so this Ethereum outline is an example rather than a universal transaction sequence. source

For example, a program might define a transfer that occurs when a specified onchain condition is met. That describes a possible programmed action, not a promise that the condition represents an external event accurately or that every application will interpret the rule as expected. On Ethereum, a deployed contract can hold and manage onchain assets and apply programmed actions when receiving or transferring them. Execution still requires a transaction or another supported trigger and enough gas; programmed behavior is only as correct as its code and inputs. source

The terms “execution” and “state” are useful here. Execution is the processing of the program’s rules; state is the data that describes the contract or network at a given point. A state change is therefore not just text displayed in an interface: it is an outcome recorded through the network’s rules. How a network handles execution, fees, and state differs by design, and the general definition does not establish a particular cost or processing time.

What smart contracts can and cannot do

Smart contracts can apply programmed rules to information and assets available within their execution environment. As one implementation example, a Safe smart account can require a configured threshold of owner accounts to confirm a transaction before it can be executed. This is a particular multisignature design, not a required feature of all smart contracts. source

A crucial boundary is the difference between information represented onchain and events outside the blockchain. A program can follow the inputs and conditions it receives, but it does not thereby establish that an offchain event—such as a delivery or a real-world inspection—actually happened. If a system uses an external data mechanism to convey such information, that mechanism and its inputs become part of the assumptions behind the result.

Even when code executes exactly as written, the result can differ from what a user expected. The user may have misunderstood a rule, the supplied input may not match the intended condition, or an application may present the contract’s behavior in a way that obscures what will happen. The definition of a smart contract alone cannot guarantee that its rules reflect a user’s intent or that information supplied to it is accurate.

Risks and limitations to understand

Smart-contract code can have software, compiler, or platform bugs; using Solidity does not by itself guarantee correctness or security. Development practices such as review and testing are recommended, but the existence of code or a deployment is not proof that it is safe.

Interactions with other contracts can create additional behavior. An external contract call can transfer execution control to another contract, which may call back before the original operation is complete and create reentrancy risk. One mitigation pattern is checks-effects-interactions: validate conditions, record internal state changes, and only then interact with external contracts. This reduces a class of reentrancy risk; it is not a complete security proof for arbitrary or multi-contract systems. source

Ethereum interactions are described as irreversible, and contracts cannot be deleted by default. Practical outcomes can still depend on design and network-specific mechanisms, so this should not be expanded into a claim that every blockchain behaves identically. The important operational point is that users should not assume an erroneous action can simply be undone.

Other dependencies can matter too. Smart-contract composability allows contracts to call or reuse independent onchain components through public interfaces. Each dependency adds its own behavior, availability, upgrade, permission, and economic assumptions to the caller’s system. A contract therefore cannot be evaluated solely by reading its name or intended purpose; the rules and components it relies on also affect how it behaves.

Technical execution and legal effect are separate questions. This article does not decide whether any particular code or arrangement is enforceable, or what legal, tax, or compliance duties apply. Those questions depend on the relevant context and jurisdiction and call for current, qualified guidance rather than a general technical definition.

For separate questions about writing contracts in Solidity, decentralized-application architecture, or token standards, consult dedicated guides on Solidity, dApps, ERC-20 tokens, and ERC-721 tokens. The core distinction is straightforward: a smart contract is a blockchain program that applies coded rules when invoked, while its practical outcome remains bounded by its code, available inputs, network, and dependencies.

Sources and references