What a smart contract actually is

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:

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: 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 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, 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.