← 1-Year PathQ4 · Mastery

Week 43 — Smart Contracts & Protocol Design

Solidity, smart contracts, and how DeFi protocols are actually built.

Week 43 of 52 · ~7 hours · 13 slides · exam + project

Building on Ethereum

Smart contracts are the code that runs trust — and where the risk lives.

What you will learn

  • Understand smart contracts and Solidity
  • Explain DeFi protocol design
  • Recognize contract risk and audit

State on-chain

Block Header prev_hash (links chain) merkle_root (tx summary) timestamp nonce (PoW counter) difficulty Transactions tx_1 · from → to · amounttx_2 · from → to · amounttx_3 · from → to · amounttx_4 · from → to · amounttx_5 · from → to · amounttx_6 · from → to · amount
State on-chain

Immutable history

HASH 0transactionsBlock 1HASH 1transactionsBlock 2HASH 2transactionsBlock 3prevprevEach block stores the hash of the previous → tamper-evident chain
Immutable history

What a smart contract is

A smart contract is code stored on-chain that executes automatically when conditions are met — no intermediary, no discretion. Written in Solidity (Ethereum) and similar languages, it's immutable once deployed (unless built to be upgradeable). 'Code is law' — for better and worse.

💡 A simple contract

A token contract tracks balances and allows transfers. An escrow contract releases funds only when both parties sign. A vault contract holds assets and issues shares. Each is just code, but once deployed and holding real money, it becomes a financial institution run by logic, not people.

DeFi protocol design

Designing a protocol means deciding: the asset (tokenomics), the incentive (who gets paid to do what), the access (permissionless?), the governance (who changes parameters), and the security (what an attacker could exploit). Every design choice is also a risk choice.

The audit imperative

Because contracts are immutable and hold real value, a single bug can drain everything. Professional audits, bug bounties, formal verification, and battle-testing are mandatory — not optional. The history of DeFi is written in unaudited contracts getting drained.

💡 Why audits matter

Reentrancy (the DAO hack), integer overflow, oracle manipulation, flash-loan exploits — each was a known class of bug that cost millions when someone skipped the audit. The lesson: security is not a feature you add; it's the architecture you build from line one.

The takeaway for investors

You don't need to write Solidity — but you must be able to read what a protocol does and whether it's been audited. 'Don't trust, verify' applies to the code, not just the chain. Invest only in protocols whose security you can reason about.

❓ Quick check

Once deployed, a smart contract is typically:

A) Editable freely
B) Immutable (unless designed upgradeable)
C) Deleted after use
D) Private
(Knowledge check — full exam is next)

Key takeaways

  • Smart contracts = immutable code that runs trust
  • Design = asset, incentive, access, governance, security
  • Audits are mandatory; read before you invest

📝 Weekly Exam — pass with 80% to unlock next week

10 questions. Review the Deep Dive and courses before attempting.

1. A smart contract is:
Auto-executing code.
2. Solidity is used primarily on:
EVM smart-contract language.
3. Once deployed, a contract is by default:
Immutable.
4. 'Code is law' means:
Deterministic execution.
5. The most important security step for a protocol is:
Audit before value.
6. A reentrancy attack is:
Recursive call exploit.
7. For an investor, 'don't trust, verify' means:
Verify code and audit.
8. Governance in a protocol decides:
Who changes parameters.
9. The history of DeFi hacks is mostly:
Repeated known bugs.
10. Invest only in protocols whose security you can:
Reason about security.
Your score: —

🛠 Weekly Project

Read one protocol's audit summary.

1
Pick a DeFi protocol you might use.
2
Find whether it's been audited and by whom (check their docs).
3
Note any findings and whether they were resolved.
4
Write 2 sentences on whether you'd trust it with capital and why.
Open tool →
← Week 42  |  Week 44 →