Smart Contracts, Applications and Outside Data

A smart contract is a program that applies rules when the network executes the relevant action. It can make an operation predictable under its code while still applying unfair terms, using bad input or containing a bug. This lesson explains code, interfaces and outside data, then shows why automatic execution is not the same as a safe agreement.

Education only. Crypto assets can lose substantial value or become worthless. No lesson requires buying an asset, depositing money or sharing real passwords, private keys or recovery words.

A vending machine for programmed rules

In the 1990s, the computer scientist and legal scholar Nick Szabo, whom you met in Level 1 as the designer of bit gold, coined the term "smart contract" (his first short piece on it appeared in 1994). His favourite illustration was a vending machine. You choose a drink, put in coins, the machine checks you paid enough, and it releases the drink and any change. Nobody behind a counter decides whether to serve you; the rules are built in and run the same way for everyone.

A smart contract is the same idea, written as code and stored on a blockchain. When a transaction reaches it, the code checks its conditions and, if they are met, carries out the result automatically. Because the code is public, anyone can inspect the rules before using it.

The analogy breaks down in three places. First, a broken vending machine can be opened and fixed. A smart contract usually cannot be changed once deployed unless its builders designed a way to upgrade it, a trade-off you'll examine in Level 6. Second, if the code contains a mistake, the "machine" follows the mistake faithfully. Third, a smart contract cannot see the outside world on its own; it only knows what is on the blockchain unless someone feeds it outside data, also a Level 6 topic.

So a smart contract needs something to pay with and something to run on. The payment part brings us to ether.

The program does not need to share a human's interpretation of fairness or intention. They may also remain dependent on administrators or outside data. Read what the program permits and who can change it rather than assuming the word smart implies judgment, intelligence or legal protection. Ethereum's virtual machine, or EVM, is the execution environment that applies its contract instructions under network rules.

The website and the contract state

An application's website helps users read information and prepare actions. The contracts maintain their own state, such as balances, permissions or pool parameters. An interface can display inaccurate information or prepare a different action from the one a user expects. Conversely, a website can be unavailable while a contract still exists on the network.

Identify the verified contract address, network and relevant version. Some applications also depend on hosted databases, front-end operators or specialised transaction services. A polished interface is not a code audit. A copied website can reuse the same graphics while pointing to another contract. When inspecting an action, connect the user-facing instruction to the exact contract call and its effect. Beginners can practise this using supplied records without connecting a funded wallet.

Code needs trustworthy outside facts

Participants need to reach consistent results from the same accepted inputs. A contract cannot simply visit any website during validation and choose whatever price it happens to show. External facts, such as a market price or weather result, must enter through an agreed mechanism. An oracle supplies data or another bridge between outside information and contract use.

The contract's result can be correct under the provided data while the data is wrong, delayed or manipulated. A lending contract using an unrealistic collateral price may allow an unsafe loan. Ask which data source is used, how often it updates, what happens when it is unavailable and whether extreme values are handled. Oracle quality and contract quality are separate dependencies. Neither can be ignored because the other has a reputable name.

Open diagram at original size ↗

Read diagram as text

The interface prepares a request; contract code applies rules; the network executes an accepted action.

An oracle can supply outside data. An administrator may be able to change rules. Those inputs and authorities affect the result.

Correct code execution can still act on bad data or unsuitable terms.

Administrators upgrades and emergency powers

Some contracts are immutable in relevant respects; others can be upgraded or governed through defined authorities. An administrator may pause operations, change parameters or redirect implementation through a proxy. These powers can support emergency response but also create control and abuse risks. Governance votes may be one part of the process rather than the only authority.

Read who holds the permissions, whether multiple approvals are required, whether there is a delay and what notice users receive. A multi-signature arrangement reduces reliance on one key only under its actual threshold and participant independence. It does not remove all collusion or compromise risk. Compare the current contract version with the version covered by any review, and track later changes that may alter the risk.

Code economic risk and The DAO

An exploit can arise from a programming error, unexpected interaction or a mechanism that is technically allowed but economically dangerous. A protocol may follow its code while failing because incentives, liquidity or collateral assumptions break. Automatic execution is therefore not a guarantee that the terms are fair, legally enforceable or appropriate for a beginner.

Use a dependency checklist: contracts, administrators, oracles, collateral, networks, interfaces and custody. Identify what can be paused or recovered and what cannot. Audits and bug-bounty programmes can improve review but do not certify the absence of every vulnerability. We return to audit scope in Level 10. For now, explain both the intended rule and at least one input or authority on which it relies.

Learn what went wrong with The DAO

In April 2016 a project called The DAO launched on Ethereum: an investor-directed fund run by smart contracts, where people sent ether, received DAO tokens and would vote on which projects to fund. According to the US Securities and Exchange Commission (SEC), its sale ran from 30 April to 28 May 2016 and raised about 12 million ETH, worth roughly US$150 million at the time.

On 17 June 2016, an attacker used a flaw in The DAO's code to move about 3.6 million ETH, roughly a third of what it had raised, into an account they controlled. Ethereum itself had not broken. It ran The DAO's code exactly as written; the code allowed something its authors never intended. This is the vending-machine warning made real: a machine with a fault pays out according to the fault.

The DAO also became a regulatory landmark: in July 2017 the SEC concluded that DAO tokens were securities under US law. That is one dated example from one country; rules differ and change, so check your own national regulator.

With a third of the fund in an attacker's control, the community faced a hard choice: accept the loss, or change the record.

See why the chain split in two

After weeks of debate, most of the community chose to act. In July 2016, a hard fork, a rule change not every node has to accept, moved the affected ether into a recovery contract so DAO token holders could withdraw it. You met chain splits in the keys and signing lesson in Level 1; Level 10 compares forks in depth.

Not everyone agreed. Some believed a blockchain record should never be rewritten to rescue one application. They kept running the original, unforked chain, which continued as Ethereum Classic (ETC): two networks with a shared history up to the fork and separate histories after it.

The lasting lesson is that "immutable" has a social side: if enough users and operators agree, they can choose new rules, and others can refuse. For you, the point is narrower: contract bugs can cost real money even when the blockchain works perfectly, and a rescue is rare, not something to count on.

Ethereum survived the split and kept growing. Its biggest technical change came six years later, when it stopped relying on miners altogether.

Try the following questions aloud or on paper before opening the worked answers. Compare your reasoning as well as your final answer.

References and further reading