What is a smart contract?

A smart contract is a program deployed on a blockchain network that runs according to its code once a transaction or another program calls it. It can read inputs and onchain data, check predefined conditions, and update the data the blockchain stores when execution succeeds.

"Smart" does not mean the program thinks for itself, and "contract" does not guarantee that it forms a contract in law. The name points to something narrower: participants can write a set of operating rules as code, and the nodes that run the blockchain software and check transactions process it according to the protocol, instead of a single server deciding the outcome on its own.

Start by separating code, state and calls

Code defines which operations the program can perform and the conditions each operation requires. State is the data the program currently stores onchain, such as balances, owners, parameters or approvals. A transaction or call supplies the sender, the function and the inputs for this particular execution, and triggers the program to read or change state.

The same code can produce different results from different inputs, or against a different current state. "Executing according to the code" therefore does not mean a contract returns the same answer every time. It means that under the same chain rules, current state, transaction inputs and execution context, validators should arrive at the same result. Execution context includes the caller, the block time and other information the protocol supplies for that execution.

A contract also does not wake up on its own to check the time, a price or a real-world event. It normally waits for a transaction or a protocol message to trigger it. If the program needs offchain information such as a market price, the weather or a match result, a data mechanism such as an oracle has to submit that information onchain first. A contract can only execute on the data it receives; it cannot prove on its own that external information is true.

The problem smart contracts address

In an ordinary application, the core logic usually runs on servers controlled by the developer or service provider. Users send requests to the server, and the server reads a database, applies the rules and returns a result. Whoever operates that server can update the program, change database permissions, or stop the service.

A smart contract moves part of that program logic and state into the blockchain's shared execution environment. Once the network confirms a qualifying transaction, nodes compute the result under the same set of rules and write valid state changes into the ledger. Participants can check the transaction and the outcome independently, rather than relying only on records supplied by an application backend.

This does not mean the application no longer needs operators or servers. Websites, mobile apps, data indexing, notifications and customer support may still come from centralized systems, and the contract itself may retain administrator permissions. To judge how an application is controlled, look separately at the onchain program, the offchain services that do not run on the blockchain, and the keys that can use administrative rights.

From deployment to execution

Blockchains do not all use the same name or the same handling for smart contracts, but the process usually passes through deployment, a call, execution and recording.

Deploying the program to the network

A developer first writes the program in a language the network supports, then converts the code into a form the network's execution environment can process. Deployment usually happens through a special transaction; once the network confirms it, the program receives an onchain identifier that other accounts or programs can call.

The deployer can set initial data and permissions in the program, such as who may pause a function, change a parameter or approve an upgrade. Not every contract has these permissions, and they do not disappear automatically because the code is called a "smart contract".

A user or a program sends a call

A user typically initiates a transaction through a wallet or an application interface, specifying the function to call and the input data. Another smart contract can also call it during execution, which is how several programs are composed into a single operation.

The button label or wallet prompt shown before a call is only the interface's interpretation of the transaction. What is actually submitted is encoded data. If the interface displays it incompletely, connects to the wrong address or hides additional permissions, what the user signs may do something different from what they believed they were approving.

Nodes execute and verify the result

Networks differ on who executes first and who verifies afterwards. On many execution-oriented public chains, validating nodes re-execute or check contract execution under the same rules to confirm the state changes a transaction produces. The program reads current state and inputs, checks conditions in order and computes a result.

On Ethereum, for example, smart contracts are called by transactions and executed in the Ethereum Virtual Machine. In Hyperledger Fabric, a comparable program is called chaincode: nodes that satisfy the endorsement policy first simulate execution and sign the result, after which the peer nodes on the channel check the endorsement signatures and the read-write records, and only verified transactions update current state. An endorsement policy is simply the rule network members agree in advance about which organizations' nodes must approve a result. These differences show that "smart contract" names a category of program rather than one public chain's particular implementation.

Writing state or returning a read

A call that changes onchain state has to be confirmed as a transaction. A program might update a token balance, record an approval, or change who holds a digital item. When execution fails, the expected state change usually does not take effect, although the sender may still bear the processing fee the network has already consumed; the specific rules are set by the network.

Reading existing state usually does not require a new onchain transaction. An application can query a node for a balance, a parameter or a record, and the node returns the result locally. Because nothing in the shared state changes, such a read does not need network-wide reconfirmation. Networks and service providers may still set their own arrangements for query methods or fees.

How a smart contract differs from an ordinary contract

A smart contract is first of all a program; an ordinary contract is first of all a legal arrangement between parties. The two can be connected — parties may use a program to make a payment or record performance — but similar names do not make them inherently the same thing.

What a program can evaluate is the data its code can read and the conditions it states explicitly. It will not necessarily understand what the parties actually intended, handle ambiguous terms, identify fraud, or determine a remedy in the real world. Whether an onchain outcome corresponds to a legal right, and how a dispute is handled, depends on the specific arrangement and the applicable rules; it cannot be concluded from the name of the code.

The reverse also holds: a legal contract does not have to use a smart contract. It can be recorded and performed through conventional systems. To assess the relationship between the two, ask separately what the code actually does, and what legal or service arrangement the parties have agreed apart from it.

How a smart contract differs from a decentralized application

A smart contract is usually only one part of a decentralized application. A decentralized application (DApp) may also include a web or mobile interface, a wallet connection, offchain databases, file storage and data services.

When a user clicks "swap" on a web page, the interface presents the assets and parameters, the wallet lets the user check the request and sign it, the smart contract applies the onchain rules, and nodes verify the transaction. An error in any of these layers can affect the final outcome.

A contract deployed on a blockchain therefore does not make the whole application decentralized. A frontend domain can be taken down, a data service can return wrong information, and an administrator may retain upgrade or pause rights. Assessing an application means looking at its individual components and at who controls them.

Can a contract be modified or upgraded

Some blockchains keep deployed contract code unchanged, but that does not mean application logic can never be upgraded. Developers can deploy a new contract and migrate users, or use a proxy structure in which a fixed entry point forwards calls to a replaceable logic contract.

Upgradeability can be used to fix defects or add functionality. It also means certain accounts, multi-signature arrangements or governance processes may have the power to change how the program behaves. Whether an upgrade right exists, who can use it, whether there is a waiting period, and whether users can exit all require checking the current contract structure and permission settings.

Even where the code itself cannot be modified, an administrator may still change outcomes through parameters, allowlists, a pause switch or an external data source. Conversely, the absence of upgrade permissions does not make a contract less risky: a defect that cannot be modified may persist for a long time.

Common uses

Smart contracts can combine onchain assets and data under a consistent set of rules. Common uses include:

• recording token issuance, balances, transfers and approvals under uniform rules;
• exchanging assets according to quantity and pricing rules written into the program;
• managing collateral, borrowing and repayment, including disposal when conditions are no longer met;
• recording identifiers for digital items and who holds them;
• managing assets under multiple signatures or role-based permissions;
• applying parameter changes based on the result of an onchain vote.

These are categories of program, not an indication that any particular contract is sound, reasonable or suitable for anyone. Programs of the same type may use entirely different permissions, data sources and upgrade methods.

Limitations and risks

Writing rules as executable code also brings coding errors and permission design onchain. Common limitations include:

• Code defects: mistakes in conditions, calculations or permission checks can cause assets or data to be handled incorrectly.
• Administrative permissions: administrators, upgrade accounts or multi-signature participants may pause or change the program.
• External data: when an oracle supplies wrong, delayed or manipulated data, a contract may execute normally on faulty input.
• Composition dependencies: when one contract calls others, failures, upgrades or changes in available assets upstream can propagate downstream.
• Transaction ordering: pending transactions may be seen first by other participants in the network, who can submit related operations ahead of them and change the conditions the original transaction finally meets.
• Interfaces and signatures: malicious pages, wrong addresses or unclear approval requests can lead users to sign an operation they did not intend.
• Execution cost: complex computation and onchain storage can require higher fees; a transaction may fail when fees are insufficient or conditions are not met.

Public code is also not the same as understandable code. What executes on a blockchain may be compiled bytecode — the low-level instructions the execution environment reads. Even when a project publishes source code that is easier for people to read, an ordinary reader will struggle to confirm that it matches the onchain program, that it has been adequately tested, or whether a proxy currently points somewhere else.

A security audit can surface some problems, but it cannot prove that a contract has no defects, and it does not remove the risks introduced by administrators, external data, market conditions or user signatures. Assessing a specific program means looking past an "audited" label.

FAQ

Do smart contracts run automatically?

They execute according to their code, but usually still need a transaction, another contract or a protocol message to trigger them. Deploying a contract does not mean it will monitor the real world and initiate every operation by itself.

Are all smart contracts public?

Not necessarily. On public blockchains, executing code and transaction data can usually be read by nodes, but source code is not always published or verified. Permissioned networks may additionally restrict which members can view data and call programs.

Is a contract impossible to change once deployed?

Not necessarily. The original contract code may stay unchanged, but an application can migrate to a new contract, or replace the logic through a proxy and administrative permissions. This requires checking the specific upgrade structure rather than relying on claims of immutability.

Can a smart contract read data from a website directly?

Generally it cannot treat ordinary web content as trusted onchain input. It needs an oracle, an authorized participant or another mechanism to submit the data, and those data sources create additional dependencies.

Does successful execution mean the operation was sound?

No. Successful execution only means the transaction satisfied the current code and network rules. It does not prove that the code matches the user's intent, that external data was correct, that permissions were reasonably configured, or that the program has no economic or security defects.

Related concepts

Continue with blockchain, block, gas fee and blockchain node, or return to the Crypto Glossary.

Sources

• NISTIR 8202: Blockchain Technology Overview — general definition of smart contracts, code and state, and node execution requirements.
• Ethereum.org: Introduction to smart contracts — deployment, calls, state, composability and offchain data limits for Ethereum contracts.
• Ethereum.org: Interacting with smart contracts — the difference between reading state and submitting state changes.
• Ethereum.org: Upgrading smart contracts — immutable code compared with proxy upgrade structures.
• Hyperledger Fabric: Smart contracts and chaincode — chaincode, endorsement, validation and state update flow in a permissioned network.