Smart Contract Fundamentals

1.1 What is a Smart Contract?

A smart contract is a self-executing program stored on a blockchain that automatically enforces the terms of an agreement when predetermined conditions are met. Unlike traditional contracts, smart contracts eliminate the need for intermediaries and execute deterministically based on code.

Historical Context: Nick Szabo's Vision

The term "smart contract" was coined by cryptographer Nick Szabo in 1994, predating blockchain technology by over a decade. Szabo envisioned embedding contractual clauses into hardware and software to make breach of contract expensive.

"A smart contract is a set of promises, specified in digital form, including protocols within which the parties perform on these promises." Nick Szabo, "Smart Contracts: Building Blocks for Digital Markets" (1996)

Key Characteristics

• Self-Executing: Automatically performs actions when conditions are met without human intervention
• Deterministic: Same inputs always produce the same outputs across all nodes
• Immutable: Once deployed, code cannot be changed (with limited exceptions)
• Transparent: Code is publicly visible and verifiable on-chain
• Trustless: Parties don't need to trust each other, only the code
• Atomic: Transactions either complete fully or revert entirely

Smart Contract Architecture

1.2 How Smart Contracts Work

The Ethereum Virtual Machine (EVM)

Most smart contracts run on the Ethereum Virtual Machine (EVM), a sandboxed runtime environment that executes bytecode. The EVM is:

• Turing-Complete: Can perform any computation given sufficient resources
• Stack-Based: Uses a last-in-first-out stack for operations
• Deterministic: Same bytecode produces identical results everywhere
• Isolated: Contracts cannot directly access external systems

Contract Lifecycle

1. Development: Code written in Solidity (or Vyper, etc.)
2. Compilation: Source code compiled to EVM bytecode
3. Deployment: Bytecode sent to blockchain via transaction
4. Initialization: Constructor function executes once
5. Interaction: Users call contract functions via transactions
6. Execution: EVM processes bytecode, updates state
7. Finality: State changes recorded permanently

Gas: The Execution Cost Model

1.3 The Oracle Problem

Smart contracts are deterministic and isolated - they cannot access external data. Oracles bridge this gap, but introduce trust assumptions that can undermine the trustless nature of blockchain systems.

Why Oracles Are Necessary

Blockchains are intentionally isolated from the outside world to maintain consensus. All nodes must agree on state, which requires deterministic inputs. External data sources (APIs, websites, sensors) are non-deterministic and could return different values to different nodes.

Types of Oracles

Oracle Attack Vectors

• Data Source Manipulation: Compromising the original data source
• Flash Loan Attacks: Manipulating spot prices temporarily
• Front-Running: Seeing oracle updates before they're processed
• Stale Data: Using outdated prices during high volatility
• Centralization Risk: Single point of failure in centralized oracles

1.4 Legal Enforceability

The legal status of smart contracts remains unsettled across jurisdictions. While code can automate execution, it cannot replace legal frameworks governing contract formation, interpretation, and remedies.

Contract Formation Requirements

Traditional contract law requires: (1) offer, (2) acceptance, (3) consideration, (4) capacity, (5) legality, and (6) intent. Smart contracts must still satisfy these elements:

Jurisdictional Recognition

• United States: No federal law; some states (Arizona, Tennessee, Wyoming) recognize smart contracts
• European Union: eIDAS Regulation provides framework for electronic signatures; smart contracts not specifically addressed
• United Kingdom: Law Commission concluded smart contracts can form binding contracts under existing law (2021)
• Singapore: Electronic Transactions Act recognizes electronic contracts; smart contracts generally valid
• India: IT Act 2000 recognizes electronic contracts; smart contracts may qualify but untested

Challenges to Enforceability

1. Interpretation: Courts interpret intent, but code executes literally. What happens when code diverges from parties' expectations?
2. Modification: Traditional contracts can be modified by agreement. Immutable smart contracts cannot be changed.
3. Remedies: Traditional remedies (specific performance, damages) may be impossible if funds are already transferred or locked.
4. Jurisdiction: Which court has authority over a borderless, decentralized contract?
5. Identity: Pseudonymous parties may be impossible to sue or serve process.

1.5 Ricardian Contracts: Bridging Code and Law

Ricardian contracts, developed by Ian Grigg in 1996, offer a solution to the code-law divide by creating a single document that serves both legal and technical purposes.

Structure of a Ricardian Contract

• Legal Prose: Natural language terms that courts can interpret
• Machine-Readable Tags: Structured data (XML/JSON) for automated parsing
• Cryptographic Hash: Links the document to on-chain code
• Digital Signatures: Proves party agreement to specific terms

// Example: Ricardian Contract Reference in Solidity
contract TokenSale {
    // IPFS hash of Ricardian contract document
    string public constant TERMS_HASH =
        "QmXyz...abc123";

    mapping(address => bool) public agreedToTerms;

    function agreeToTerms(bytes32 _termsHash) external {
        require(
            keccak256(abi.encodePacked(TERMS_HASH)) == _termsHash,
            "Invalid terms hash"
        );
        agreedToTerms[msg.sender] = true;
    }
}