A smart contract is a computer program or a transaction protocol that is intended to automatically execute, control or document events and actions according to the terms of a contract or an agreement. The objectives of smart contracts are the reduction of need for trusted intermediators, arbitration costs, and fraud losses, as well as the reduction of malicious and accidental exceptions.

Smart contracts are commonly associated with cryptocurrencies, and the smart contracts introduced by Ethereum are generally considered a fundamental building block for decentralized finance (DeFi) and non-fungible token (NFT) applications.

The original Ethereum white paper by Vitalik Buterin in 2014 describes the Bitcoin protocol as a weak version of the smart contract concept as originally defined by Nick Szabo, and proposed a stronger version based on the Solidity language, which is Turing complete. Since then, various cryptocurrencies have supported programming languages which allow for more advanced smart contracts between untrusted parties.

A smart contract should not be confused with a smart legal contract, which is a traditional, natural-language, legally binding agreement that has selected terms expressed and implemented in machine-readable code.

By 1996, Nick Szabo was using the term "smart contract" to refer to contracts which would be enforced by physical property (such as hardware or software) instead of by law. Szabo described vending machines as an example of this concept. In 1998, the term was used to describe objects in rights management service layer of the system The Stanford Infobus, which was a part of Stanford Digital Library Project.

A smart contract does not typically constitute a valid binding agreement at law. Proposals exist to regulate smart contracts.

Smart contracts are not legal agreements, but instead transactions which are executed automatically by a computer program or a transaction protocol, such as technological means for the automation of payment obligations such as by transferring cryptocurrencies or other tokens. Some scholars have argued that the imperative or declarative nature of programming languages would impact the legal validity of smart contracts.

In some jurisdictions, legal scholars have examined how the rigidity of smart contracts interacts with traditional doctrines such as contractual unforeseeability. For instance, Colombian legal scholarship has proposed adapting the theory of supervening onerousness (teoría de la imprevisión) to account for the high economic and systemic costs of reversing smart contract effects through judicial intervention, emphasizing the need to internalize these costs and develop new procedural mechanisms for digital environments.

Similar to a transfer of value on a blockchain, deployment of a smart contract on a blockchain occurs by sending a transaction from a wallet for the blockchain. The transaction includes the compiled code for the smart contract as well as a special receiver address. That transaction must then be included in a block that is added to the blockchain, at which point the smart contract's code will execute to establish the initial state of the smart contract. Byzantine fault-tolerant algorithms secure the smart contract in a decentralized way from attempts to tamper with it.

Once a smart contract is deployed, it cannot be updated. Smart contracts on a blockchain can store arbitrary state and execute arbitrary computations. End clients interact with a smart contract through transactions. Such transactions with a smart contract can invoke other smart contracts. These transactions might result in changing the state and sending coins from one smart contract to another or from one account to another.

The most popular blockchain for running smart contracts is Ethereum. On Ethereum, smart contracts are typically written in a Turing-complete programming language called Solidity, and compiled into low-level bytecode to be executed by the Ethereum Virtual Machine. Due to the halting problem and other security problems, Turing-completeness is considered to be a risk and is deliberately avoided by languages like Vyper. Some of the other smart contract programming languages missing Turing-completeness are Simplicity, Scilla, Ivy and Bitcoin Script.

Some newer platforms have explored "asset-oriented" domain-specific languages (such as Scrypto) that treat digital assets as native data types within the language environment to enforce finiteness and safety rules at the compiler level. However, measurements in 2020 using regular expressions showed that only 35.3% of 53,757 Ethereum smart contracts at that time included recursions and loops — constructs connected to the halting problem.

Several languages are designed to enable formal verification: Bamboo, IELE, Simplicity, Michelson (can be verified with Rocq), Liquidity (compiles to Michelson), Scilla, DAML and Pact.

In 1998, Szabo proposed that smart contract infrastructure can be implemented by replicated asset registries and contract execution using cryptographic hash chains and Byzantine fault-tolerant replication. Askemos implemented this approach in 2002 using Scheme (later adding SQLite) as the contract script language.

One proposal for using Bitcoin for replicated asset registration and contract execution is called "colored coins". Replicated titles for potentially arbitrary forms of property, along with replicated contract execution, are implemented in different projects.

As of 2015^([update]), UBS was experimenting with "smart bonds" that use the bitcoin blockchain in which payment streams could hypothetically be fully automated, creating a self-paying instrument.