# What a smart contract actually is

> A smart contract is a program that lives on a blockchain and runs identically for everyone, with results nobody can alter afterwards. That is genuinely useful and genuinely dangerous — because a bug is permanent, and the code cannot know anything about the world outside the chain.

Source: https://thenftacademy.com/learn/smart-contracts-explained
Last updated: 2026-09-11
Site: The NFT Academy (https://thenftacademy.com)

---

A smart contract is a program stored on a blockchain. When someone sends it a transaction, it
runs, and every node in the network runs it and agrees on the result.

Two properties make this different from ordinary software:

- **Nobody can stop it or change what it does.** Once deployed, the code is what it is.
- **Everyone gets the same answer.** There is no server that might behave differently for different users.

The name is unfortunate. A smart contract is not smart and is not a contract. It is a program
with unusual guarantees, and most of the confusion in this subject comes from taking the name
literally.

### What does a smart contract look like?
Say you want to sell a digital item for 0.1 ETH. A contract could say, in effect:

> If someone sends 0.1 ETH, transfer item #47 to their address. Otherwise, reject.

Once deployed:

- The seller cannot refuse a valid buyer
- The buyer cannot obtain the item without paying
- No intermediary holds the funds mid-transaction
- The rules are public and verifiable before anyone commits

That is the useful core. No trusted third party is required, because the rules execute
themselves.

### What does an NFT contract actually store?
An ERC-721 contract is not exotic. Underneath, it maintains a handful of mappings:

| Data | What it records |
| --- | --- |
| `ownerOf` | Which address controls each token ID |
| `balanceOf` | How many tokens each address holds |
| `tokenURI` | Where to find each token's metadata |
| `getApproved` | Who has permission to move a specific token |
| `isApprovedForAll` | Who has permission over an address's entire collection |

And a handful of functions: `transferFrom`, `approve`, `setApprovalForAll`, usually a `mint`.

That is essentially it. An NFT is a row in the first mapping. The art, the community, the
prices — all of that is built on top by other software.

That last mapping, `isApprovedForAll`, is worth remembering. It is the mechanism behind most
[NFT theft](/learn/nft-scams-and-red-flags): the victim signs a `setApprovalForAll` call,
granting an attacker permission over their whole collection. No exploit is involved. The
contract does exactly what it was asked.

### Why is immutability both a feature and a problem?
Immutability is the headline feature and the main hazard.

**In your favour:** rules cannot be changed after you commit. A project cannot raise the
royalty after you buy, or mint extra supply, or disable transfers — if the contract does not
allow it, it cannot happen, regardless of who wants it to.

**Against you:** bugs are permanent. Ordinary software gets patched. A deployed contract does
not. A flaw discovered after deployment, in code holding real money, is a flaw that stays
there while everyone watches.

This is why contract development is genuinely different from ordinary programming. You cannot
iterate towards correctness. The code must be right before it is deployed, because after is
too late — and the history of this space is substantially a history of that lesson being
learned expensively.

### Can a smart contract be upgraded?
Because permanent bugs are intolerable, many projects use **proxy patterns**: a small
permanent contract holds the state and forwards calls to a logic contract that can be swapped.

This solves the bug problem and reintroduces the trust problem. Whoever controls the upgrade
key can change what the contract does. The guarantee is now "this behaves as described, unless
the key holder decides otherwise" — which is a materially weaker claim than immutability, and
close to the trust model of ordinary software.

Neither choice is wrong. But when a project says "trustless" and the contract is upgradeable,
those two statements are in tension, and it is worth noticing which one is load-bearing.

### Why can a contract not know what happens off-chain?
A structural limitation that explains a lot of failed ideas: **a contract can only see the
blockchain.** It cannot read a website, call an API, check the weather, or verify that a
physical item was delivered.

Anything from outside must be *put in* by a transaction, which means trusting whoever put it
in. **Oracles** are services that do this — and they are the point at which a decentralised
system acquires a centralised dependency. A contract that pays out based on a price feed is
exactly as trustworthy as that feed.

This is why "smart contracts will replace legal contracts" was never plausible. A legal
contract covers things like reasonable effort, good faith and unforeseen circumstances. A
program can only act on data it has been handed.

### Why is NFT artwork not stored on-chain?
Every operation costs gas, and the cost is not uniform. Storage is dramatically more expensive
than computation.

This single fact explains one of the most-asked questions about NFTs: storing a
high-resolution image on-chain would cost far more than almost any NFT has sold for. So
contracts store a *pointer* — which is why [where that pointer leads](/learn/what-are-nfts)
determines whether the artwork still exists in a decade.

A small number of projects do store artwork fully on-chain, usually generative work producible
from a compact algorithm. They are a minority precisely because of this cost structure.

### How do you read a contract before trusting it?
You do not need to be a developer to do basic due diligence.

1. **Is it verified?** On Etherscan, a verified contract shows readable source matching the deployed bytecode. Unverified means you are trusting a promise about code nobody can see. For anything holding value, this alone should be disqualifying.
2. **Does it use standard implementations?** Contracts extending OpenZeppelin's ERC-721 inherit code that has been reviewed by a very large number of people. Bespoke reimplementations of standard functionality are where novel bugs live.
3. **Is there an audit?** From a firm with a reputation, covering the deployed version. An audit reduces risk; it does not eliminate it, and audited contracts have been exploited.
4. **What can the owner do?** Look for functions restricted to an admin address. Can they mint more? Change the metadata? Pause transfers? Withdraw funds? These may be legitimate — but they are the trust assumptions, and you should know what they are.
5. **Is it upgradeable?** If so, the guarantees are only as strong as the custody of the upgrade key.

### How do you learn to write smart contracts?
The path is well established: JavaScript first if you need it, then Ethereum fundamentals,
then Solidity, then the security patterns — reentrancy, access control, integer behaviour —
which are the part that actually matters.

Before anything you write holds value, work through Ethernaut and Damn Vulnerable DeFi. They
teach by having you break contracts, which builds instincts that no lecture does.

[Development courses are reviewed here](/courses/nft-development-solidity), with an honest
note on how much each one's tooling has dated — which in this corner of the subject matters
more than the star rating.

## Frequently asked questions

### Is a smart contract a legal contract?

No. It is a program. The name is a historical accident and a persistently misleading one. It has no legal force in itself, cannot be interpreted by a court in the way a contract is, and executes exactly what it says regardless of what anyone intended.

### Can a smart contract be changed after deployment?

Not directly — deployed bytecode is immutable. Many projects use proxy patterns that allow the logic to be swapped, which reintroduces exactly the trust assumption immutability was supposed to remove. If a contract is upgradeable, whoever controls the upgrade key controls the contract.

### What language are smart contracts written in?

Solidity dominates on Ethereum and every EVM-compatible chain. Vyper is a smaller Python-influenced alternative. Solana uses Rust. Solidity is where the tooling, documentation and teaching material are deepest.

### What does it cost to run a smart contract?

Every operation consumes gas, paid by whoever sends the transaction. Storage is by far the most expensive operation, which is why NFT artwork is almost never stored on-chain — it would cost more than the artwork is worth.

## Sources

- [Ethereum Foundation — Introduction to smart contracts](https://ethereum.org/en/developers/docs/smart-contracts/)