Course Structure — Blockchain, Cryptocurrencies & Fintech

Interactive playground · Course structure

Blockchain, Cryptocurrencies & Fintech

This page is the academic companion to the interactive playground. It reconstructs the official IE University syllabus into a navigable map: what the course is about, how it is taught and graded, and a deep pass through all 15 live sessions — each broken down into its objective, the concepts it introduces, a one-sentence "key idea", suggested readings, and links to the matching hands-on demos. Where a topic is technical (hashing, ECDSA, the UTXO model, the EVM, Solidity, consensus, ZK proofs) a short definition box gives you the precise mental model to carry into class.

DegreeBCSAI — Bachelor in Computer Science & AI

Course codeBCF-CSAI.4.M.A

AreaComputer Science

Year · Semester4th year · 2nd semester

Credits3.0 ECTS

Sessions15 (live, in-person)

CategoryCompulsory

LanguageEnglish

Academic year2025–26

ProfessorDr. Milan Groshev

Contactmgroshev@faculty.ie.edu

Office hoursOn request (by email)

Subject description

Bitcoin and other cryptographic currencies have gained attention over the years as the systems continue to evolve. This course examines the design of the underlying mechanism behind Bitcoin and other cryptocurrencies: the blockchain. It focuses on how blockchains function in practice — through cryptography, programming, and network architecture — and looks ahead to future developments in smart contracts and privacy. Programming assignments throughout the term turn the theory into practical experience interacting with these currencies and protocols.

GenAI policy

Generative AI tools may be used for assignments and code writing with appropriate acknowledgement. GenAI may not be used for presentations, group submissions, or exams. Inappropriate use of AI-generated content is treated as academic misconduct and can mean failing the assignment or the course.

Prerequisites & how this course connects

This is a 4th-year compulsory course in the BCSAI degree, and it assumes the maturity that earlier years build. You do not need prior blockchain experience, but the cryptography and systems content lands much faster if the following are already comfortable — and each maps onto a specific part of the syllabus.

Programming & data structuresComfort reading code, plus trees and hashing — directly reused in Merkle trees (S5) and Solidity (S7).

Discrete maths / modular arithmeticFinite fields and modular exponentiation underpin ECDSA and ZK proofs (S2, S10).

Basic probabilityMining is a Poisson process; understanding expected work clarifies difficulty and 51% attacks (S3).

Networking intuitionPeer-to-peer gossip, latency and partitions explain why consensus is hard (S1, S3, S4).

A little JavaScriptHelpful for the Dapp front-end glue and for the playground demos that accompany the lectures.

Curiosity about economicsIncentives, game theory and token design recur from PoS through DAOs and Web3 (S3, S8–S11).

How it connects forward

The course is a ladder: cryptographic primitives (S1–2) secure a ledger; consensus (S3) agrees on its history; Bitcoin (S4–5) is the minimal application of those ideas; Ethereum (S6–7) generalises the ledger into a programmable world computer; DAOs/Dapps (S8–9) build organisations on top; ZK and Web3 (S10–11) push privacy, scaling and ownership; and the fintech lectures + capstone (S12–15) connect it all to research and industry. Skipping a rung makes the next one wobble — each session deliberately reuses the previous one's vocabulary.

Weekly study-load (3 ECTS ≈ 75 hours)

Across 15 sessions, budget roughly 5 hours per week total: ~1–1.5h consolidating the lecture, ~2–3h on the programming exercise that is due at the start of the next session, and ~1h on readings/discussion prep. The load is front-loaded toward exercises (sessions 2–11) and peaks again at the capstone (sessions 12–15). Treat each weekly exercise as non-optional rehearsal — they are 50% of the grade and the best preparation for the comprehensive re-sit exam should you ever need it.

Learning objectives

By the end of the course, students should be able to:

Understand the foundations. Explain the basic concepts behind modern blockchain-based systems — cryptographic ledgers, hashing, digital signatures, consensus, and the transaction/account models that Bitcoin and Ethereum use.
Program & simulate. Write and simulate custom programs — i.e. smart contracts — for currency and for the formalization of consensus rules, deploying and interacting with them on public blockchains.
Read the research. Engage with the latest blockchain research and develop the ability to critically analyze academic papers in the crypto ecosystem (the basis for the final group SWOT-style paper analysis).

Teaching methodology

IE University's teaching method is collaborative, active, and applied: students participate throughout to build knowledge and sharpen skills, while the professor leads and guides toward the learning objectives. The course mixes lectures, discussions, in-class and asynchronous exercises, fieldwork, group work, and independent study. The figures below are the weight of each activity in the workload and the estimated student time it represents (75 hours total for a 3-ECTS course).

Lectures20.0% · 15h

Discussions13.3% · 10h

Exercises in class, asynchronous sessions, field work33.3% · 25h

Group work13.3% · 10h

Individual studying20.0% · 15h

Applied work dominates: a third of the effort is hands-on exercises and fieldwork — which is exactly what the interactive playground is designed to support.

Assessment & evaluation

The grade is built from three components. At the end of each of sessions 2–11 a programming exercise is released (due at the start of the next session); these intermediate exercises are the largest single component. The course culminates in a group research-paper analysis presented in session 15.

Intermediate exercises50%

Group presentation40%

Class participation10%

50%

Intermediate exercises

Programming exercises released at the end of sessions 2 through 11, each due at the beginning of the following session. They demonstrate proficiency with blockchain tools and programming frameworks (hashing, signatures, consensus, Bitcoin/Ethereum tooling, Solidity, DAOs/Dapps, ZK proofs, Web3).

40%

Group presentation

A ~5-student group picks a blockchain research paper (candidates supplied across sessions 12–14) and presents a deep scientific analysis in session 15 — covering the strengths, weaknesses, opportunities, and threats (SWOT) of the chosen paper.

10%

Class participation

Active engagement in the live in-person sessions: discussion, in-class exercises, and contribution to the collaborative, applied format of the course.

Rubric & deliverable formats

What each component is actually judged on, and the form your submission should take. These criteria are an instructional reconstruction of the syllabus weights — always defer to the professor's exact brief for any given exercise.

Component	What it rewards	Deliverable format
Intermediate exercises (50%)	Correctness — does it produce the right result / pass the tests? Understanding — is the approach sound, not copy-pasted? Code quality — readable, commented, no obvious security holes. On time — due at the start of the next session.	Source code (Python/JS/Solidity) plus a short README or notebook explaining your reasoning; GenAI use acknowledged where applied. Submit per the professor's channel for each session.
Group presentation (40%)	Depth of analysis — a real, specific SWOT, not a summary. Technical accuracy — correct use of course concepts. Synthesis — links to the cryptography/consensus/contract material. Delivery — clarity, timing, fielding questions.	~5-student group talk in session 15 with slides; everyone presents. No GenAI permitted for this component (presentations & group submissions are excluded by the AI policy).
Class participation (10%)	Consistency across the live sessions, quality of questions and discussion, and active engagement in in-class exercises and the collaborative, applied format.	Continuous, in-person. Tied to the 80% attendance rule below — you cannot participate in sessions you miss.

Tips to maximise the grade

Never skip an exercise. At 50% over sessions 2–11, each is worth roughly 5 points of your final mark — and they're cumulative practice for everything after.
Submit something even if incomplete. Partial, well-explained work earns partial credit; a missing submission earns zero.
Acknowledge GenAI honestly on code where you used it — undisclosed use is misconduct that can fail the assignment or the course.
Treat participation as free marks you earn just by showing up prepared and engaging — but only if you meet the 80% attendance threshold.
Start the capstone in week 12. The 40% component rewards depth, and depth needs weeks, not days.

Pass, attendance & re-sit rules

Attendance: students who do not meet the 80% attendance rule fail both the ordinary and extraordinary calls for the year and must re-take (re-enroll) the next academic year.
Four calls: each student has four chances to pass a course across two consecutive academic years — ordinary and extraordinary (June/July re-sit) calls.
Ordinary fail → re-sit: failing in the ordinary call means re-sitting in June/July (unless barred by the attendance rule, which forces a re-enroll instead).
Re-sit format: the June/July extraordinary call is a single comprehensive exam, physically on campus (Segovia or Madrid). The grade depends on that exam only (continuous evaluation is not counted), with a minimum pass of 5 and a maximum of 8.0 ("notable").
Retakers: students re-enrolled after failing a previous year must check the assigned professor's syllabus and contact them about specific criteria; the maximum grade in the 3rd call (retake exam) is 10.0.
Review & appeals: a review session follows grading; attending it is a prerequisite for any grade appeal. Failing >18 ECTS in the year after the re-sits means leaving the program.

Program — the 15 sessions

All 15 sessions are live and in-person. The arc runs from cryptographic primitives → consensus → Bitcoin → Ethereum & smart contracts → DAOs/Dapps → privacy (ZK) → Web3 → fintech guest lectures. Programming exercises accompany sessions 2–11. Below, each session is expanded with its objective, the concepts it covers, a key idea, readings, and links into the matching interactive demos.

Module A · Cryptographic foundations & consensus

Sessions 1–3 · the primitives that make a tamper-evident ledger possible

Before any "coin" exists there is a data structure and some cryptography. This module builds the intuition for what a blockchain is — an append-only, tamper-evident ledger — and the two pillars that secure it: cryptographic hashing/signatures, and a consensus rule for agreeing on one history without a central authority.

Learning outcomes

Describe a blockchain as a hash-linked, tamper-evident sequence of records.
Explain public-key cryptography, ECDSA signatures, and the avalanche property of hashes.
Compare Proof of Work and Proof of Stake on security, scalability, energy and finality.

Session 1Live in-person

Introduction to cryptographic ledgers (blockchain)

Objective: establish what a blockchain is and frame the research landscape of the field.

The cryptographic ledger. A blockchain is a tamper-proof sequence of data that any user can read and append to with no trusted central operator. Why it matters: it solves the double-spend problem for digital money without a bank. How it works: data is grouped into blocks, each block commits to the previous block's hash, and a consensus rule decides which chain is canonical. Example: a payment ledger where everyone holds the same copy and can independently detect if a row was altered.
Centralised vs decentralised trust. Traditional systems trust an operator to keep an honest database; a blockchain replaces that with replication plus cryptography, so any participant can verify the whole history themselves rather than trusting a single party not to cheat or fail.
The research landscape. The instructor frames his own blockchain research and surveys live problem areas — scalability, privacy, MEV, cross-chain bridges — that the rest of the course (and the capstone paper) will draw on.

Core concept · Blockchain

A blockchain is an append-only ledger of blocks, where each block stores the cryptographic hash of the previous one. Because changing any historical record changes its hash — and therefore every later block's "previous-hash" link — tampering is immediately detectable. Trust comes from data structure + cryptography + consensus, not from an institution.

Worked example · a block as a struct

Strip away the jargon and a block is just a record that names its parent by hash:

block = {
  index:      4,
  timestamp:  1700000000,
  data:       "Alice → Bob: 5 BTC",
  prevHash:   "0000a3f1…9c",   // hash of block 3
  nonce:      0,
}
block.hash = SHA256(index‖timestamp‖data‖prevHash‖nonce)
// edit block 2's data → its hash changes →
// block 3's prevHash no longer matches → chain "breaks"

Key idea

A blockchain replaces "trust the operator" with "verify the math": the chain is its own audit trail.

Common pitfall

"Tamper-proof" really means tamper-evident. Nothing physically stops you editing your own copy — but everyone else can instantly see your hashes no longer line up, so your forged chain is simply rejected. Immutability is a social/economic property enforced by consensus, not a magic lock.

Readings

Antonopoulos, Mastering Bitcoin — Ch. 1 (What is Bitcoin?) for the big picture and vocabulary you'll reuse all term.
Nakamoto (2008), Bitcoin: A Peer-to-Peer Electronic Cash System — the 9-page original; read §3–4 (Timestamp Server, Proof-of-Work) to see the chained-ledger idea in its first form.

Key takeaway

Everything later in the course is a refinement of this one move: bind records with hashes, then agree on one history. Hold that picture and the rest is detail.

Play with it: Block chain visualiser Concept roadmap

Session 2Live in-person+ programming exercise

Signatures, hashing & hash chains

Objective: master the cryptographic primitives that give blockchains their security and privacy.

Hashing algorithms. One-way functions (e.g. SHA-256) map any input to a fixed 256-bit digest. Why it matters: they give every piece of data a unique, fixed-size fingerprint that is cheap to check but infeasible to forge or reverse. How it works: the function is deterministic and collision-resistant, with the avalanche effect. Example: a 1 GB file and the word "hi" both hash to exactly 64 hex characters.
Public-key cryptography. An asymmetric keypair where the private key signs/decrypts and the public key verifies/encrypts. It lets strangers exchange verifiable, confidential messages without ever sharing a secret — the basis of every blockchain identity (your address is derived from your public key).
ECDSA. The Elliptic Curve Digital Signature Algorithm signs transactions on Bitcoin and Ethereum over the secp256k1 curve. Elliptic curves give the same security as RSA with far smaller keys (256-bit vs ~3072-bit), which keeps signatures and addresses compact.
Hash chains & Merkle trees. Linking records by hash makes a sequence tamper-evident; hashing pairs of records up a tree yields a single Merkle root that commits to thousands of transactions at once.

Core concept · Cryptographic hash

A hash function maps arbitrary input to a fixed-length fingerprint such that it is infeasible to invert or to find two inputs with the same output (collision resistance). A one-bit change flips ~50% of output bits — the avalanche effect — which is why hashes detect tampering and bind blocks together.

Core concept · Digital signature (ECDSA)

A wallet stores a private key, not coins. Signing a message with it produces a signature anyone can check with the matching public key — proving authorization without revealing the secret. This is how a transaction proves "the owner approved this spend".

Worked example · sign & verify

Avalanche in action, then the signature flow Bitcoin actually uses:

SHA256("hello")  = 2cf24dba5fb0a30e26e83b2ac5b9e29e…
SHA256("hellp")  = b21f5b3a8f9c…    // one letter → totally different

// signing (secp256k1)
sig        = ECDSA_sign(privKey, SHA256(tx))
ok         = ECDSA_verify(pubKey, SHA256(tx), sig)  // → true
// pubKey is public; privKey never leaves the wallet

Key idea

Hashes make data tamper-evident; signatures make actions un-forgeable. Together they replace account passwords with provable authorization.

Common pitfall

The private key is the money. There is no "forgot password" — lose the key and the funds are gone, leak it and they're stolen. Also beware nonce reuse in ECDSA: signing two messages with the same random k leaks the private key (the 2010 PS3 hack). Real wallets use deterministic nonces (RFC 6979).

Readings

Antonopoulos, Mastering Bitcoin — Ch. 4 (Keys, Addresses): how private→public→address derivation and ECDSA actually chain together.
Goldreich (2019), Providing Sound Foundations for Cryptography — formal grounding for one-way functions and signatures; skim for the definitions, not the proofs.

Key takeaway

These two primitives are the whole security model. The exercise this week (your first of the 50% component) will have you hash data and verify a signature by hand — do it, because every later session assumes it.

Play with it: SHA-256 + avalanche ECDSA sign & verify Merkle trees

Session 3Live in-person+ programming exercise

Proof of Work vs Proof of Stake

Objective: deep-dive into the two dominant consensus models and weigh their trade-offs.

Proof of Work (Bitcoin). Miners race to find a nonce making the block hash fall below a target, verifying transactions by expending real hashing work. Why it matters: work is expensive to produce but trivial to check, so honest history becomes the one nobody can cheaply out-compute. Cost: serious energy use and limited throughput (~7 tx/s on Bitcoin). Example: Bitcoin retargets difficulty every 2016 blocks to hold a ~10-minute block time as hashpower grows.
Proof of Stake (Ethereum). Validators lock up (stake) ETH and are pseudo-randomly chosen to propose and attest blocks; dishonest behaviour is punished by slashing the stake. It replaces burned energy with at-risk capital, enabling faster finality — while opening new questions (long-range attacks, stake centralisation) as it matures.
Finality & the longest-chain rule. PoW offers probabilistic finality (more confirmations = safer); Ethereum's PoS adds explicit checkpoint finality via the Casper-FFG gadget, so blocks become irreversible after two finalised epochs.
Trade-offs. Weighing security, decentralisation, energy, throughput and finality — the practical lens for spotting each model's advantages and disadvantages.

Core concept · Proof of Work

Block producers search for a nonce so that SHA-256(block) < target. Finding it is hard (costs energy) but verifying it is trivial. Honest history is the one with the most cumulative work, so attacking it means out-hashing the whole network (~a 51% attack).

Core concept · Proof of Stake

Validators lock up (stake) capital and are pseudo-randomly chosen to propose/attest blocks. Misbehaviour is punished by slashing their stake. Security comes from economic skin-in-the-game rather than energy; Ethereum's 2022 "Merge" cut energy use ~99.95%.

Worked example · the mining loop

PoW in pseudocode — the whole "work" is brute-forcing a nonce:

target = 2**(256 - difficulty_bits)
nonce  = 0
while SHA256(blockHeader + nonce) >= target:
    nonce += 1          // ~ billions of tries
# found! verifying is ONE hash:
assert SHA256(blockHeader + nonce) < target

# difficulty_bits = 20  → ~1,000,000 hashes/block (toy)
# Bitcoin today      → ~10^23 hashes/block

Key idea

PoW buys security with electricity; PoS buys it with at-risk capital. Both make rewriting history more expensive than it's worth.

Common pitfall

A "51% attack" lets you reorder or censor recent blocks and double-spend — it does not let you steal coins or forge signatures (the cryptography still holds) or rewrite deeply-buried history. And in PoS the attacker's own stake gets slashed, so the attack is often self-defeating economically.

Readings

Buterin & Schneider (2022), Proof of Stake — the philosophy and design of PoS; pairs directly with this session.
Antonopoulos, Mastering Bitcoin — Ch. 10 (Mining & Consensus): difficulty retargeting and the longest-chain rule in detail.

Key takeaway

Consensus is the answer to "who gets to append the next block?" — and the choice of answer (work vs stake) cascades into energy, speed and decentralisation trade-offs you'll see again in every chain Bitcoin (S4) and Ethereum (S6) build on.

Play with it: Mine a block (PoW) PoW vs PoS comparison Difficulty & re-mining

Module B · Bitcoin: from core concepts to advanced features

Sessions 4–5 · the first decentralized digital currency, in depth

With the primitives in place, the course turns to Bitcoin itself: how value is represented and moved without accounts (the UTXO model), how nodes verify and synchronize the ledger, and the advanced machinery — light clients, wallet types, data embedding — that production systems use.

Learning outcomes

Explain Bitcoin transaction verification and the public distributed ledger.
Reason about the UTXO model, node synchronization, and pruning.
Describe SPV light clients, wallet types, and OP_RETURN/Catena data anchoring.

Session 4Live in-person+ programming exercise

Bitcoin introduction & core concepts

Objective: understand Bitcoin as the first decentralized digital currency and its building blocks.

Transaction verification. Every network node independently checks each transaction: signatures are valid, inputs reference real unspent outputs, and no value is created from nothing. Why it matters: "don't trust, verify" is what makes the network trustless — no node has to believe another. Example: your full node rejects a block even from a miner if a single signature is bad.
Public distributed ledger. Every full node holds and re-validates the entire shared history, so the ledger is replicated thousands of times over rather than held by one authority — censorship and silent edits become practically impossible.
UTXO model. Bitcoin tracks a set of unspent transaction outputs, not account balances. You spend coins by consuming whole outputs and creating new ones, which makes parallel validation and clear ownership easy (but stateful smart contracts hard).
Synchronization & pruning. A new node downloads and verifies from the genesis block forward (Initial Block Download); a pruned node keeps only the UTXO set and recent blocks, discarding old block data while still enforcing every rule — so it runs on modest hardware.

Core concept · UTXO model

Bitcoin has no account balances. The ledger is a set of Unspent Transaction Outputs. To pay, you consume whole UTXOs as inputs and create new UTXOs as outputs — typically one to the recipient and one back to yourself as change. Your "balance" is just the sum of UTXOs you can unlock.

Core concept · Pruning

A pruned node validates the full chain but then discards old block data it no longer needs, keeping only the UTXO set and recent blocks — letting it run on modest hardware while still enforcing all rules.

Worked example · spending UTXOs & change

Alice owns two UTXOs and wants to send Bob 0.7 BTC:

INPUTS  (consumed whole):
  utxo_A: 0.5 BTC   ┐ total 0.8 BTC
  utxo_B: 0.3 BTC   ┘
OUTPUTS (newly created):
  → Bob:   0.70 BTC
  → Alice: 0.0999 BTC   (change)
  fee = 0.8 − 0.70 − 0.0999 = 0.0001 BTC  (implicit, to miner)
// utxo_A and utxo_B are now SPENT and removed from the UTXO set

Key idea

In Bitcoin you don't "have a balance" — you hold a pocketful of unspent coins and spend them whole, making change like cash.

Common pitfall

The transaction fee is not a field you set directly — it's whatever inputs minus outputs leaves behind. Forget the change output and you tip the miner your entire remaining balance. Wallets add change automatically; raw-transaction builders do not.

Readings

Antonopoulos, Mastering Bitcoin — Ch. 6 (Transactions): inputs, outputs, scripts and fees; Ch. 2 (How Bitcoin Works) for the end-to-end payment story.

Key takeaway · connects to S6

The UTXO model is the foil for Ethereum's account model in Session 6: stateless coins that are great for parallelism and privacy, versus mutable accounts that are great for smart contracts. Knowing why Bitcoin chose UTXOs explains why Ethereum chose differently.

Play with it: UTXO transaction builder Supply schedule & halving

Session 5Live in-person+ programming exercise

Bitcoin advanced concepts & programming exercise

Objective: go beyond the basics into the tooling and extensions of the Bitcoin protocol.

SPV (Simplified Payment Verification). Light clients verify that a payment is included in the chain using only block headers plus a Merkle proof, never downloading the full ledger. Why it matters: it's what lets a phone wallet (a few MB of headers) trust the network without running a ~600 GB full node. How: request the sibling hashes that recompute the block's Merkle root, then check the root against a trusted header.
Wallet types. Non-deterministic (a random bag of keys) vs deterministic HD wallets (BIP-32/39/44, all keys derived from one seed phrase); hot (online) vs cold (offline/hardware) for the security/convenience trade-off; and custodial (an exchange holds your keys) vs self-custody ("not your keys, not your coins").
OP_RETURN. A script opcode that embeds up to ~80 bytes of provably-unspendable data in a transaction — the sanctioned way to anchor a hash or timestamp on-chain without bloating the UTXO set.
Catena. A scheme that anchors an append-only, auditable log to Bitcoin via a chain of OP_RETURN commitments, giving the log Bitcoin-grade non-equivocation guarantees.

Core concept · SPV & Merkle proofs

An SPV client downloads only block headers. To check that a transaction is included in a block it requests a Merkle proof — the handful of sibling hashes needed to recompute the block's Merkle root. This verifies membership in O(log n) hashes instead of downloading every transaction.

Core concept · HD wallets & OP_RETURN

A hierarchical-deterministic wallet derives millions of keypairs from one seed phrase (BIP-32/39/44). OP_RETURN lets a transaction carry up to ~80 bytes of arbitrary data, useful for timestamping/anchoring external records on-chain.

Worked example · a Merkle proof

To prove tx D is in a block of 4 transactions, you need just 2 hashes, not all 4:

            ROOT = H(H_AB ‖ H_CD)
           /                    \
      H_AB                        H_CD = H(H_C ‖ H_D)
                                      /        \
                                   H_C          H_D = H(D)

Proof for D = [ H_C , H_AB ]        // O(log n) hashes
verify:  H_CD' = H(H_C ‖ H(D));  ROOT' = H(H_AB ‖ H_CD')
         ROOT' == header.merkleRoot ?  →  D is included

Key idea

You don't need the whole blockchain to trust a payment — a Merkle proof against a header is enough, which is what makes phone wallets possible.

Common pitfall

SPV proves a transaction was included, not that it was valid or that the header chain is the real one — a light client trusts miners on validity and assumes it's seeing the most-work header chain. That weaker trust model is the price of not running a full node. And your seed phrase, not any single private key, is the real backup: lose it and an HD wallet is unrecoverable.

Readings

Antonopoulos, Mastering Bitcoin — Ch. 5 (Wallets): seeds, HD derivation paths; Ch. 8 (The Network): SPV, bloom filters and how light clients talk to peers.

Key takeaway

Merkle proofs reappear everywhere — in Ethereum's state trie, in rollups, and in ZK systems (S10). If you understand the proof above, you understand the data-availability trick behind most of modern scaling.

Play with it: Wallets & addresses Merkle proofs Forks & upgrades (SegWit, Taproot)

Module C · Ethereum & smart contracts

Sessions 6–7 · the programmable blockchain

Ethereum generalises the blockchain from "money" to "any program". This module introduces smart contracts as deterministic on-chain code and Solidity as the language to write them — the foundation for everything from tokens to DeFi to DAOs.

Learning outcomes

Explain smart contracts as deterministic "if this then that" programs stored on-chain.
Distinguish EOAs from contract accounts and understand gas as a metering mechanism.
Read and write basic Solidity, deploy a contract, and call its functions.

Session 6Live in-person+ programming exercise

Ethereum & smart contracts fundamentals

Objective: introduce smart contracts as the foundation of Ethereum's application layer.

Smart contracts. Programs stored at an address on the blockchain that follow "if this then that" logic and are guaranteed to execute exactly as their code defines. Why it matters: they remove the trusted intermediary from agreements — escrow, voting, lending run themselves. How: a transaction calls a function, every node runs the same code, and the resulting state is recorded identically everywhere. Example: a vending-machine contract that releases a token the instant payment clears.
Application layer. Contracts compose — one can call another — so simple pieces snap together into the dApp/DeFi ecosystem ("money legos"): a DEX calls a token, a lender calls the DEX, all atomically in one transaction.
Account model. Ethereum replaces UTXOs with mutable accounts that carry a balance and a nonce: EOAs are controlled by a private key, contract accounts are controlled by their code. State persists between calls, which is exactly what makes stateful programs (unlike Bitcoin script) possible.
Gas & the EVM. Every operation costs gas, paid in ETH, so computation is metered and infinite loops simply run out of fuel and revert — the network's defence against spam and denial-of-service.

Core concept · Smart contract

A smart contract is code deployed to an address on the blockchain. Anyone can call its functions by sending a transaction; the network executes the code deterministically and records the resulting state. There is no "off-switch" — it runs by the rules in its code, which is both its power and its risk.

Core concept · Account model & the EVM

Ethereum has two account types: EOAs (controlled by a private key; balance + nonce) and contract accounts (code + storage). All execution happens in the EVM, a deterministic stack machine; every opcode costs gas so computation is metered and spam is priced out.

Worked example · gas & the fee bill

Under EIP-1559 a transaction's cost has a burned base fee plus a tip to the validator:

gasUsed       = 21000           // a plain ETH transfer
baseFee       = 20 gwei         // set by the protocol, BURNED
priorityFee   = 2  gwei         // your tip to the validator
totalFee = gasUsed * (baseFee + priorityFee)
         = 21000 * 22 gwei = 462,000 gwei = 0.000462 ETH
// a contract call uses far more gas (e.g. ERC-20 transfer ≈ 50k)

Key idea

Ethereum is a world computer: a shared state machine where deploying code means publishing an unstoppable, publicly-callable program.

Common pitfall

"Immutable and unstoppable" cuts both ways: a bug in deployed code is permanent and publicly exploitable, and a reverted transaction still costs the gas it burned. The DAO hack (2016) and countless re-entrancy exploits since are all consequences of code being law.

Readings

Antonopoulos & Wood, Mastering Ethereum — Ch. 1–2 (Intro & Ethereum basics) for the account model; Ch. 7 (Smart Contracts) and Ch. 13 (the EVM) for execution & gas.

Key takeaway · connects to S4

This is the deliberate flip from Bitcoin's UTXO model (S4): mutable accounts and metered computation are what turn "digital cash" into "programmable money", at the cost of new attack surfaces you'll learn to defend against in Sessions 7–8.

Play with it: ETH account model EVM opcode walker Gas & EIP-1559 fees

Session 7Live in-person+ programming exercise

Solidity & programming exercise

Objective: get hands-on with Solidity and the crucial concepts behind programming Ethereum.

Solidity language. A statically-typed, contract-oriented language: contracts, state variables (in storage), functions with visibility (public/external/ internal/private), require guards and reusable modifiers. Why it matters: it's how you actually express on-chain logic. How: it compiles down to EVM bytecode that every node executes deterministically.
Deployment lifecycle. Compile → deploy (a transaction that writes bytecode to a new address, paid in gas) → call. msg.sender identifies the caller and is the foundation of access control (e.g. an onlyOwner modifier).
State, events & reverts. Writes change storage and cost gas; view reads are free; events log data cheaply for off-chain UIs; a failed require reverts the entire transaction atomically — all or nothing.
Token standards. ERC-20 (fungible) and ERC-721 (NFTs) are the canonical contract patterns; coding to their shared interfaces is what makes wallets and DEXes interoperable.

Core concept · Solidity

Solidity is a statically-typed, contract-oriented language that compiles to EVM bytecode. State variables live in contract storage; require(...) guards enforce conditions and revert the whole transaction (atomically) on failure. The deployer's address arrives as msg.sender in the constructor — the basis of ownership.

Core concept · ERC-20 / ERC-721

ERC-20 defines fungible tokens via functions like transfer, approve, and transferFrom — the approve/transferFrom pair is what lets DEXes pull your tokens. ERC-721 gives each tokenId a unique owner, pointing to off-chain metadata (often on IPFS).

Worked example · a minimal Solidity contract

Ownership via msg.sender, a guard via require, and an event:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract PiggyBank {
    address public owner;
    event Withdrawn(address to, uint amount);

    constructor() { owner = msg.sender; }   // deployer is owner

    receive() external payable {}            // accept ETH

    function withdraw(uint amount) external {
        require(msg.sender == owner, "not owner");   // access control
        require(amount <= address(this).balance, "too much");
        payable(owner).transfer(amount);             // effects after checks
        emit Withdrawn(owner, amount);
    }
}

Key idea

Standards are why composability works: any wallet or contract can talk to any ERC-20/721 token because they all expose the same function signatures.

Common pitfall · re-entrancy

Sending ETH hands control to the recipient mid-function; if you update state after the transfer, a malicious contract can call back in and drain you (the classic DAO bug). Follow checks-effects-interactions: validate, update state, then make external calls last. Also: uint underflow no longer wraps silently in Solidity ≥0.8 — it reverts.

Readings

Antonopoulos & Wood, Mastering Ethereum — Ch. 7 (Smart Contracts & Solidity), Ch. 10 (Tokens & ERC-20/721), Ch. 9 (Security: re-entrancy & common pitfalls).

Key takeaway

This is the most heavily-weighted skill in the exercise stream. Write, deploy and break your own contracts now — the same Solidity carries straight into the DAO and Dapp work in Sessions 8–9.

Play with it: Deploy a Solidity contract ERC-20 token NFTs (ERC-721)

Module D · DAOs & decentralized applications

Sessions 8–9 · governance and applications on top of contracts

Smart contracts can encode not just tokens but whole organisations. This module covers DAOs as contract-governed entities and Dapps as the user-facing front-ends, then puts it into practice by deploying a DAO and building an app against it.

Learning outcomes

Explain how a DAO encodes governance and coordination in smart contracts.
Describe the architecture of a Dapp (front-end + contracts + wallet/RPC).
Deploy a DAO to a public chain and interact with it through a Dapp.

Session 8Live in-person+ programming exercise

DAOs: principles & mechanisms · Dapps and DAOs

Objective: understand DAO governance and how algorithms and people cooperate without a traditional company.

DAO principles. A Decentralized Autonomous Organization encodes its membership, treasury, and decision rules in smart contracts rather than a corporate hierarchy. Why it matters: strangers across the world can pool funds and govern them with no bank signatory or legal incorporation. How: token holders submit proposals, vote on-chain, and passing proposals execute automatically. Example: a grants DAO that releases treasury ETH only when a vote crosses quorum.
Governance mechanisms. Voting power is usually token-weighted (1 token = 1 vote), with parameters like quorum, voting period, and an execution timelock that delays passed proposals so members can exit if they disagree.
Algorithms + individuals. DAOs let code and people cooperate without forming a traditional legal entity — the contract is the constitution, the bylaws and the bank account all at once.
Dapps and DAOs. A Dapp is the human interface: the tools and mechanisms to build a DAO, deploy it on a public blockchain, and interact with it through a web front-end wired to the contracts via a wallet/RPC provider.

Core concept · DAO

A Decentralized Autonomous Organization is an entity whose rules — membership, treasury, voting, execution — are encoded in smart contracts. Token holders propose and vote on actions; passing proposals execute on-chain automatically, replacing bylaws and bank signatories with code.

Core concept · Dapp

A Dapp (decentralized application) pairs a normal web front-end with on-chain smart contracts as its backend. The browser talks to the chain through a wallet/RPC provider, so logic and state are public and censorship-resistant rather than living on a private server.

Worked example · the proposal lifecycle

The on-chain governance loop most DAO frameworks (e.g. OpenZeppelin Governor) implement:

1. propose(targets, calldata, description)   → proposalId
2. … voting delay …
3. castVote(proposalId, support)             // weight = token balance
4. … voting period ends; tally vs quorum …
5. queue(proposalId)                         // enters timelock
6. … timelock delay (e.g. 2 days) …
7. execute(proposalId)                        // the calldata runs on-chain

Key idea

A DAO is "the company is the contract": governance and money move only when code says a vote passed — no boardroom required.

Common pitfall

Token-weighted voting is plutocratic — a "whale" or a flash-loaned majority can pass a proposal to drain the treasury (governance attacks are real). Timelocks, quorums and delegation mitigate this but don't eliminate it. "Decentralized" governance is only as decentralized as its token distribution.

Readings

Antonopoulos & Wood, Mastering Ethereum — Ch. 9 (Smart Contract Security) and the original The DAO case study — required reading for why governance code must be bulletproof.

Key takeaway · connects to S7

A DAO is just the Solidity from Session 7 with voting logic and a treasury attached. Every access-control and re-entrancy lesson applies with higher stakes, because here the contract literally holds the money.

Play with it: Contract state & access control Calling contract functions

Session 9Live in-person+ programming exercise

Deploying DAOs & building Dapps

Objective: deploy DAOs on public blockchains and interact with them via Dapps.

Deployment. Compiling and publishing a DAO's governance contracts to a public chain — first a testnet (Sepolia/Holesky, free faucet ETH) to rehearse, then optionally mainnet. Why it matters: deployment is irreversible and gas-priced, so you get one shot at the constructor parameters. How: a tool like Hardhat/Foundry sends the creation transaction and returns the new contract address.
Dapp integration. Wiring a front-end (ethers.js/web3.js + a wallet like MetaMask) to the contract's ABI so users can read state, submit proposals, and cast votes from a browser.
Reads vs writes. view calls are free and instant; state-changing calls are transactions that cost gas, must be signed by the user's wallet, and only confirm after a block — the UI has to handle that latency and possible failure.
Practical exercise. A programming exercise completing the full deploy-and-interact loop, end to end.

Core concept · Deploy & interact loop

Deploying writes contract bytecode to a new address (paid in gas); from then on the Dapp builds transactions that call the contract's functions. Reads are free (view calls); writes cost gas and change on-chain state. The same loop underpins every dApp you'll build.

Worked example · calling a contract from a Dapp

The read/write split with ethers.js — note which line opens the wallet:

import { ethers } from "ethers";
const provider = new ethers.BrowserProvider(window.ethereum);
const dao = new ethers.Contract(daoAddress, daoAbi, provider);

// READ — free, no wallet popup, returns immediately
const state = await dao.state(proposalId);

// WRITE — needs a signer; pops MetaMask, costs gas, awaits a block
const signer = await provider.getSigner();
const tx = await dao.connect(signer).castVote(proposalId, 1);
await tx.wait();   // confirmed on-chain

Key idea

Shipping a Dapp is mostly wiring a UI to function calls — the hard, irreversible part is getting the contract logic right before you deploy.

Common pitfall

Deploy to a testnet first — a constructor typo on mainnet is permanent and the gas is gone. Other classics: forgetting that the front-end may be on the wrong network, not handling a user who rejects the wallet popup, and treating a sent transaction as final before tx.wait() confirms it (it can still revert).

Readings

Antonopoulos & Wood, Mastering Ethereum — Ch. 12 (Dapps): the web3 stack, providers, and connecting front-ends to deployed contracts.

Key takeaway

This is the last "build" session before the frontier topics — by the end you can take an idea from Solidity to a working, deployed, clickable app, which is exactly the proficiency the 50% exercise stream is grading.

Play with it: Deploy & call (simulated) Cost of deploys & calls

Module E · Privacy & new directions in Web3

Sessions 10–11 · scaling, privacy and the next iteration of the web

The frontier of the field: proving things without revealing them (zero-knowledge proofs, which also power ZK-rollups and scaling), and the broader Web3 vision of a decentralized, token-economic internet.

Learning outcomes

Define a zero-knowledge proof and create/verify a simple one.
Connect ZK proofs to privacy and to L2 scaling (ZK-rollups).
Articulate what distinguishes Web3 from Web1/Web2 paradigms.

Session 10Live in-person+ programming exercise

Zero-knowledge proofs

Objective: learn to create and verify proofs that reveal nothing beyond a statement's truth.

Prover & verifier. A prover convinces a verifier that a statement is true. Why it matters: you can prove you satisfy a condition (over-18, solvent, know a password) without revealing the underlying data. Example: proving you know a maze's exit by repeatedly emerging from the side the verifier names, without ever showing the path.
The three properties. A good ZK system is complete (true statements always verify), sound (false statements almost never do), and zero-knowledge (the proof leaks nothing beyond the statement's truth).
SNARKs vs STARKs. zk-SNARKs are tiny and cheap to verify but need a trusted setup; zk-STARKs need no trusted setup and are post-quantum, at the cost of larger proofs — the practical engines behind on-chain ZK.
Tooling & applications. Circuits (e.g. Circom) compile a computation into a provable form; the two killer apps are privacy (shielded transactions) and scaling (ZK-rollups proving a batch of transactions in one succinct proof).

Core concept · Zero-knowledge proof

A zero-knowledge proof lets a prover convince a verifier that a statement is true while revealing nothing else — not the witness, not the secret. Good ZK systems are complete (true statements verify), sound (false ones don't), and zero-knowledge (no extra information leaks). zk-SNARKs/STARKs make this practical on-chain.

Worked example · commit, then prove

A hash commitment is the simplest "reveal nothing yet" primitive ZK builds on:

// PROVER picks secret s, sends only a commitment:
commit = SHA256(s ‖ r)        // r = random blinding factor
// …later, to PROVE knowledge of s without re-using it elsewhere,
// a ZK proof shows:  "I know s,r such that SHA256(s‖r)=commit
//                      AND s satisfies <statement>"
// VERIFIER checks the proof; learns ONLY that it's true.

// ZK-rollup analogy:
proof = prove( "I correctly executed 5,000 transactions,
                old_root → new_root" )
// L1 verifies one small proof instead of re-running 5,000 txs

Key idea

ZK proofs separate "I can prove it" from "I'll show you how" — enabling both privacy and cheap verification of huge computations (the heart of ZK-rollups).

Common pitfall

"Zero-knowledge" is not "anonymous by default" — a ZK system only hides what the circuit is designed to hide; metadata (timing, amounts, the calling address) can still leak. And SNARKs' trusted setup is a real risk: if the setup's secret "toxic waste" survives, an attacker can forge proofs. Soundness is computational, not absolute.

Readings

Goldreich (2019), Providing Sound Foundations for Cryptography — Goldwasser–Micali and the origins of zero-knowledge; the conceptual source for this whole session.

Key takeaway · connects to S5

ZK-rollups are the grown-up version of the Merkle-proof idea from Session 5: instead of proving one transaction is included, you prove a whole batch was executed correctly — succinct verification is the throughline.

Play with it: L2 rollups (incl. ZK) Commitments via hashing

Session 11Live in-person+ programming exercise

New directions in Web3

Objective: explore the Web3 ecosystem and what sets it apart from earlier web paradigms.

Decentralization. Shifting control from platforms to open protocols and users. Why it matters: if the rules live in public contracts rather than a company's servers, no single party can deplatform, rug, or silently change the terms. Example: a DEX that keeps trading even if its founding team disappears.
Blockchain technologies. The Web3 stack — decentralized identity (wallets/ENS), decentralized storage (IPFS/Arweave), oracles for off-chain data, and composable on-chain services that any app can build on.
Token-based economics. Tokens align incentives: they can represent ownership (equity-like), access (utility), or governance (votes), and are the coordination glue that lets a protocol bootstrap a network without a central paymaster.
DeFi primitives. Lending, automated market makers (AMMs), and derivatives — the composable "money legos" that show Web3's economics in action.

Core concept · Web3

Web3 reframes the web around user-owned data and assets: instead of logging into platforms that own your content (Web2), you hold keys to portable tokens and identities, and apps are built on open, composable protocols. Token economics align incentives between users, builders, and the network itself.

Worked example · the AMM constant-product rule

Uniswap-style pricing with no order book — just x·y=k:

pool: x = 100 ETH, y = 300,000 USDC   →  k = x·y = 30,000,000
buy ETH with 3,000 USDC (0.3% fee):
  y' = 300,000 + 3,000*0.997 = 302,991
  x' = k / y' = 30,000,000 / 302,991 = 99.013 ETH
  ETH received = 100 − 99.013 = 0.987 ETH
// price impact (slippage): big trades move x·y along the curve
// liquidity providers earn the 0.3% fee on every swap

Key idea

Web1 = read, Web2 = read/write, Web3 = read/write/own — ownership is the new primitive.

Common pitfall

"Decentralized" is a spectrum, not a badge — many Web3 apps still depend on centralized RPC providers, front-ends, or admin keys that can pause or upgrade the contract. Token incentives also invite speculation and ponzi-like designs; read tokenomics the way you'd read a balance sheet, and watch for AMM impermanent loss on the LP side.

Readings

Buterin & Schneider (2022), Proof of Stake — essays on the philosophy and social layer of blockchains; the best framing for "what is Web3 actually for".
Antonopoulos & Wood, Mastering Ethereum — Ch. 12 (Dapps) for the concrete Web3 stack underneath the vision.

Key takeaway

This is the last lecture before the guest series — it's deliberately a synthesis, pulling tokens (S7), DAOs (S8), privacy/scaling (S10) into one picture of where the ecosystem is going, which is exactly the lens to bring to the capstone paper.

Play with it: AMM / DeFi (x·y=k) NFTs & on-chain ownership Scaling with L2

Module F · Fintech guest lectures & research capstone

Sessions 12–15 · industry perspectives and the final group analysis

The course closes with three fintech guest lectures bringing industry and applied perspectives, followed by the capstone: a group scientific analysis of a chosen blockchain research paper. Paper candidates are distributed across sessions 12–14 and presented in session 15.

Learning outcomes

Connect course concepts to real fintech practice via guest speakers.
Select and critically read a blockchain research paper.
Present a structured SWOT analysis as a group.

Session 12Live in-person

Fintech guest lecture I

Objective: hear an industry/applied perspective on blockchain & fintech; paper candidates begin to be distributed.

Guest perspective. A practitioner view connecting course theory to real fintech systems — payments, settlement, custody, tokenisation, or regulation in the wild. Why it matters: it grounds the protocol-level material in the constraints (compliance, UX, risk) that decide what actually ships.
Capstone kickoff. The first batch of candidate research papers for the final group analysis is shared; start skimming abstracts now to find a topic your group cares about.

Key idea

Start reading early: the best capstone presentations choose their paper in week 12, not week 14.

How to prepare

Bring one question that links the guest's domain to a concept from Sessions 1–11.
Log every candidate paper's title, venue and year — you'll compare them as a group later.

Session 13Live in-person

Fintech guest lecture II

Objective: continue building the industry/fintech picture; refine paper selection.

Guest perspective. A second applied fintech viewpoint — likely a different vertical (e.g. DeFi/CBDCs/RegTech) so the cohort sees the breadth of where blockchain meets finance.
Paper candidates. Further research-paper options provided; by now your group should be shortlisting two or three and reading their introductions and results sections.

How to prepare

Shortlist papers by what your group can critique credibly, not just by buzz.
Check each paper is peer-reviewed and recent enough to matter, but old enough to have follow-ups.

Session 14Live in-person

Fintech guest lecture III

Objective: final guest perspective and finalize the choice of capstone paper.

Guest perspective. A third fintech/industry lecture — often the most forward-looking, covering emerging risks or the regulatory horizon.
Lock the paper. Last batch of candidate papers; groups confirm their selection and start dividing the SWOT axes among members so each person owns part of the analysis.

How to prepare

Confirm your paper today — session 15 is one week away and the analysis takes real time.
Assign roles: who reads method vs results, who builds slides, who rehearses the talk.

Session 15Live in-person

Final research-paper presentations

Objective: deliver the group's deep scientific analysis of a chosen blockchain research paper.

Group presentation (~5 students). The 40% capstone component.
SWOT analysis. A structured examination of the paper's strengths, weaknesses, opportunities, and threats.
Synthesis. Connecting the paper back to the cryptography, consensus, and smart-contract concepts from across the course.

Capstone · SWOT paper analysis

A SWOT analysis frames a research paper along four axes: Strengths (what it does well / its contribution), Weaknesses (assumptions, gaps, limits), Opportunities (follow-on work, applications) and Threats (risks, competing approaches, attack surface). It rewards reading like a reviewer, not a consumer.

Key idea

Note the GenAI policy: presentations and group submissions must be your own — AI tools are not permitted for this component.

Presentation tips (40% of the grade)

Lead with the contribution. In one slide, state what the paper claims and why it matters before you critique it.
Be specific in the SWOT. "Weak evaluation" is empty; "tested only on a 4-node private chain, so the scalability claim is unsupported" is a real critique.
Connect back to the course. Tie the paper to the exact concept it builds on (consensus, ZK, the account model) — graders reward synthesis.
Rehearse the timing and the handoffs. Five speakers means four transitions; practise them so the talk flows.
Anticipate questions. Know the paper's threat model and its one biggest assumption cold — that's where the questions land.

Key concepts — glossary

A quick-reference for the core vocabulary of the course. Each term links conceptually to a session above and, where applicable, to a live demo in the playground.

Blockchain: An append-only ledger of hash-linked blocks; tampering with any record breaks every later link, making history tamper-evident.

Cryptographic hash: A one-way function (e.g. SHA-256) giving a fixed-size fingerprint; collision-resistant, with the avalanche effect.

Avalanche effect: A one-bit input change flips ~50% of a hash's output bits — why hashes detect tampering.

Public-key cryptography: A keypair where the private key signs/decrypts and the public key verifies/encrypts.

ECDSA: Elliptic Curve Digital Signature Algorithm; signs transactions on Bitcoin (secp256k1) and Ethereum.

Digital signature: Proof that the holder of a private key authorized a message, verifiable by anyone with the public key.

Merkle tree / root: A hash tree summarising many transactions in one root hash; enables compact membership (Merkle) proofs.

Nonce: A number miners vary to find a hash below the target (PoW); also a per-account counter on Ethereum to order txs.

Proof of Work (PoW): Consensus by expending hashing energy to find valid blocks; security ∝ cost of out-hashing the network.

Proof of Stake (PoS): Consensus by staking capital; misbehaviour is slashed. Lower energy, faster finality.

Mining / difficulty: Searching nonces against a difficulty target; higher difficulty means exponentially more work per block.

51% attack: Controlling a majority of hashpower (PoW) or stake (PoS) to rewrite recent history.

UTXO: Unspent Transaction Output — Bitcoin's accounting unit; spent whole, with change returned to the sender.

SPV: Simplified Payment Verification — a light client verifying payments from block headers + Merkle proofs.

HD wallet: Hierarchical-deterministic wallet deriving many keys from one seed (BIP-32/39/44).

OP_RETURN: A Bitcoin script opcode embedding a small, unspendable data payload (e.g. for anchoring/timestamping).

Fork (soft/hard): A rule change: soft forks tighten rules (backward-compatible); hard forks are incompatible and can split the chain.

Halving: Bitcoin's block reward halves every 210,000 blocks (~4 years), converging on the 21M BTC cap.

Account model: Ethereum's alternative to UTXOs: EOAs (key-controlled) and contract accounts (code + storage), each with a balance/nonce.

EVM: Ethereum Virtual Machine — the deterministic stack machine that executes contract bytecode.

Gas / EIP-1559: The unit metering EVM work; under EIP-1559 the base fee is burned and a priority tip pays the validator.

Smart contract: Deterministic code at an address that executes exactly as written when called — "if this then that".

Solidity: Ethereum's main contract language, compiled to EVM bytecode; uses require, modifiers, and msg.sender.

ERC-20: Fungible-token standard (transfer, approve, transferFrom, …) enabling DeFi composability.

ERC-721 (NFT): Non-fungible token standard; each unique tokenId has one owner and points to off-chain metadata.

AMM (x·y=k): Automated market maker holding two assets at constant product; large trades incur slippage; LPs earn the fee.

DeFi: Decentralized finance — lending, trading, and derivatives built from composable token contracts, no intermediary.

DAO: Decentralized Autonomous Organization governed by smart-contract rules and token-holder voting.

Dapp: Decentralized application: a web front-end backed by on-chain contracts via a wallet/RPC provider.

Layer-2 / rollup: Off-chain execution posting compressed state to L1; optimistic (fraud proofs) vs ZK (validity proofs).

Zero-knowledge proof: A proof that a statement is true revealing nothing else; powers privacy and ZK-rollups (zk-SNARK/STARK).

Web3: A user-owned web of portable tokens, identities, and open protocols, coordinated by token economics.

Genesis block: The first block of a chain (height 0), hard-coded with no parent; the anchor every other block ultimately links back to.

Block header: The compact summary of a block (prev-hash, Merkle root, timestamp, nonce, target) — all an SPV client needs to verify proofs.

secp256k1: The specific elliptic curve used by Bitcoin and Ethereum for ECDSA keys and signatures.

Seed phrase (BIP-39): 12–24 human-readable words that encode the master seed of an HD wallet; whoever holds it controls every derived key.

Hot vs cold wallet: Hot wallets are connected to the internet (convenient, exposed); cold wallets stay offline/hardware (safer, slower).

Custodial vs self-custody: A custodian (e.g. an exchange) holds your keys for you; self-custody means you alone hold them — "not your keys, not your coins".

Finality: The point at which a block is irreversible: probabilistic in PoW (more confirmations), explicit/checkpointed in Ethereum PoS.

Slashing: The PoS penalty that destroys part of a validator's stake for provable misbehaviour (double-signing, equivocation).

Validator: A PoS participant who stakes capital to propose and attest blocks, earning rewards and risking slashing.

EOA: Externally-Owned Account — an Ethereum account controlled by a private key (balance + nonce), as opposed to a contract account.

ABI: Application Binary Interface — the JSON description of a contract's functions/events that lets a Dapp encode calls to it.

msg.sender: In Solidity, the address that called the current function — the basis of ownership and access control.

Re-entrancy: An attack where a called contract calls back in before state is updated; mitigated by the checks-effects-interactions pattern.

require / revert: Solidity guard that aborts and rolls back the whole transaction (atomically) when a condition fails.

Testnet: A practice network (e.g. Sepolia) with free faucet ETH for rehearsing deploys before risking real value on mainnet.

Gwei: A denomination of ETH (10⁻⁹ ETH) used to quote gas prices.

Timelock: A delay between a DAO proposal passing and executing, giving members time to react or exit.

Quorum: The minimum participation/votes a DAO proposal needs to be valid, preventing low-turnout capture.

zk-SNARK / zk-STARK: Succinct ZK proof systems; SNARKs are tiny but need a trusted setup, STARKs need none and are post-quantum but larger.

Trusted setup: A one-time ceremony generating SNARK parameters; its secret "toxic waste" must be destroyed or proofs can be forged.

Oracle: A service that feeds trusted off-chain data (prices, events) to contracts, which otherwise can't see the outside world.

IPFS: A content-addressed P2P storage network commonly used to host NFT metadata and Dapp front-ends off-chain.

Impermanent loss: The opportunity cost an AMM liquidity provider suffers when pool prices diverge from just holding the two assets.

Double-spend: Spending the same coin twice; preventing it without a central authority is the core problem blockchains solve.

Bibliography

Recommended texts from the official syllabus, annotated for how they map onto the course.

Mastering Bitcoin: Programming the Open Blockchain

Andreas M. Antonopoulos (2017) · O'Reilly Media · ISBN 978149195438 (Digital)

The reference for Module B. Best for hashing, keys/addresses, the UTXO model, transactions, wallets, SPV, and PoW mining (Sessions 1–5).
Mastering Ethereum: Building Smart Contracts and Dapps

Andreas Antonopoulos & Gavin Wood (2018) · O'Reilly Media · ISBN 978149197194 (Digital)

The reference for Modules C–E. Covers the account model, EVM, gas, Solidity, tokens, smart-contract security, DAOs and Dapps (Sessions 6–11).
Proof of Stake: The Making of Ethereum and the Philosophy of Blockchains

Vitalik Buterin & Nathan Schneider (2022) · Seven Stories Press · ISBN 978164421248 (Digital)

Essays on consensus design and the social/economic philosophy behind PoS and Web3 (Sessions 3, 11).
Providing Sound Foundations for Cryptography: On the work of Shafi Goldwasser and Silvio Micali

Oded Goldreich (2019) · ISBN 9781450372671 (Digital)

The theoretical backbone: one-way functions, signatures, and the origins of zero-knowledge proofs (Sessions 2, 10).

Policies & conduct

Behavior: see IE University's Code of Conduct; the Program Director may add indications.
Attendance: see IE University's Attendance Policy (80% rule applies — see Assessment above).
Ethics: see IE University's Ethics Code.

Full official details are in the syllabus PDF.