Smart contracts and their limits

Programs whose results become ledger state

A smart contract is code deployed within a blockchain environment that executes according to that environment's rules. Despite the name, a smart contract is not necessarily a legally binding contract. It may simply implement an automated instruction such as “record a balance change when the required conditions are satisfied.” Its outputs can update balances, emit records, or call other applications. The blockchain supplies a replicated environment in which participating nodes can check whether execution followed agreed rules.

A useful starting example is a ticket registry. A smart contract may record that ticket identifier 417 belongs to a particular blockchain account. On receiving an authorized transfer request, it checks ownership and any restrictions before updating that record. The code does not know by itself whether the underlying event will happen, whether the holder is a particular real-world person, or whether local consumer law permits a restriction. Those questions belong to other systems and legal arrangements. Smart contracts make specified rules executable; they do not make every relevant real-world fact available.

Transactions, state, and deterministic execution

A transaction is a submitted instruction that requests a blockchain state change. State is the currently recorded information, such as balances, account permissions, or variables stored by a contract. Deterministic execution means that nodes applying the same valid instructions to the same prior state should obtain the same result. This is why a typical contract cannot simply open an arbitrary website and use the current page as trusted input. Different nodes could see different information or encounter different failures.

Networks differ in their execution models. Some support general-purpose programmable contracts; others provide intentionally restricted scripts. Even when two networks offer similar capabilities, they may use different virtual machines, fees, account structures, and transaction semantics. This lesson explains the shared logic rather than requiring students to program a particular chain.

Automation is conditional, not magical

A contract may contain conditions, permissions, and events. A condition evaluates facts visible to its environment, such as whether an account holds enough tokens. A permission specifies which actor can invoke a function. An event is a structured record emitted to help applications observe what happened. Not every event guarantees a corresponding movement of assets, and not every user interface accurately interprets the underlying transaction. Reviewers should inspect successful state changes rather than treating a displayed notification as decisive evidence.

Contracts also consume execution resources. Many networks measure computational work and charge transaction fees, sometimes called gas. If a contract requires excessive computation or the transaction does not provide sufficient resources, the operation may fail. Fee requirements help discourage unbounded computation. They do not guarantee that all contracts are economical to use or that a code path is free of errors. Complexity increases the need for testing and review.

Oracles connect the chain to external facts

An oracle is a mechanism that provides a contract with information originating outside its blockchain. Examples might include an official reference rate, a delivery confirmation, or a verified eligibility record. An oracle does not eliminate trust; it relocates it to information providers, data-validation processes, and delivery channels. Bad, late, manipulated, or unavailable data can lead a contract to behave exactly as written while producing a commercially wrong result. The Ethereum documentation on Oracles describes this separation between on-chain code and external information.

For public-sector use, an oracle feeding administrative records raises additional concerns: authority to publish data, privacy, correction procedures, and auditability. Writing personal information permanently to a widely replicated ledger may be inappropriate. Systems can often store only a limited proof or reference on-chain while retaining sensitive records in managed databases. The proper design depends on retention law, accessibility, and the evidentiary purpose of the system.

Four limits every decision-maker should recognize

First, code risk remains. A programming defect, misunderstood standard, or unsafe interaction between applications can cause unintended results. Published source code helps review but does not prove correctness. Second, governance risk remains. Some contracts have administrators who can pause functions or upgrade code. An immutable-looking interface may hide changeable dependencies. Third, data risk remains when the contract relies on oracles, data feeds, or document repositories. Fourth, legal enforceability remains separate: blockchain execution may happen even when a dispute exists over authority, consent, or ownership.

A user should distinguish immutability of past ledger records from immutability of application behavior. A historical transaction may remain visible even if a proxy contract points to new implementation code later. A system may also include legitimate recovery or emergency controls, subject to their own risks. The binary description “fully decentralized versus centralized” usually conceals more useful questions: who controls updates, whose signatures are required, what can be frozen, and who can resolve disputes?

Testing a claim of automatic enforcement

Imagine a contract advertised as automatically releasing payment when equipment reaches a government warehouse. Inspectors should ask how arrival is measured, who certifies it, what happens when a sensor fails, and how corrections are entered. If the system accepts an authorized employee's confirmation as the trigger, the contract enforces the presence of that confirmation—not the physical arrival itself. This difference is crucial when determining whether records provide proof of a fact, proof of a declaration, or both.

Under the FATF's 2021 virtual-assets guidance, regulatory analysis likewise depends on function and control, including whether persons operate or control covered services. A self-described “autonomous” application should not be assumed exempt from all legal duties. National and regional laws may also apply depending on the activity; it is not correct to assume that simply deploying code answers the regulatory question.

A practical review sequence

For a non-programmer, the simplest review starts by identifying the intended function, then mapping inputs, authority, execution, and outputs. Next, examine whether any actor can change the rules. Finally, determine which facts and rights are established outside the blockchain. A legal opinion, security audit, or accounting review may be necessary depending on the stakes. This is not a failure of smart contracts: all technology operates within institutions and policies. Their useful contribution is consistent execution of clearly specified, verifiable rules when the assumptions hold.

A note on evidence and accountability

The technical record of a contract call can answer “which account submitted this instruction?” and “what did the software record?” It usually cannot answer “who was authorized under organizational policy?” without reference to identity and approval records. Logs, deployment history, contract versions, and access-control inventories should therefore be retained together. For public procurement or regulated operations, automation may strengthen consistency only if someone remains accountable for incorrect inputs, exceptional outcomes, and rule changes.

Standards and legal references

The Ethereum documentation, Introduction to Smart Contracts and Oracles, describes execution and off-chain dependencies. FATF's Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers (October 2021) provides relevant activity-based considerations.

Exam focus: Explain what a smart contract executes, distinguish deterministic on-chain facts from external facts supplied by oracles, and recognize that technical execution does not by itself settle legal enforceability.