Blockchain Basics Module

Smart Contracts & Execution Layer

How on-chain programs execute, mutate state, and compose with each other

Core path (recommended): What is a smart contract → Deployment → Execution layer → ABI → State mutation/atomicity → Logs/indexers → Composability

~70–110 minutes • Beginner → early intermediate

This is the required path to complete the module. All other articles are optional.

Start core path

What this module covers

Smart contracts are public programs with persistent state and callable interfaces.

This module covers how contracts are deployed and addressed, how execution is deterministic, how ABIs enable interaction, how calls mutate state atomically (commit or revert), and how logs/indexers make execution observable.

Hard stop: before protocol-specific languages, security audits, and advanced DeFi patterns.

Time

70–110 min (recommended path)

Level

Beginner → early intermediate

Prereqs

State & Data Models + Blocks & Transactions (helpful, not required)

This module is for

  • Anyone who wants a correct mental model of on-chain program execution
  • Developers integrating with contracts via ABI and RPC
  • Users trying to understand receipts, reverts, and event logs

This module is not

  • Protocol-specific languages and chain-specific toolchains
  • Security audits and exploit education
  • Advanced DeFi patterns and deep protocol design

Stage 0

Orientation: On-chain Programs

What makes a program “on-chain”?

See a smart contract as a public program with persistent state and a callable interface — not an “automatic agreement”.

Core

CORE • Step 1/7 • Beginner • 5–7 min • Concept

Smart Contract

On-chain programs with persistent state and public interfaces.

Supporting (intuition)

Optional intuition and mental models.

Coming soon

Code vs Deployment

Why deployed code becomes an addressable object with state, not a one-off script.

Coming soon

Programs vs Accounts (Intuition)

Intuition for contracts as account-like identities with code and storage.

Reference (how to observe the system)

Optional verification via explorers, clients, wallets, and documentation.

Coming soon

Where Contracts Appear in Explorers (Conceptual)

How explorers surface contract addresses, code, and verified interfaces.

You can move on when:

  • You can explain what makes a program “on-chain”.
  • You can distinguish code from deployment and addressability.
  • You can explain why contracts are not “just scripts”.

Stage 1

Deployment & Contract Identities

How do contracts come into existence and get addressed?

Treat a contract as a special account-like identity with code and an address.

Core

CORE • Step 2/7 • Coming soon

Contract Deployment Basics

How contracts are deployed, addressed, and made callable.

Coming soon

Contract Accounts vs EOAs

Why contracts and externally owned accounts behave differently.

Supporting (intuition)

Optional intuition and mental models.

Coming soon

Why Contracts Can’t “Sign” Transactions

Why contract control is code-defined, not key-defined.

Coming soon

Who Pays for Deployment and Execution

Why EOAs pay fees even when contracts do the work.

Reference (how to observe the system)

Optional verification via explorers, clients, wallets, and documentation.

Coming soon

Deployment Transactions in Explorers

What deployment looks like in explorer UIs (conceptual).

You can move on when:

  • You can explain deployment as creating an addressable contract identity.
  • You can explain why EOAs and contracts behave differently.
  • You can explain why contracts can’t sign transactions.

Stage 2

Execution Environment

Where and how does contract code actually run?

Treat the execution layer as a deterministic rule-application machine, not a server.

Core

CORE • Step 3/7 • Coming soon

Execution Layer

What the execution layer does and what it assumes from other layers.

Coming soon

Determinism and Why It Matters

Why the same inputs must always produce the same state changes.

Supporting (intuition)

Optional intuition and mental models.

Intermediate • 6–8 min • Mechanism

Gas Metering During Execution

Metering as limits and safety during execution (not fee market design).

Reference (how to observe the system)

Optional verification via explorers, clients, wallets, and documentation.

Coming soon

Execution Traces (Conceptual)

How traces help you observe what execution did (conceptual).

You can move on when:

  • You can describe what the execution layer does at a high level.
  • You can explain why determinism is required.
  • You can explain why execution is metered (limits and safety).

Stage 3

Contract Interfaces (ABI)

How do users, apps, and contracts know how to talk to a contract?

Treat ABI as an interface contract, not just a dev artifact.

Core

CORE • Step 4/7 • Coming soon

ABI Explained

How interfaces describe what contracts accept and return.

Coming soon

Why ABIs Matter for Wallets and dApps

How intent becomes encoded calls.

Supporting (intuition)

Optional intuition and mental models.

Coming soon

Encoding Calldata and Decoding Results

High-level encoding/decoding (no byte-level deep dive).

Reference (how to observe the system)

Optional verification via explorers, clients, wallets, and documentation.

Coming soon

ABI Usage in Wallets (Conceptual)

How wallets use ABIs to render human-readable interactions (conceptual).

You can move on when:

  • You can explain ABI as a description of callable functions and return types.
  • You can explain how wallets/dApps encode intent into calls.
  • You can explain why decoding matters for UX.

Stage 4

State Mutation & Atomicity

How do contract calls change state — safely or not at all?

Lock in: read → compute → write → commit or revert.

Core

Coming soon

Reads vs Writes: How Calls Mutate State

How execution reads current state and writes updates.

CORE • Step 5/7 • Coming soon

Reverts, Errors, and Atomicity

Why transactions fully apply or have no effect.

Supporting (intuition)

Optional intuition and mental models.

Coming soon

Storage vs Memory

Persistent vs temporary data during execution.

Reference (how to observe the system)

Optional verification via explorers, clients, wallets, and documentation.

Coming soon

Transaction Receipts and Status Flags

How success/revert is represented in receipts (conceptual).

You can move on when:

  • You can explain reads vs writes at a high level.
  • You can explain what a revert means for state changes.
  • You can explain why atomicity matters for UX and safety.

Stage 5

Events, Logs & Observability

How do apps know what happened during execution?

Understand that logs ≠ state, but logs make execution observable for apps.

Core

CORE • Step 6/7 • Coming soon

Events and Logs

How logs are emitted and why apps rely on them.

Coming soon

Indexers and Event-Driven Apps

How UIs and analytics reconstruct activity.

Supporting (intuition)

Optional intuition and mental models.

Coming soon

Reading Contract History: Receipts and Traces

How apps reconstruct what happened from execution artifacts.

Reference (how to observe the system)

Optional verification via explorers, clients, wallets, and documentation.

Coming soon

Event Logs in Explorers

How explorers display logs and topics (conceptual).

You can move on when:

  • You can explain why apps rely on logs/events.
  • You can explain what indexers do at a high level.
  • You can connect receipts/traces to observability.

Stage 6

Composability & Shared State

Why can contracts build on each other — and why is that risky?

Treat composability as a system property of shared state.

Core

CORE • Step 7/7 • Coming soon

Composability Basics

Why shared state enables contracts to call each other.

Supporting (intuition)

Optional intuition and mental models.

Coming soon

Reentrancy and Call Stack Intuition

Intuition for nested calls and shared state (no exploit tactics).

Coming soon

Permissioning and Access Control Basics

A simple model for roles, ownership, and permissions in contracts.

Reference (how to observe the system)

Optional verification via explorers, clients, wallets, and documentation.

Coming soon

Common Composability Failures (Conceptual)

Conceptual examples of failures driven by shared state and composition.

You can move on when:

  • You can explain why shared state enables contract-to-contract calls.
  • You can explain why composability creates new failure modes.
  • You can explain why permissions and access control matter.

Stage 7

Boundaries & Next Modules

What execution enables — and what it does not solve?

Close before languages/toolchains, audits, and advanced DeFi patterns; bridge into scaling and advanced security topics.

You now have the execution lens: deploy → call → execute deterministically → commit/revert → observe via logs → compose via shared state.

Hard stop (covered later)

  • Protocol-specific languages and toolchains
  • Security audits and exploit education
  • Advanced DeFi patterns

Leads naturally to

  • Fees & Incentives (cost of execution)
  • Scaling & Layer 2 (execution off-chain)
  • Security & Auditing (advanced)

Supporting (intuition)

Optional intuition and mental models.

Intermediate • 6–8 min • Bridge

State Models and Storage Layout

State structure and storage layout shape execution patterns and constraints.

Intermediate • 6–8 min • Bridge

Fee Markets and Gas Pricing

How pricing and congestion shape what can run and when.

Intermediate • 6–8 min • Bridge

Nodes, RPC, and Data Serving

How apps reach execution results through networking and RPC.

Next: Scaling & Layer 2

Completion checklist

If you can answer these, you have the module’s mental model.

  1. What makes a program “on-chain” compared to an off-chain service?
  2. How do contracts get deployed and addressed, and how do they differ from EOAs?
  3. What does the execution layer do, and why must it be deterministic?
  4. What is an ABI and how do wallets/dApps use it?
  5. How do calls mutate state and why do reverts enforce atomicity?
  6. Why are logs crucial for apps, and what do indexers do?
  7. Why does composability exist and what risks does it introduce?

FAQ

Related system guides

How execution changes stateComing soon

A system-level view of how calls and transactions become state updates.

Why composability changes system riskComing soon

How shared state and contract calls create new failure modes.

Key concepts

Open glossary

Execution layerComing soon
ABIComing soon
CalldataComing soon
AtomicityComing soon
Logs / eventsComing soon
IndexerComing soon
ComposabilityComing soon

Back to Blockchain Basics

Blockchain Basics hub

Next module

Scaling & Layer 2

How systems scale beyond base-layer throughput constraints.

© 2025 Tokenoversity. All rights reserved.