An application asks you to deposit tokens. Who applies the rules after you click? Often, a smart contract: a program deployed on a blockchain whose execution can change the ledger. The term means neither artificial intelligence nor, by itself, a legal contract.
You can already distinguish tokens and NFTs. Now we can examine how a program manages them.
A rule written in advance
Imagine a demonstration fundraising campaign. Its program allows contributions to be returned if a target is not reached before a deadline. When someone calls the relevant function, it checks the conditions and applies the rule.
The result depends on the deployed code, not the website’s slogan. A program does not understand that a user made a mistake: it processes inputs according to its instructions. Ethereum’s smart contract introduction explains their operation on that network.
The application and contract are different layers
The website supplies buttons, explanations and screens. The contract contains some of the rules executed on the blockchain. Other features may still depend on conventional servers.
Our fictional fundraising website could advertise “automatic refunds” while the program requires each contributor to claim a refund through a transaction. “Automatic” would describe how the rule is applied, not necessarily an action that starts without intervention.
Ask what triggers an action, who can trigger it and what happens if the website disappears.
A program cannot directly see the real world
Suppose a refund depends on delivery of a parcel. The program cannot inspect a letterbox. It needs external information supplied by an oracle or another participant.
Incorrect information can make correctly executed code produce a result that does not fit reality. Oracles connect programs with external data while introducing assumptions about their sources and operation.
Can the rules change?
Some systems are designed to evolve. An intermediary contract may direct calls to replaceable logic. Other systems include pause powers or adjustable parameters.
Identify who holds these powers: one person, several signers, a vote or another procedure. The upgrade documentation explains why “on a blockchain” does not always mean “impossible to change”.
A technical audit searches for weaknesses within a defined scope. It guarantees neither the absence of future flaws nor a sound business model. A useful report identifies the version examined and unresolved findings.
Read a promise through three questions
Return to the fundraising example. What condition allows a refund? Who supplies the necessary information? Who can change or suspend the rules?
These questions are easier to start with than hundreds of lines of code. They help distinguish documentation that explains a mechanism from a page that simply offers reassurance.
Check your understanding
A smart contract promises compensation if a parcel is late. Is public code enough to establish whether it arrived? No. The reliability of delivery information remains a separate question.
Remember: code automates rules. It does not turn external information into truth or remove every responsible party.