What a smart contract is and isn’t

The name oversells it; the definition is modest

Few terms in this field are as misleading as “smart contract”. It suggests something intelligent and something legally binding. It is neither. Ethereum’s documentation gives the actual definition: “A ‘smart contract’ is simply a program that runs on the Ethereum blockchain. It’s a collection of code (its functions) and data (its state) that resides at a specific address.” Strip away the connotations and you are left with an ordinary idea: a program, stored on the ledger, that does exactly what its code says.

The classic illustration is a vending machine. You put in the right coins and make a selection, and the machine dispenses the item automatically, with no clerk to negotiate with. The rules are fixed in advance and applied identically to everyone. A smart contract works the same way: given the right inputs, as Ethereum’s documentation notes, “a certain output is guaranteed.”

Code and data living at an address

Recall that ordinary accounts are controlled by a private key. A contract account is different: it is controlled by its own code. When a developer deploys a contract, its compiled code is stored on the blockchain at a new address, along with any initial data. From then on, that address holds two things: the contract’s functions (what it can do) and its state (the data it currently holds, such as balances or settings).

A contract does nothing on its own. It sits inert until a transaction calls one of its functions. Only then does the network execute the relevant code, which may read and update the contract’s state and even call other contracts. This is a crucial and often missed point: contracts are reactive, not autonomous. There is no background process; every action a contract takes is triggered by a transaction that someone submitted and paid gas for.

Public by default

Because a contract lives on a public blockchain, its deployed code and its state are visible to everyone. Ethereum’s documentation describes contracts as “public on Ethereum,” comparable to “open APIs,” meaning their functions can be inspected and called by anyone. This transparency is a genuine strength for security review: in principle, anyone can read exactly what a contract will do before interacting with it.

It also carries an obligation. “Public” means there are no private variables in the everyday sense; data stored in a contract can be read by anyone, even if a function is not designed to expose it. Sensitive information should never be placed in contract storage under the assumption it is hidden.

Immutable by default

Perhaps the most consequential property is permanence. Ethereum’s documentation states flatly that “smart contracts cannot be deleted by default, and interactions with them are irreversible.” Once deployed, the code at that address is fixed. There is no built-in edit button.

This cuts both ways. Immutability is what lets people trust a contract without trusting its author: the rules cannot be quietly rewritten after you have committed funds. But it also means that a bug deployed to the network is permanent. If a contract contains a flaw, it cannot simply be patched; developers must either deploy an entirely new contract or design in advance for upgradeability through more elaborate patterns. The lesson for users is direct: a smart contract’s behaviour is only as good as the code that was deployed, and that code will not improve on its own.

Deterministic, and blind to the outside world

Smart contracts are deterministic: given the same inputs and the same state, they always produce the same result. This is a requirement, not a nicety, because every node in the network must independently re-execute a contract and arrive at exactly the same outcome, otherwise the network could not agree on the new state.

Determinism has a striking consequence: a contract cannot, by itself, know anything about the world outside the blockchain. It cannot check the weather, a stock’s value, or the result of a sporting event, because those are not part of its deterministic inputs. Ethereum’s documentation is explicit: “Smart contracts alone cannot get information about ‘real-world’ events because they can’t retrieve data from offchain sources.” The bridge for this is an oracle, a service that, as the documentation puts it, ingests “offchain data and make[s] it available to smart contracts.” Oracles are themselves a security consideration, because a contract is only as trustworthy as the data fed into it.

What a smart contract is not

With the definition established, the myths dissolve one by one.

It is not a legal contract. Despite the name, a smart contract is a program, not an agreement recognised by a court. It may implement the terms of a deal, but it carries no inherent legal force and cannot interpret intent, only execute code.

It is not “smart”. There is no reasoning or judgement involved. A contract executes fixed instructions literally. It will faithfully carry out a mistake in its own code, and it cannot tell that an outcome is unfair or unintended.

It is not automatically safe or correct. The network guarantees that a contract runs exactly as written; it guarantees nothing about whether what was written is what the author meant, or whether it is free of exploitable flaws. Many of the largest losses in this field trace to contract bugs faithfully executed by a network working exactly as designed.

It is not private. As above, its code and data are public.

It is not autonomous. It cannot start itself. Every execution is initiated by a transaction, and even a contract meant to run “on a schedule” relies on some external party sending a transaction to poke it.

How to think about interacting with one

These properties translate into practical caution. Interacting with a smart contract means authorising code you may not have read to act according to rules that cannot later be changed. That is powerful when the contract is well written and audited, and unforgiving when it is not. Because interactions are irreversible, there is no undo; because the code is public, it can, in principle, be reviewed; and because a contract can only ever do what its code allows, understanding, or trusting a review of, that code is the real basis for interacting safely. The technology removes the need to trust a counterparty’s promises. It replaces that with the need to trust the code, which is a different problem, not the absence of one.

Approvals: a permission you grant, and can revoke

One interaction pattern deserves particular attention because it is where many users are caught out. To let a contract move tokens on your behalf, for example to trade them, you often first send a separate transaction that grants the contract an allowance: permission to spend up to some amount of a given token from your account. This is a deliberate design that keeps token transfers under your control, but it has a sharp edge. An allowance persists after the action that prompted it, and some interfaces request permission to spend an unlimited amount for convenience. If the contract you approved is malicious or later compromised, a standing allowance can be used to drain the approved token.

The practical points follow from the mechanism rather than from fear. An approval is a real transaction that changes on-chain state, so it is visible on a block explorer and can be reviewed before signing. Approvals can also be revoked or reduced with another transaction, and it is sound practice to grant only the amount actually needed and to periodically review and remove allowances you no longer use. Understanding that an approval is a lasting grant of spending permission, not a one-off click, reframes it as exactly what it is: a decision about how much of your account a piece of code is allowed to touch.

Sources

• Ethereum.org — Introduction to smart contracts
• Ethereum.org — Anatomy of smart contracts
• Ethereum.org — Oracles
• Ethereum.org — Ethereum accounts