← Back to all projects

WEB3 DEEP UNDERSTANDING PROJECTS

Web3 Deep Understanding - Project-Based Learning Path

Overview

Web3 represents a paradigm shift from centralized to decentralized systems. To truly understand it, you must understand why it exists and how each component works at a fundamental level.

Why Web3 Exists

The traditional web (Web2) has fundamental problems:

  • Trust: You must trust centralized entities (banks, tech companies) not to manipulate data
  • Censorship: Single points of control can deny access
  • Ownership: You don’t truly own your digital assets; you rent access
  • Privacy: Your data is harvested and monetized without consent

Web3 solves these through cryptographic guarantees and decentralized consensus—code that enforces rules without requiring trust in any party.

Core Concepts You’ll Master

Concept Area What You’ll Understand
Cryptography Hash functions, digital signatures, elliptic curves, zero-knowledge proofs
Data Structures Merkle trees, Patricia tries, blockchain structure
Consensus Proof of Work, Proof of Stake, Byzantine fault tolerance
State Machines How the EVM executes contracts, gas, storage
Economics Token mechanics, incentive design, game theory
Security Attack vectors, reentrancy, oracle manipulation
Protocols Bitcoin, Ethereum, Layer 2s, bridges

Project 1: Cryptographic Hash Function Visualizer

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Rust
  • Alternative Programming Languages: C, Go, Python
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Cryptography / Hash Functions
  • Software or Tool: SHA-256 Implementation
  • Main Book: “Serious Cryptography, 2nd Edition” by Jean-Philippe Aumasson

What you’ll build

A command-line tool that implements SHA-256 from scratch (no crypto libraries), visualizing each step: message padding, block processing, compression function rounds, and the avalanche effect.

Why it teaches Web3

Hash functions are the foundation of everything in Web3. Block hashes, transaction IDs, Merkle trees, proof-of-work mining—all depend on understanding that hash functions are one-way, deterministic, and avalanche-sensitive. Without implementing one yourself, you’re just trusting magic.

Core challenges you’ll face

  • Bit manipulation (rotating, shifting, XORing 32-bit words) → maps to low-level cryptography
  • Message padding (handling arbitrary-length input) → maps to protocol specifications
  • Compression function (64 rounds of mixing) → maps to understanding irreversibility
  • Avalanche visualization (showing how 1-bit change affects output) → maps to security intuition

Key Concepts

  • Hash Function Properties: “Serious Cryptography” Chapter 6 - Jean-Philippe Aumasson
  • Bit Manipulation in C: “The C Programming Language” Chapter 2 - Kernighan & Ritchie
  • SHA-256 Specification: NIST FIPS 180-4

Difficulty

Intermediate

Time estimate

1-2 weeks

Prerequisites

Basic programming, understanding of binary/hex

Real world outcome

$ ./sha256_visualizer "Hello"
Input: "Hello" (5 bytes)
Padded: 48656c6c6f80000000...0028 (64 bytes)

Round 0:  A=5d6aeb04 B=6a09e667 C=bb67ae85 ...
Round 1:  A=2a0c8e42 B=5d6aeb04 C=6a09e667 ...
...
Round 63: A=185f8db3 B=2271fe25 C=f14f0564 ...

Final Hash: 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969

Avalanche Test:
"Hello" → 185f8db32271fe25...
"hello" → 2cf24dba5fb0a30e...
         ^^^^^^^^^^^^^^^^ (32/64 bytes different = 50%)

Implementation Hints

Start by reading FIPS 180-4 specification (it’s surprisingly readable). Implement the message schedule (W array) first, then the compression function. Use uint32_t for words. The key insight: each round mixes bits so thoroughly that reversing even one round is computationally infeasible. For visualization, print intermediate values in hex with color coding (green = bits that changed).

Pseudo-code structure:

function sha256(message):
    padded = pad_message(message)
    blocks = split_into_512bit_blocks(padded)
    H = initial_hash_values  // These are specific constants

    for each block:
        W = expand_to_64_words(block)
        a,b,c,d,e,f,g,h = H

        for round in 0..63:
            // Apply mixing functions
            T1 = h + Σ1(e) + Ch(e,f,g) + K[round] + W[round]
            T2 = Σ0(a) + Maj(a,b,c)
            // Shift and update

        H = H + (a,b,c,d,e,f,g,h)

    return concatenate(H)

Learning milestones

  1. Message padding works correctly → You understand protocol specifications
  2. Single block hashes match known values → You’ve implemented cryptographic primitives
  3. Avalanche visualization shows ~50% bit changes → You understand security properties

Project 2: ECDSA Digital Signature Implementation

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Rust
  • Alternative Programming Languages: Python, Go, C
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
  • Difficulty: Level 4: Expert
  • Knowledge Area: Cryptography / Elliptic Curves
  • Software or Tool: secp256k1 Signature Tool
  • Main Book: “Elliptic Curve Cryptography for Developers” by Michael Rosing

What you’ll build

A complete ECDSA implementation using the secp256k1 curve (same as Bitcoin/Ethereum). Generate key pairs, sign messages, and verify signatures—all from scratch without crypto libraries.

Why it teaches Web3

Every transaction in Bitcoin and Ethereum is authorized via ECDSA. When you send crypto, you’re creating a signature that mathematically proves you own the private key. Understanding this means understanding ownership in Web3—not “someone says you own it,” but “math proves you own it.”

Core challenges you’ll face

  • Modular arithmetic (operations in finite fields) → maps to mathematical foundations
  • Point addition on curves (geometric operations become algebra) → maps to elliptic curve math
  • Random number generation (k value must be truly random) → maps to critical security
  • Signature malleability (understanding s-value normalization) → maps to protocol subtleties

Key Concepts

  • Elliptic Curve Math: “Elliptic Curve Cryptography for Developers” Chapters 2-4 - Michael Rosing
  • secp256k1 Parameters: Bitcoin Wiki ECDSA
  • Practical Implementation: “Practical Cryptography for Developers” - cryptobook.nakov.com
  • Security Considerations: “Serious Cryptography” Chapter 11 - Jean-Philippe Aumasson

Difficulty

Expert (requires comfort with modular arithmetic)

Time estimate

3-4 weeks

Prerequisites

Project 1 (hash functions), basic number theory, comfort with mathematical notation

Real world outcome

$ ./ecdsa generate
Private Key: 0x1a2b3c4d5e6f...
Public Key:  04:7b3f2a...

$ ./ecdsa sign --key private.key --message "Send 1 ETH to Alice"
Message Hash: 0x9f86d081884c...
Signature (r,s): (0x3045..., 0x3046...)

$ ./ecdsa verify --pubkey public.key --message "Send 1 ETH to Alice" --sig signature.bin
✓ Signature VALID - This message was signed by this key

$ ./ecdsa verify --pubkey public.key --message "Send 100 ETH to Eve" --sig signature.bin
✗ Signature INVALID - Message or signer mismatch

Implementation Hints

Start with finite field arithmetic: implement mod_add, mod_sub, mod_mul, mod_inv (use extended Euclidean algorithm for inverse). Then implement point operations: point_add, point_double, scalar_mult. The secp256k1 curve is y² = x³ + 7 over a prime field.

Critical security note: The random k value in signing MUST be cryptographically random. Reusing k or using predictable k leaks your private key (this is how the PlayStation 3 was hacked).

Pseudo-code for signing:

function sign(private_key, message_hash):
    k = random_in_range(1, n-1)  // n = curve order
    R = k * G                     // G = generator point
    r = R.x mod n
    s = k_inv * (message_hash + r * private_key) mod n
    return (r, s)

function verify(public_key, message_hash, r, s):
    s_inv = modular_inverse(s, n)
    u1 = message_hash * s_inv mod n
    u2 = r * s_inv mod n
    R = u1*G + u2*public_key
    return r == R.x mod n

Learning milestones

  1. Modular inverse works correctly → You understand finite field arithmetic
  2. Point multiplication matches test vectors → You’ve implemented elliptic curve operations
  3. Sign/verify round-trips correctly → You understand digital signatures
  4. Your signatures validate in real Bitcoin/Ethereum libraries → You’ve achieved compatibility

Project 3: Merkle Tree Library

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Go
  • Alternative Programming Languages: Rust, C, TypeScript
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Data Structures / Blockchain
  • Software or Tool: Merkle Tree / Proof Generator
  • Main Book: “Mastering Bitcoin” by Andreas M. Antonopoulos

What you’ll build

A Merkle tree library that constructs trees from data, generates inclusion proofs, and verifies proofs. Visualize tree structure and demonstrate how changing one leaf affects the root.

Why it teaches Web3

Merkle trees enable light clients—you can verify a transaction is in a block by downloading only ~10 hashes instead of millions of transactions. This is how mobile wallets work. Understanding Merkle proofs means understanding how trustless verification is even possible.

Core challenges you’ll face

  • Tree construction (handling odd number of leaves, recursive hashing) → maps to data structure design
  • Proof generation (collecting sibling hashes along the path) → maps to algorithmic thinking
  • Proof verification (reconstructing root from leaf + proof) → maps to verification logic
  • Sparse Merkle trees (efficient representation of mostly-empty trees) → maps to Ethereum state

Key Concepts

  • Merkle Trees in Bitcoin: “Mastering Bitcoin” Chapter 9 - Andreas Antonopoulos
  • Tree Data Structures: “Algorithms, Fourth Edition” Chapter 3 - Sedgewick & Wayne
  • Merkle Proofs: Bitcoin Wiki - Merkle Trees

Difficulty

Intermediate

Time estimate

1 week

Prerequisites

Project 1 (hash functions), tree data structures

Real world outcome

$ ./merkle build --data transactions.json
Leaves: [tx1_hash, tx2_hash, tx3_hash, tx4_hash]

Tree Structure:
       [ROOT: 3a7f...]
          /        \
    [ab12...]    [cd34...]
      /  \          /  \
  [tx1] [tx2]   [tx3] [tx4]

Merkle Root: 3a7f8b2c...

$ ./merkle prove --index 2 --root 3a7f8b2c...
Proof for tx3:
  - Sibling[0]: cd34... (right)
  - Sibling[1]: ab12... (left)

$ ./merkle verify --leaf tx3_hash --proof proof.json --root 3a7f8b2c...
✓ Proof VALID - tx3 is in tree with root 3a7f8b2c...

Implementation Hints

Build bottom-up: hash pairs of nodes to create parent level. Handle odd counts by duplicating the last node. For proofs, track whether each sibling is left or right.

Pseudo-code:

function build_tree(leaves):
    current_level = [hash(leaf) for leaf in leaves]
    tree = [current_level]

    while len(current_level) > 1:
        next_level = []
        for i in 0..len(current_level) step 2:
            left = current_level[i]
            right = current_level[i+1] if i+1 < len else left
            next_level.append(hash(left + right))
        tree.append(next_level)
        current_level = next_level

    return tree

function generate_proof(tree, index):
    proof = []
    for level in tree[:-1]:  // exclude root
        sibling_index = index ^ 1  // flip last bit
        is_left = index % 2 == 1
        proof.append({hash: level[sibling_index], is_left: is_left})
        index = index // 2
    return proof

Learning milestones

  1. Tree construction matches known test vectors → You understand the algorithm
  2. Proofs verify correctly → You understand trustless verification
  3. Changing one leaf changes the root → You understand data integrity
  4. Sparse Merkle tree works → You understand Ethereum’s state model

Project 4: Build a Blockchain from Scratch

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Go
  • Alternative Programming Languages: Rust, Python, TypeScript
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Distributed Systems / Blockchain Core
  • Software or Tool: Mini-Blockchain
  • Main Book: “Mastering Bitcoin” by Andreas M. Antonopoulos

What you’ll build

A complete blockchain with blocks, transactions, chain validation, and a simple P2P network. No smart contracts yet—focus on the core data structure and consensus rules.

Why it teaches Web3

This is the heart of it all. A blockchain is just a linked list of blocks where each block commits to the previous one via hash. But the magic is in the rules: what makes a block valid? How do nodes agree? Building this yourself strips away the mysticism.

Core challenges you’ll face

  • Block structure (header, transactions, hash chaining) → maps to blockchain fundamentals
  • Transaction validation (input/output model, signature verification) → maps to UTXO model
  • Chain selection (longest chain rule) → maps to consensus basics
  • P2P gossip (broadcasting blocks and transactions) → maps to distributed systems

Key Concepts

  • Bitcoin Block Structure: “Mastering Bitcoin” Chapters 6-9 - Andreas Antonopoulos
  • P2P Networking: “Computer Networks” Chapter 2 - Tanenbaum
  • Chain Validation: “The Bitcoin Developer Guide” - bitcoin.org

Difficulty

Advanced

Time estimate

2-3 weeks

Prerequisites

Projects 1-3, network programming basics

Real world outcome

# Terminal 1 - Node A
$ ./minichain --port 3000
[Node A] Genesis block: 0000abc...
[Node A] Listening on :3000

# Terminal 2 - Node B
$ ./minichain --port 3001 --peer localhost:3000
[Node B] Connected to peer localhost:3000
[Node B] Synced chain: height=0, tip=0000abc...

# Terminal 1
$ ./minichain mine --to alice_pubkey
[Node A] Mining block 1...
[Node A] Block found! hash=0000def... nonce=48293
[Node A] Broadcasting to peers...

# Terminal 2
[Node B] Received block 1 from peer
[Node B] Block valid, extending chain
[Node B] New tip: 0000def... height=1

Implementation Hints

Start simple: Block = {index, timestamp, previous_hash, transactions, nonce, hash}. Validate by checking: hash matches contents, previous_hash matches prior block, transactions are valid. For P2P, use simple TCP with JSON messages.

Block structure pseudo-code:

struct Block:
    index: int
    timestamp: int
    previous_hash: bytes[32]
    merkle_root: bytes[32]
    nonce: int
    transactions: []Transaction

struct Transaction:
    inputs: []TxInput    // References to previous outputs
    outputs: []TxOutput  // New outputs being created
    signature: bytes

function validate_block(block, chain):
    // Check proof of work
    if not block.hash.starts_with("0000"):
        return false

    // Check hash correctness
    if hash(block.header) != block.hash:
        return false

    // Check chain linkage
    if block.previous_hash != chain.tip.hash:
        return false

    // Validate all transactions
    for tx in block.transactions:
        if not validate_transaction(tx, chain.utxo_set):
            return false

    return true

Learning milestones

  1. Chain validates correctly → You understand blockchain structure
  2. Two nodes sync → You understand P2P consensus
  3. Invalid blocks are rejected → You understand validation rules
  4. Fork resolution works → You understand longest-chain rule

Project 5: Proof of Work Miner

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: C
  • Alternative Programming Languages: Rust, Go, C++
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Consensus / Mining
  • Software or Tool: PoW Miner
  • Main Book: “Mastering Bitcoin” by Andreas M. Antonopoulos

What you’ll build

A multi-threaded Proof of Work miner that finds valid block hashes by brute-forcing nonces. Include difficulty adjustment and mining pool simulation.

Why it teaches Web3

Proof of Work is the original consensus mechanism. Understanding it means understanding Sybil resistance—why you can’t just spin up 1000 fake nodes and take over the network. The answer: because each “vote” costs real energy/computation.

Core challenges you’ll face

  • Hash grinding (trying billions of nonces efficiently) → maps to computational hardness
  • Difficulty targeting (adjusting to maintain block time) → maps to self-regulating systems
  • Multi-threading (parallel nonce search) → maps to performance optimization
  • Stratum protocol (mining pool communication) → maps to real-world mining

Key Concepts

  • Proof of Work: “Mastering Bitcoin” Chapter 10 - Andreas Antonopoulos
  • Multi-threading in C: “The Linux Programming Interface” Chapter 29 - Michael Kerrisk
  • Difficulty Adjustment: Bitcoin Wiki - Difficulty

Difficulty

Advanced

Time estimate

2 weeks

Prerequisites

Projects 1 & 4, multi-threading experience

Real world outcome

$ ./miner --threads 8 --difficulty 4
[Miner] Target: 0000ffff...
[Miner] Starting 8 threads...
[Thread 0] Searching nonce range 0-1000000...
[Thread 1] Searching nonce range 1000000-2000000...
...
[Thread 3] FOUND! nonce=4829371 hash=0000a3f2...
[Miner] Block mined in 2.3 seconds (1.8 MH/s)

$ ./miner benchmark
Single-threaded: 450 kH/s
8 threads: 3.2 MH/s
Speedup: 7.1x (efficiency: 89%)

Implementation Hints

The inner loop must be blazingly fast—this is one of the few places micro-optimization matters. Use uint32_t arrays, avoid memory allocation in the hot path, and consider SIMD instructions.

Mining loop pseudo-code:

function mine(block_template, difficulty_target):
    nonce = 0

    while true:
        block_template.nonce = nonce
        hash = sha256(sha256(block_template.header))

        if hash < difficulty_target:
            return (nonce, hash)

        nonce += 1

        if nonce % 1000000 == 0:
            print("Hashrate:", nonce / elapsed_time)

Difficulty adjustment:

function adjust_difficulty(last_2016_blocks):
    expected_time = 2016 * 10 * 60  // 2 weeks in seconds
    actual_time = last_block.time - first_block.time

    adjustment = expected_time / actual_time
    // Clamp to 4x max adjustment
    adjustment = clamp(adjustment, 0.25, 4.0)

    new_difficulty = old_difficulty * adjustment
    return new_difficulty

Learning milestones

  1. Find valid hashes at low difficulty → You understand PoW basics
  2. Multi-threading provides near-linear speedup → You understand parallel mining
  3. Difficulty adjustment maintains target block time → You understand self-regulation
  4. Mining pool protocol works → You understand real-world mining

Project 6: HD Wallet (BIP-32/BIP-39)

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Rust
  • Alternative Programming Languages: Go, Python, TypeScript
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 4: Expert
  • Knowledge Area: Cryptography / Key Management
  • Software or Tool: HD Wallet Generator
  • Main Book: “Mastering Bitcoin” by Andreas M. Antonopoulos

What you’ll build

A hierarchical deterministic wallet that generates mnemonic seed phrases (BIP-39), derives child keys (BIP-32), and supports multiple cryptocurrencies from a single seed.

Why it teaches Web3

“Not your keys, not your coins.” Wallets are how you hold and control crypto. Understanding HD wallets means understanding key derivation—how a single 12-word phrase can generate billions of addresses across multiple blockchains, all recoverable.

Core challenges you’ll face

  • Mnemonic encoding (entropy → words → seed) → maps to BIP-39 standard
  • HMAC-SHA512 (deriving child keys) → maps to cryptographic key derivation
  • Hardened vs normal derivation (security tradeoffs) → maps to key hierarchy
  • Path parsing (m/44’/60’/0’/0/0) → maps to BIP-44 standards

Key Concepts

  • HD Wallets: “Mastering Bitcoin” Chapter 5 - Andreas Antonopoulos
  • BIP-32 Specification: BIP-0032
  • BIP-39 Wordlist: BIP-0039
  • Derivation Paths: BIP-44

Difficulty

Expert

Time estimate

2-3 weeks

Prerequisites

Projects 1 & 2, understanding of HMAC

Real world outcome

$ ./hdwallet generate
Mnemonic: abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about

$ ./hdwallet derive --path "m/44'/60'/0'/0/0"
Path: m/44'/60'/0'/0/0 (Ethereum, Account 0, Address 0)
Private Key: 0x1a2b3c4d...
Public Key:  0x04ab12cd...
Address:     0x9858EfFD232B4033E47d90003D41EC34EcaEda94

$ ./hdwallet derive --path "m/44'/0'/0'/0/0"
Path: m/44'/0'/0'/0/0 (Bitcoin, Account 0, Address 0)
Address:     1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2

Implementation Hints

BIP-39: Generate 128-256 bits of entropy, add checksum, convert to word indices. BIP-32: Use HMAC-SHA512 with parent key as key and child index as data.

Pseudo-code for key derivation:

function derive_child(parent_key, parent_chain_code, index):
    if index >= 0x80000000:  // Hardened
        data = 0x00 || parent_private_key || index
    else:  // Normal
        data = parent_public_key || index

    I = HMAC-SHA512(parent_chain_code, data)
    child_key = (I_left + parent_key) mod n
    child_chain_code = I_right

    return (child_key, child_chain_code)

function derive_path(seed, path):
    // path = "m/44'/60'/0'/0/0"
    master_key, master_chain = HMAC-SHA512("Bitcoin seed", seed)

    current = (master_key, master_chain)
    for component in parse_path(path):
        current = derive_child(current, component)

    return current

Learning milestones

  1. Mnemonic generates correct seed → You understand BIP-39
  2. Child derivation matches test vectors → You understand BIP-32
  3. Addresses match other wallets → You’ve achieved compatibility
  4. Recovery from mnemonic works → You understand backup/restore

Project 7: Bitcoin Transaction Parser

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Rust
  • Alternative Programming Languages: C, Go, Python
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Protocols / Bitcoin
  • Software or Tool: Transaction Decoder
  • Main Book: “Mastering Bitcoin” by Andreas M. Antonopoulos

What you’ll build

A parser that decodes raw Bitcoin transactions from hex, displaying inputs, outputs, scripts, witness data, and computing transaction IDs.

Why it teaches Web3

Bitcoin transactions are the original “smart contracts”—Script is a stack-based language that defines spending conditions. Understanding the UTXO model (unspent transaction outputs) is fundamentally different from Ethereum’s account model, and essential for understanding blockchain design tradeoffs.

Core challenges you’ll face

  • Variable-length encoding (CompactSize integers) → maps to binary protocol parsing
  • Script parsing (opcodes, stack operations) → maps to Bitcoin Script
  • Witness data (SegWit transaction format) → maps to protocol upgrades
  • TXID computation (which parts are hashed) → maps to transaction malleability

Key Concepts

  • Transaction Structure: “Mastering Bitcoin” Chapter 6 - Andreas Antonopoulos
  • Bitcoin Script: “Mastering Bitcoin” Chapter 7 - Andreas Antonopoulos
  • SegWit Format: BIP-141

Difficulty

Advanced

Time estimate

2 weeks

Prerequisites

Projects 1-3, binary data parsing

Real world outcome

$ ./txparser decode 0100000001c997a...
Transaction ID: 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

Version: 1
Inputs (1):
  [0] Previous TX: c997a5e56e104102fa209c6a852dd90660a20b2d9c352423edce25857fcd3704
      Output Index: 0
      Script: 473044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794...
      Sequence: 0xffffffff

Outputs (2):
  [0] Value: 0.10000000 BTC
      Script: OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG
      Type: P2PKH
      Address: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa

  [1] Value: 0.89990000 BTC
      Script: OP_HASH160 <scripthash> OP_EQUAL
      Type: P2SH
      Address: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy

Fee: 0.00010000 BTC (10 sat/vbyte)

Implementation Hints

Bitcoin uses little-endian for most integers. CompactSize uses the first byte to indicate length: 0-252 = value, 0xfd = next 2 bytes, 0xfe = next 4 bytes, 0xff = next 8 bytes.

Parsing pseudo-code:

function parse_transaction(raw_bytes):
    reader = ByteReader(raw_bytes)

    version = reader.read_u32_le()

    // Check for SegWit marker
    marker = reader.peek_u8()
    has_witness = (marker == 0x00)
    if has_witness:
        reader.read_u8()  // marker
        reader.read_u8()  // flag

    input_count = reader.read_compact_size()
    inputs = []
    for i in 0..input_count:
        prev_tx = reader.read_bytes(32)
        prev_index = reader.read_u32_le()
        script_len = reader.read_compact_size()
        script = reader.read_bytes(script_len)
        sequence = reader.read_u32_le()
        inputs.append(TxInput{...})

    // Similar for outputs...

    return Transaction{version, inputs, outputs, ...}

Learning milestones

  1. Simple transactions parse correctly → You understand basic structure
  2. Script opcodes decode → You understand Bitcoin Script
  3. SegWit transactions parse → You understand protocol evolution
  4. TXID matches block explorers → You’ve achieved correctness

Project 8: Simple EVM Implementation

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Rust
  • Alternative Programming Languages: Go, C++, TypeScript
  • Coolness Level: Level 5: Pure Magic (Super Cool)
  • Business Potential: 1. The “Resume Gold” (Educational/Personal Brand)
  • Difficulty: Level 5: Master
  • Knowledge Area: Virtual Machines / Ethereum
  • Software or Tool: Mini-EVM
  • Main Book: “Mastering Ethereum” by Andreas M. Antonopoulos & Gavin Wood

What you’ll build

A minimal Ethereum Virtual Machine that can execute EVM bytecode, manage stack/memory/storage, and handle gas accounting. Start with arithmetic opcodes, then add control flow and storage.

Why it teaches Web3

The EVM is the heart of Ethereum. Every smart contract, every DeFi protocol, every NFT—they all run on this stack machine. Understanding EVM bytecode means you can read what contracts actually do, not just what Solidity says they do. This is essential for security auditing.

Core challenges you’ll face

  • Stack machine (push, pop, dup, swap operations) → maps to VM architecture
  • Memory management (expanding, gas cost calculation) → maps to resource accounting
  • Storage (256-bit key-value with gas costs) → maps to state management
  • Control flow (JUMP, JUMPI, JUMPDEST validation) → maps to bytecode execution

Key Concepts

Difficulty

Master

Time estimate

1 month+

Prerequisites

Projects 1-4, VM/interpreter experience helpful

Real world outcome

$ ./mini-evm execute --bytecode "6005600401" --trace
Bytecode: PUSH1 0x05 PUSH1 0x04 ADD

Step 0: PUSH1 0x05
  Stack: [5]
  Gas: 3

Step 1: PUSH1 0x04
  Stack: [5, 4]
  Gas: 6

Step 2: ADD
  Stack: [9]
  Gas: 9

Execution complete.
Result: 0x09
Total gas used: 9

$ ./mini-evm execute --bytecode "608060405234801..." --input "0xa9059cbb..."
Executing ERC-20 transfer...
SLOAD key=0x0...1 -> 1000
SUB: 1000 - 100 = 900
SSTORE key=0x0...1 <- 900
...
Return: 0x01 (success)

Implementation Hints

Start with the simplest opcodes: PUSH1-PUSH32, POP, ADD, SUB, MUL, DIV. Then add DUP1-DUP16, SWAP1-SWAP16. Then control flow: JUMP, JUMPI, PC, JUMPDEST. Finally storage: SLOAD, SSTORE.

Core EVM structure:

struct EVM:
    stack: array[256] of uint256  // Max 1024 depth
    memory: dynamic byte array
    storage: map[uint256 -> uint256]
    pc: int  // Program counter
    gas: int
    code: bytes

function execute(evm):
    while evm.pc < len(evm.code):
        opcode = evm.code[evm.pc]

        match opcode:
            0x01 (ADD):
                a = evm.stack.pop()
                b = evm.stack.pop()
                evm.stack.push(a + b)
                evm.gas -= 3

            0x55 (SSTORE):
                key = evm.stack.pop()
                value = evm.stack.pop()
                old = evm.storage.get(key)
                evm.storage.set(key, value)
                // Gas: 20000 if 0->non0, 5000 otherwise

            0x56 (JUMP):
                dest = evm.stack.pop()
                if evm.code[dest] != 0x5b:  // JUMPDEST
                    revert("invalid jump")
                evm.pc = dest
                continue

        evm.pc += 1 + opcode_immediate_size(opcode)

Learning milestones

  1. Arithmetic opcodes work → You understand stack machines
  2. Control flow works → You understand bytecode execution
  3. Storage persists across calls → You understand state
  4. Gas accounting matches geth → You understand resource metering

Project 9: ERC-20 Token from Scratch

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Solidity
  • Alternative Programming Languages: Vyper, Huff (for assembly-level)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Smart Contracts / Token Standards
  • Software or Tool: ERC-20 Token
  • Main Book: “Mastering Ethereum” by Andreas M. Antonopoulos & Gavin Wood

What you’ll build

A complete ERC-20 token implementation with transfer, approve, transferFrom, and events. Deploy to testnet and interact via web3.

Why it teaches Web3

ERC-20 is the standard that made the 2017 ICO boom possible. Understanding it means understanding composability—how contracts interact through standard interfaces. Every DEX, lending protocol, and yield farm builds on ERC-20.

Core challenges you’ll face

  • Balance tracking (mapping of addresses to amounts) → maps to state management
  • Allowance mechanism (approve/transferFrom pattern) → maps to delegation
  • Event emission (Transfer, Approval events) → maps to off-chain indexing
  • Integer overflow (SafeMath or Solidity 0.8+) → maps to security

Key Concepts

Difficulty

Intermediate

Time estimate

1 week

Prerequisites

Basic Solidity, Projects 1-3 conceptually

Real world outcome

$ forge create MyToken --constructor-args "MyToken" "MTK" 1000000
Deployed to: 0x1234...

$ cast call 0x1234... "balanceOf(address)" 0xYourAddress
1000000000000000000000000  // 1M tokens with 18 decimals

$ cast send 0x1234... "transfer(address,uint256)" 0xAlice 1000000000000000000
Transaction: 0xabc...

$ cast call 0x1234... "balanceOf(address)" 0xAlice
1000000000000000000  // Alice has 1 token

Implementation Hints

The core is just two mappings: balances and allowances. The tricky part is getting the semantics exactly right.

Pseudo-Solidity:

contract ERC20 {
    mapping(address => uint256) private _balances;
    mapping(address => mapping(address => uint256)) private _allowances;
    uint256 private _totalSupply;

    function transfer(address to, uint256 amount) public returns (bool) {
        require(_balances[msg.sender] >= amount, "insufficient");
        _balances[msg.sender] -= amount;
        _balances[to] += amount;
        emit Transfer(msg.sender, to, amount);
        return true;
    }

    function approve(address spender, uint256 amount) public returns (bool) {
        _allowances[msg.sender][spender] = amount;
        emit Approval(msg.sender, spender, amount);
        return true;
    }

    function transferFrom(address from, address to, uint256 amount) public returns (bool) {
        require(_allowances[from][msg.sender] >= amount, "allowance");
        require(_balances[from] >= amount, "balance");

        _allowances[from][msg.sender] -= amount;
        _balances[from] -= amount;
        _balances[to] += amount;
        emit Transfer(from, to, amount);
        return true;
    }
}

Learning milestones

  1. Transfers work → You understand token basics
  2. Approve/transferFrom works → You understand delegation
  3. Events emit correctly → You understand off-chain integration
  4. Edge cases handled → You understand security

Project 10: Automated Market Maker (AMM/DEX)

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Solidity
  • Alternative Programming Languages: Vyper, Rust (for Solana)
  • Coolness Level: Level 5: Pure Magic (Super Cool)
  • Business Potential: 5. The “Industry Disruptor”
  • Difficulty: Level 4: Expert
  • Knowledge Area: DeFi / Market Making
  • Software or Tool: Uniswap V2 Clone
  • Main Book: “Mastering Ethereum” by Andreas M. Antonopoulos & Gavin Wood

What you’ll build

A constant-product AMM (x*y=k) similar to Uniswap V2. Users can add liquidity, swap tokens, and earn fees from trades.

Why it teaches Web3

AMMs revolutionized DeFi by eliminating order books. Understanding x*y=k means understanding algorithmic price discovery—how math can replace market makers. This is the foundation of DeFi.

Core challenges you’ll face

  • Constant product formula (maintaining xy=k after swaps) → maps to *pricing math
  • Liquidity provision (minting/burning LP tokens) → maps to share accounting
  • Slippage calculation (price impact of large trades) → maps to market dynamics
  • Flash swap attacks (reentrancy protection) → maps to DeFi security

Key Concepts

Difficulty

Expert

Time estimate

2-3 weeks

Prerequisites

Project 9, understanding of ERC-20

Real world outcome

# Add liquidity
$ cast send $POOL "addLiquidity(uint256,uint256)" 1000e18 2000e18
# You now own LP tokens representing your share

# Swap tokens
$ cast send $POOL "swap(address,uint256)" $TOKEN_A 100e18
# Received ~196 TOKEN_B (with slippage)

# Check reserves
$ cast call $POOL "getReserves()"
# Returns: 1100e18, 1804e18 (x*y ≈ k)

Implementation Hints

The math is deceptively simple but the edge cases are tricky. The key insight: if reserves are (x, y) and someone swaps dx of token X, they receive dy where:

(x + dx) * (y - dy) = x * y

Solving for dy: dy = y * dx / (x + dx)

Pseudo-Solidity:

contract AMM {
    uint256 public reserve0;
    uint256 public reserve1;
    uint256 public totalSupply;  // LP tokens

    function addLiquidity(uint256 amount0, uint256 amount1) external returns (uint256 liquidity) {
        // Transfer tokens in
        token0.transferFrom(msg.sender, address(this), amount0);
        token1.transferFrom(msg.sender, address(this), amount1);

        if (totalSupply == 0) {
            liquidity = sqrt(amount0 * amount1);
        } else {
            liquidity = min(
                amount0 * totalSupply / reserve0,
                amount1 * totalSupply / reserve1
            );
        }

        _mint(msg.sender, liquidity);
        reserve0 += amount0;
        reserve1 += amount1;
    }

    function swap(address tokenIn, uint256 amountIn) external returns (uint256 amountOut) {
        bool isToken0 = tokenIn == address(token0);
        (uint256 resIn, uint256 resOut) = isToken0
            ? (reserve0, reserve1)
            : (reserve1, reserve0);

        // 0.3% fee
        uint256 amountInWithFee = amountIn * 997;
        amountOut = (amountInWithFee * resOut) / (resIn * 1000 + amountInWithFee);

        // Transfer and update reserves
        // ... (with reentrancy protection!)
    }
}

Learning milestones

  1. Basic swaps maintain k → You understand the math
  2. LP tokens track ownership correctly → You understand shares
  3. Fees accumulate for LPs → You understand incentives
  4. Flash loan attacks fail → You understand security

Project 11: NFT Marketplace

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Solidity + TypeScript
  • Alternative Programming Languages: Vyper + Python, Rust (Solana)
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: NFTs / Marketplaces
  • Software or Tool: OpenSea Clone
  • Main Book: “Mastering Ethereum” by Andreas M. Antonopoulos & Gavin Wood

What you’ll build

A complete NFT marketplace with listing, buying, offers, auctions, and royalty distribution. Includes ERC-721 token implementation and frontend.

Why it teaches Web3

NFTs represent digital ownership—not just JPEGs, but any unique digital asset. Understanding ERC-721 and marketplace mechanics means understanding how ownership, transfers, and commerce work on-chain.

Core challenges you’ll face

  • ERC-721 implementation (ownerOf, transferFrom, safeTransferFrom) → maps to token standards
  • Listing/offer mechanics (escrow vs approval pattern) → maps to marketplace design
  • Auction logic (English, Dutch, reserve prices) → maps to game theory
  • Royalty distribution (ERC-2981 standard) → maps to creator economics

Key Concepts

Difficulty

Advanced

Time estimate

2-3 weeks

Prerequisites

Project 9, basic frontend knowledge

Real world outcome

Web interface showing:
- Browse NFT collections
- List your NFT for sale (fixed price or auction)
- Make offers on NFTs
- Buy NFTs instantly
- View transaction history
- Royalties automatically distributed to creators

Implementation Hints

The marketplace contract holds listings as a mapping. When someone buys, it orchestrates the transfer: ETH goes to seller (minus fees/royalties), NFT goes to buyer.

Pseudo-Solidity:

struct Listing {
    address seller;
    address nftContract;
    uint256 tokenId;
    uint256 price;
    bool active;
}

mapping(bytes32 => Listing) public listings;

function listNFT(address nft, uint256 tokenId, uint256 price) external {
    require(IERC721(nft).ownerOf(tokenId) == msg.sender);
    require(IERC721(nft).isApprovedForAll(msg.sender, address(this)));

    bytes32 listingId = keccak256(abi.encodePacked(nft, tokenId));
    listings[listingId] = Listing(msg.sender, nft, tokenId, price, true);
}

function buyNFT(bytes32 listingId) external payable {
    Listing memory listing = listings[listingId];
    require(listing.active && msg.value >= listing.price);

    listings[listingId].active = false;

    // Handle royalties (ERC-2981)
    (address royaltyReceiver, uint256 royaltyAmount) =
        IERC2981(listing.nftContract).royaltyInfo(listing.tokenId, listing.price);

    // Transfer NFT
    IERC721(listing.nftContract).safeTransferFrom(
        listing.seller, msg.sender, listing.tokenId
    );

    // Distribute payments
    payable(royaltyReceiver).transfer(royaltyAmount);
    payable(listing.seller).transfer(listing.price - royaltyAmount);
}

Learning milestones

  1. NFT minting and transfers work → You understand ERC-721
  2. Listings and purchases work → You understand marketplace mechanics
  3. Royalties distribute correctly → You understand creator economics
  4. Frontend displays NFT metadata → You understand the full stack

Project 12: DAO Governance System

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Solidity
  • Alternative Programming Languages: Vyper, Rust (Solana)
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Governance / DAOs
  • Software or Tool: Governor Contract
  • Main Book: “Mastering Ethereum” by Andreas M. Antonopoulos & Gavin Wood

What you’ll build

A complete governance system: proposal creation, voting (with delegation), timelock, and execution. Similar to Compound Governor or OpenZeppelin Governor.

Why it teaches Web3

DAOs represent decentralized governance—organizations run by code and token holders, not executives. Understanding governance means understanding how collective decisions can be made trustlessly, and the game theory involved.

Core challenges you’ll face

  • Vote weighting (token-weighted vs quadratic voting) → maps to voting mechanisms
  • Vote delegation (liquid democracy) → maps to governance efficiency
  • Timelock (delay between passing and execution) → maps to security
  • Quorum and thresholds (when is a vote valid?) → maps to game theory

Key Concepts

Difficulty

Advanced

Time estimate

2 weeks

Prerequisites

Project 9, understanding of proxies

Real world outcome

# Create proposal
$ cast send $GOVERNOR "propose(address[],uint256[],bytes[],string)" \
    "[0xTreasury]" "[0]" "[(transfer(address,uint256), 0xRecipient, 1000e18)]" \
    "Transfer 1000 tokens to community fund"
Proposal ID: 1

# Vote
$ cast send $GOVERNOR "castVote(uint256,uint8)" 1 1  # 1 = For
Vote cast: 10000 votes FOR

# After voting period + timelock
$ cast send $GOVERNOR "execute(uint256)" 1
Proposal executed!

Implementation Hints

The governor tracks proposals, vote counts, and proposal states. Use block numbers for timing (more reliable than timestamps). ERC20Votes provides vote checkpoints.

Pseudo-Solidity:

enum ProposalState { Pending, Active, Defeated, Succeeded, Queued, Executed }

struct Proposal {
    address proposer;
    uint256 startBlock;
    uint256 endBlock;
    uint256 forVotes;
    uint256 againstVotes;
    mapping(address => bool) hasVoted;
    // Execution data...
}

function propose(...) external returns (uint256) {
    require(getVotes(msg.sender) >= proposalThreshold);
    // Create proposal...
}

function castVote(uint256 proposalId, uint8 support) external {
    Proposal storage p = proposals[proposalId];
    require(state(proposalId) == ProposalState.Active);
    require(!p.hasVoted[msg.sender]);

    uint256 votes = getVotes(msg.sender, p.startBlock);  // Snapshot!

    if (support == 1) p.forVotes += votes;
    else p.againstVotes += votes;

    p.hasVoted[msg.sender] = true;
}

function execute(uint256 proposalId) external {
    require(state(proposalId) == ProposalState.Succeeded);
    // Execute via timelock...
}

Learning milestones

  1. Proposals can be created and voted on → You understand basic governance
  2. Vote snapshots prevent double-voting → You understand security
  3. Timelock adds execution delay → You understand operational security
  4. Delegation works → You understand liquid democracy

Project 13: Layer 2 Optimistic Rollup (Simplified)

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Rust + Solidity
  • Alternative Programming Languages: Go + Solidity
  • Coolness Level: Level 5: Pure Magic (Super Cool)
  • Business Potential: 5. The “Industry Disruptor”
  • Difficulty: Level 5: Master
  • Knowledge Area: Scaling / Layer 2
  • Software or Tool: Mini-Rollup
  • Main Book: “Mastering Ethereum” by Andreas M. Antonopoulos & Gavin Wood

What you’ll build

A simplified optimistic rollup: off-chain execution, batch transaction submission to L1, fraud proof mechanism, and deposit/withdrawal bridges.

Why it teaches Web3

Layer 2 is how Ethereum scales. Understanding rollups means understanding the fundamental tradeoff: execute off-chain for speed, but inherit L1 security through fraud proofs or validity proofs. This is the future of blockchain scaling.

Core challenges you’ll face

  • State commitment (posting state roots to L1) → maps to data availability
  • Fraud proofs (proving invalid state transitions) → maps to game theory
  • Deposit/withdrawal bridge (moving assets between layers) → maps to bridges
  • Sequencer role (ordering transactions) → maps to decentralization tradeoffs

Key Concepts

Difficulty

Master

Time estimate

1-2 months

Prerequisites

Projects 4, 8, deep Ethereum knowledge

Real world outcome

# L2 Sequencer
$ ./rollup-node --sequencer --l1-rpc http://localhost:8545
[Sequencer] Watching L1 for deposits...
[Sequencer] Processing L2 transactions...
[Sequencer] Batch ready: 100 txs, submitting to L1...
[Sequencer] State root posted: 0xabc...

# L2 User
$ cast send --rpc-url http://localhost:8546 $L2_RECIPIENT --value 1ether
[L2] Transaction confirmed in 200ms

# Bridge deposit (L1 -> L2)
$ cast send $BRIDGE "deposit()" --value 1ether
[L1] Deposit event emitted
[L2] Deposit credited after 10 L1 blocks

# Bridge withdrawal (L2 -> L1)
$ cast send --rpc-url http://localhost:8546 $BRIDGE "withdraw(uint256)" 1ether
[L2] Withdrawal initiated
[L1] 7-day challenge period started...
[L1] Withdrawal finalized

Implementation Hints

Start with the simplest possible rollup: a sequencer that batches transactions and posts state roots. The fraud proof is the hard part—you need to prove invalid state transitions in a single L1 transaction.

Architecture overview:

L1 Contract (Ethereum):
  - Accepts deposits (ETH locked, credit on L2)
  - Accepts state root submissions from sequencer
  - Handles fraud proofs (challenge period)
  - Processes withdrawals (after challenge period)

L2 Node (Off-chain):
  - Maintains L2 state (accounts, balances)
  - Executes transactions
  - Batches transactions
  - Submits state roots to L1
  - Watches for fraud proof challenges

Fraud Proof (simplified):
  1. Challenger claims state transition is invalid
  2. Sequencer must prove transition was valid
  3. If sequencer can't prove it, state is reverted
  4. If challenger was wrong, they lose bond

Learning milestones

  1. Deposits credit on L2 → You understand bridging
  2. Batches submit to L1 → You understand rollup mechanics
  3. Fraud proofs can revert state → You understand security model
  4. Withdrawals complete → You understand the full cycle

Project 14: Smart Contract Security Scanner

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Python
  • Alternative Programming Languages: Rust, TypeScript
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 4: Expert
  • Knowledge Area: Security / Auditing
  • Software or Tool: Static Analyzer
  • Main Book: “Mastering Ethereum” by Andreas M. Antonopoulos & Gavin Wood

What you’ll build

A static analysis tool that scans Solidity contracts for common vulnerabilities: reentrancy, integer overflow, access control issues, unchecked returns, and more.

Why it teaches Web3

Security is paramount in Web3—there’s no “customer support” to reverse hacks. In 2024, over $1.4 billion was lost to smart contract exploits. Understanding vulnerabilities at a tool-building level means you truly understand attack vectors.

Core challenges you’ll face

  • AST parsing (understanding Solidity syntax tree) → maps to static analysis
  • Control flow analysis (tracing execution paths) → maps to vulnerability patterns
  • Pattern matching (detecting known bad patterns) → maps to security heuristics
  • False positive reduction (not crying wolf) → maps to practical tooling

Key Concepts

Difficulty

Expert

Time estimate

3-4 weeks

Prerequisites

Projects 8 & 9, compiler/parser experience helpful

Real world outcome

$ ./scanner analyze VulnerableContract.sol

=== Security Scan Results ===

HIGH: Reentrancy vulnerability
  Location: withdraw() at line 45
  Pattern: State change after external call
  Fix: Move state change before call or use ReentrancyGuard

HIGH: Unchecked low-level call
  Location: line 78
  Pattern: call() return value not checked
  Fix: require(success, "call failed")

MEDIUM: Floating pragma
  Location: line 1
  Pattern: pragma solidity ^0.8.0
  Fix: Lock to specific version: pragma solidity 0.8.19

LOW: Missing zero-address check
  Location: setOwner() at line 23
  Fix: require(newOwner != address(0))

Summary: 2 HIGH, 1 MEDIUM, 1 LOW

Implementation Hints

Use solc to generate the AST (Abstract Syntax Tree). Then traverse the tree looking for patterns. For reentrancy, look for external calls followed by state changes.

Pseudo-code:

def check_reentrancy(function_ast):
    external_calls = find_external_calls(function_ast)
    state_changes = find_state_changes(function_ast)

    for call in external_calls:
        for change in state_changes:
            if change.position > call.position:
                report_vulnerability(
                    type="reentrancy",
                    severity="HIGH",
                    location=call.position,
                    message="State change after external call"
                )

def find_external_calls(ast):
    # Look for: call, delegatecall, transfer, send
    # And external function calls
    pass

def find_state_changes(ast):
    # Look for: assignments to state variables
    # Including via SSTORE in assembly
    pass

Learning milestones

  1. Parse Solidity AST → You understand compiler output
  2. Detect reentrancy pattern → You understand the #1 vulnerability
  3. Low false positive rate → You understand practical tooling
  4. Find real bugs in production contracts → You can do security research

Project 15: Decentralized Storage Client (IPFS-like)

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Go
  • Alternative Programming Languages: Rust, TypeScript
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 4: Expert
  • Knowledge Area: Distributed Systems / Storage
  • Software or Tool: Content-Addressed Storage
  • Main Book: “Designing Data-Intensive Applications” by Martin Kleppmann

What you’ll build

A content-addressed storage system with chunking, Merkle DAG construction, content discovery via DHT, and peer-to-peer file transfer.

Why it teaches Web3

Blockchain stores code and state, but not files. IPFS and similar systems provide the data layer for Web3. Understanding content-addressing means understanding how you can verify data integrity without trusting the source.

Core challenges you’ll face

  • Content addressing (CID = hash of content) → maps to immutability
  • Chunking and DAG (splitting files, linking chunks) → maps to data structures
  • DHT routing (finding who has the content) → maps to distributed systems
  • BitSwap (incentivized peer transfer) → maps to protocol design

Key Concepts

  • Content Addressing: “The content’s hash IS its address”
  • Merkle DAGs: IPFS Concepts
  • Kademlia DHT: “Designing Data-Intensive Applications” Chapter 6 - Martin Kleppmann
  • P2P Networks: “Computer Networks” Chapter 2 - Tanenbaum

Difficulty

Expert

Time estimate

3-4 weeks

Prerequisites

Projects 3 & 4, P2P networking experience

Real world outcome

# Add file
$ ./ipfs-lite add myfile.pdf
Added: QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG
File split into 4 chunks, linked via Merkle DAG

# Get file (from any peer that has it)
$ ./ipfs-lite get QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG
Searching DHT for providers...
Found 3 peers with content
Downloading from best peer...
myfile.pdf (1.2 MB) downloaded

# Pin (keep permanently)
$ ./ipfs-lite pin QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG
Pinned: content will be preserved

Implementation Hints

Start with content addressing: hash files to get CID. Then chunking: split large files into 256KB chunks. Then DAG: create a root node that links to chunks. Finally DHT: find peers who have the content.

Architecture:

Content Identifier (CID):
  - Version (1)
  - Codec (raw, dag-pb, etc.)
  - Multihash of content

Merkle DAG (for large files):
  root_node = {
    type: "directory",
    links: [
      {name: "chunk-0", cid: "Qm...", size: 262144},
      {name: "chunk-1", cid: "Qm...", size: 262144},
      ...
    ]
  }

  CID(file) = hash(root_node)

DHT Lookup:
  1. Hash CID to get DHT key
  2. Find k-closest nodes to key
  3. Ask each node for providers
  4. Connect to provider, request blocks

Learning milestones

  1. Content addressing works → You understand immutability
  2. Large files chunk correctly → You understand data structures
  3. DHT finds providers → You understand distributed lookup
  4. Multi-peer download works → You understand P2P protocols

Project 16: Multi-Signature Wallet

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Solidity
  • Alternative Programming Languages: Vyper
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Security / Wallet Design
  • Software or Tool: Gnosis Safe Clone
  • Main Book: “Mastering Ethereum” by Andreas M. Antonopoulos & Gavin Wood

What you’ll build

A multi-signature wallet requiring M-of-N signatures to execute transactions. Support for adding/removing owners, changing threshold, and batch transactions.

Why it teaches Web3

Multi-sig is how serious projects protect their treasuries. Understanding it means understanding social key recovery, operational security, and how to design systems that don’t have single points of failure.

Core challenges you’ll face

  • Signature verification (recovering signer from ECDSA signature) → maps to cryptography
  • Nonce management (preventing replay attacks) → maps to security
  • Owner management (adding/removing signers) → maps to governance
  • Gas estimation (estimating execution cost) → maps to UX

Key Concepts

Difficulty

Advanced

Time estimate

2 weeks

Prerequisites

Project 9, understanding of signatures

Real world outcome

# Deploy 2-of-3 multisig
$ forge create MultiSig --constructor-args "[0xAlice,0xBob,0xCharlie]" 2

# Alice proposes transfer
$ cast send $MULTISIG "submitTransaction(address,uint256,bytes)" \
    0xRecipient 1ether 0x
Transaction ID: 0

# Bob confirms
$ cast send $MULTISIG "confirmTransaction(uint256)" 0 --from bob
Confirmations: 2/2 ✓

# Execute (anyone can call after threshold reached)
$ cast send $MULTISIG "executeTransaction(uint256)" 0
Transaction executed!

Implementation Hints

Store pending transactions in a mapping. Track confirmations per transaction. Only execute when confirmations >= threshold.

Pseudo-Solidity:

struct Transaction {
    address to;
    uint256 value;
    bytes data;
    bool executed;
    uint256 confirmations;
}

mapping(uint256 => Transaction) public transactions;
mapping(uint256 => mapping(address => bool)) public isConfirmed;

function confirmTransaction(uint256 txId) public onlyOwner {
    require(!isConfirmed[txId][msg.sender], "already confirmed");

    isConfirmed[txId][msg.sender] = true;
    transactions[txId].confirmations += 1;

    if (transactions[txId].confirmations >= threshold) {
        executeTransaction(txId);
    }
}

function executeTransaction(uint256 txId) public {
    Transaction storage tx = transactions[txId];
    require(tx.confirmations >= threshold, "not enough confirmations");
    require(!tx.executed, "already executed");

    tx.executed = true;
    (bool success,) = tx.to.call{value: tx.value}(tx.data);
    require(success, "execution failed");
}

Learning milestones

  1. Basic multi-sig works → You understand the pattern
  2. Owner management works → You understand governance
  3. EIP-712 signatures work → You understand off-chain signing
  4. Edge cases handled → You understand security

Project 17: Flash Loan Implementation

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Solidity
  • Alternative Programming Languages: Vyper
  • Coolness Level: Level 5: Pure Magic (Super Cool)
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 4: Expert
  • Knowledge Area: DeFi / Flash Loans
  • Software or Tool: Flash Loan Pool
  • Main Book: “Mastering Ethereum” by Andreas M. Antonopoulos & Gavin Wood

What you’ll build

A flash loan pool that allows borrowing unlimited funds with zero collateral—as long as you repay within the same transaction. Implement both the lending pool and example arbitrage bot.

Why it teaches Web3

Flash loans are DeFi’s secret weapon—they enable capital-efficient arbitrage, liquidations, and collateral swaps. They also power many attacks. Understanding them means understanding atomic transactions and capital efficiency.

Core challenges you’ll face

  • Atomic execution (borrow + use + repay in one tx) → maps to transaction atomicity
  • Callback pattern (pool calls borrower, borrower does stuff) → maps to contract interaction
  • Fee collection (taking a cut of borrowed amount) → maps to protocol revenue
  • Security (preventing reentrancy, ensuring repayment) → maps to attack prevention

Key Concepts

Difficulty

Expert

Time estimate

1-2 weeks

Prerequisites

Projects 9 & 10

Real world outcome

# Deploy flash loan pool with 1000 ETH
$ forge create FlashLoanPool --value 1000ether

# Deploy arbitrage bot
$ forge create ArbitrageBot

# Execute arbitrage (borrow 100 ETH, arb, repay 100.09 ETH)
$ cast send $BOT "executeArbitrage(uint256)" 100ether
[FlashLoanPool] Loaned 100 ETH to ArbitrageBot
[ArbitrageBot] Bought TOKEN on DEX_A for 100 ETH
[ArbitrageBot] Sold TOKEN on DEX_B for 102 ETH
[ArbitrageBot] Repaying 100.09 ETH (0.09% fee)
[FlashLoanPool] Loan repaid ✓

Profit: 1.91 ETH (net of fees)

Implementation Hints

The key insight: use a callback pattern. The pool transfers funds, then calls a function on the borrower, then verifies repayment. If repayment fails, the whole transaction reverts.

Pseudo-Solidity:

// Flash Loan Pool
function flashLoan(uint256 amount, bytes calldata data) external {
    uint256 balanceBefore = address(this).balance;
    uint256 fee = amount * 9 / 10000;  // 0.09% fee

    // Send funds to borrower
    (bool sent,) = msg.sender.call{value: amount}("");
    require(sent, "transfer failed");

    // Call borrower's callback
    IFlashBorrower(msg.sender).executeOperation(amount, fee, data);

    // Verify repayment
    require(
        address(this).balance >= balanceBefore + fee,
        "flash loan not repaid"
    );
}

// Borrower Contract
contract ArbitrageBot is IFlashBorrower {
    function executeOperation(
        uint256 amount,
        uint256 fee,
        bytes calldata data
    ) external {
        // Do arbitrage with `amount` ETH
        // ...

        // Repay loan + fee
        payable(msg.sender).transfer(amount + fee);
    }
}

Learning milestones

  1. Basic flash loan works → You understand atomicity
  2. Arbitrage bot profits → You understand capital efficiency
  3. Failed arbitrage reverts cleanly → You understand transaction safety
  4. Multi-asset flash loans work → You understand complex DeFi

Project 18: Block Explorer

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: TypeScript
  • Alternative Programming Languages: Python, Go
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Infrastructure / Data
  • Software or Tool: Etherscan Clone
  • Main Book: “Mastering Ethereum” by Andreas M. Antonopoulos & Gavin Wood

What you’ll build

A block explorer that indexes blockchain data, displays transactions, decodes contract calls, and shows token transfers. Like a mini Etherscan.

Why it teaches Web3

Block explorers are how users verify on-chain activity. Building one means understanding how to read the blockchain—decoding transactions, interpreting events, and presenting on-chain data.

Core challenges you’ll face

  • Chain indexing (syncing and storing block data) → maps to data pipelines
  • Transaction decoding (ABI interpretation) → maps to contract interfaces
  • Event parsing (extracting Transfer, Swap events) → maps to off-chain integration
  • Search (finding transactions by hash, address) → maps to database design

Key Concepts

Difficulty

Intermediate

Time estimate

2-3 weeks

Prerequisites

Project 9, basic web development

Real world outcome

Web interface showing:
- Latest blocks with gas used, transaction count
- Block details: hash, parent, timestamp, miner, transactions
- Transaction details: from, to, value, gas, decoded input
- Address pages: balance, token holdings, transaction history
- Token transfers: decoded ERC-20/721 events
- Contract verification: source code, ABI

Implementation Hints

Use ethers.js or web3.py to fetch data via JSON-RPC. Store in PostgreSQL for querying. Decode function calls using ABI.

Architecture:

Indexer (background process):
  1. Connect to Ethereum node (Infura, Alchemy, local)
  2. For each new block:
     - Store block metadata
     - For each transaction:
       - Store tx data
       - Decode function call (if known ABI)
       - Parse events (Transfer, Approval, etc.)
       - Track token balances
  3. Index for fast search

API Layer:
  GET /block/:number
  GET /tx/:hash
  GET /address/:address
  GET /address/:address/transactions
  GET /address/:address/tokens

Frontend:
  - React/Vue app consuming API
  - Real-time updates via WebSocket

Learning milestones

  1. Blocks and transactions display → You understand chain data
  2. Function calls decode correctly → You understand ABI encoding
  3. Token transfers tracked → You understand events
  4. Search works → You understand blockchain indexing

Final Comprehensive Project: Build a Full Ethereum Client

  • File: WEB3_DEEP_UNDERSTANDING_PROJECTS.md
  • Main Programming Language: Rust
  • Alternative Programming Languages: Go, C++
  • Coolness Level: Level 5: Pure Magic (Super Cool)
  • Business Potential: 5. The “Industry Disruptor”
  • Difficulty: Level 5: Master
  • Knowledge Area: Protocol Implementation
  • Software or Tool: Mini-Geth
  • Main Book: “Mastering Ethereum” by Andreas M. Antonopoulos & Gavin Wood

What you’ll build

A minimal but functional Ethereum client: P2P networking (devp2p), chain sync, state management (Patricia Merkle Trie), EVM execution, and JSON-RPC API.

Why it teaches Web3

This is the ultimate test of Web3 understanding. An Ethereum client is where everything comes together: cryptography, networking, consensus, state, execution. If you can build this, you truly understand how Ethereum works at every level.

Core challenges you’ll face

  • DevP2P protocol (node discovery, RLPx encryption) → maps to P2P networking
  • Chain sync (snap sync, state healing) → maps to distributed systems
  • Patricia Merkle Trie (state storage, proofs) → maps to data structures
  • EVM execution (full opcode support) → maps to virtual machines
  • Consensus (block validation, fork choice) → maps to protocol rules

Key Concepts

Difficulty

Master (6+ months for full implementation)

Time estimate

3-6 months (or more)

Prerequisites

All previous projects, deep systems programming experience

Real world outcome

$ ./mini-geth --syncmode snap --rpc
[P2P] Discovering peers...
[P2P] Connected to 25 peers
[Sync] Downloading headers...
[Sync] Block 18,500,000 - syncing state...
[Sync] State sync: 45% (healing 1,234 accounts)
[RPC] JSON-RPC server listening on :8545

# In another terminal
$ cast block-number --rpc-url http://localhost:8545
18500000

$ cast call --rpc-url http://localhost:8545 \
    0xdAC17F958D2ee523a2206206994597C13D831ec7 \
    "balanceOf(address)" 0xF977814e90dA44bFA03b6295A0616a897441aceC
1234567890000000000000

Implementation Hints

This is a massive project. Break it into phases:

Phase 1: Core Infrastructure (1 month)

  • RLP encoding/decoding
  • Keccak-256 hashing
  • ECDSA signatures (secp256k1)
  • Basic P2P (TCP + encryption)

Phase 2: Data Structures (1 month)

  • Patricia Merkle Trie
  • Block/Transaction structures
  • State database (LevelDB)

Phase 3: Sync (1-2 months)

  • Header download
  • Block verification
  • State sync (full or snap)

Phase 4: Execution (1-2 months)

  • Full EVM with all opcodes
  • Precompiled contracts
  • Gas metering

Phase 5: Consensus & RPC (1 month)

  • Block validation
  • Fork choice
  • JSON-RPC API

Learning milestones

  1. Can connect to mainnet peers → You understand P2P
  2. Can sync headers → You understand chain structure
  3. Can execute blocks → You understand EVM
  4. Can serve RPC → You’ve built a working client
  5. Passes Ethereum tests → You’re production-ready

Project Comparison Table

Project Difficulty Time Depth of Understanding Fun Factor
1. SHA-256 Visualizer Intermediate 1-2 weeks ⭐⭐⭐ ⭐⭐⭐
2. ECDSA Implementation Expert 3-4 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐
3. Merkle Tree Library Intermediate 1 week ⭐⭐⭐ ⭐⭐⭐
4. Blockchain from Scratch Advanced 2-3 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
5. PoW Miner Advanced 2 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐
6. HD Wallet Expert 2-3 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐
7. Bitcoin TX Parser Advanced 2 weeks ⭐⭐⭐⭐ ⭐⭐⭐
8. Simple EVM Master 1 month+ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
9. ERC-20 Token Intermediate 1 week ⭐⭐⭐ ⭐⭐⭐
10. AMM/DEX Expert 2-3 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
11. NFT Marketplace Advanced 2-3 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐
12. DAO Governance Advanced 2 weeks ⭐⭐⭐⭐ ⭐⭐⭐
13. L2 Rollup Master 1-2 months ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
14. Security Scanner Expert 3-4 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐
15. IPFS-like Storage Expert 3-4 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐
16. Multi-Sig Wallet Advanced 2 weeks ⭐⭐⭐⭐ ⭐⭐⭐
17. Flash Loans Expert 1-2 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
18. Block Explorer Intermediate 2-3 weeks ⭐⭐⭐ ⭐⭐⭐
Final: Ethereum Client Master 3-6 months ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐

Based on building from fundamentals to advanced, here’s the optimal order:

Phase 1: Cryptographic Foundations (4-6 weeks)

  1. Project 1: SHA-256 Visualizer - Start here. Everything uses hashes.
  2. Project 2: ECDSA Implementation - Understand ownership in Web3.
  3. Project 3: Merkle Tree Library - Understand verification.

Phase 2: Blockchain Core (6-8 weeks)

  1. Project 4: Blockchain from Scratch - The foundation.
  2. Project 5: PoW Miner - Understand consensus.
  3. Project 6: HD Wallet - Understand key management.
  4. Project 7: Bitcoin TX Parser - Understand transactions.

Phase 3: Smart Contracts (4-6 weeks)

  1. Project 9: ERC-20 Token - Your first smart contract.
  2. Project 8: Simple EVM - Understand execution.
  3. Project 16: Multi-Sig Wallet - Advanced patterns.

Phase 4: DeFi & NFTs (6-8 weeks)

  1. Project 10: AMM/DEX - Core DeFi primitive.
  2. Project 17: Flash Loans - DeFi’s unique capability.
  3. Project 11: NFT Marketplace - Digital ownership.

Phase 5: Infrastructure & Security (6-8 weeks)

  1. Project 12: DAO Governance - Decentralized organization.
  2. Project 14: Security Scanner - Become an auditor.
  3. Project 18: Block Explorer - Read the chain.
  4. Project 15: IPFS-like Storage - Data layer.

Phase 6: Advanced (3-6 months)

  1. Project 13: L2 Rollup - Scaling solutions.
  2. Final: Ethereum Client - The ultimate test.

Essential Resources

Books

  • “Mastering Bitcoin” by Andreas Antonopoulos - Bitcoin deep dive
  • “Mastering Ethereum” by Antonopoulos & Wood - Ethereum deep dive
  • “Serious Cryptography” by Jean-Philippe Aumasson - Cryptography foundations
  • “Elliptic Curve Cryptography for Developers” by Michael Rosing - ECC specifics
  • “Designing Data-Intensive Applications” by Martin Kleppmann - Distributed systems

Online Resources

Security

Communities

  • Ethereum Discord
  • Ethereum Research Forum
  • r/ethdev

Summary

# Project Main Language
1 Cryptographic Hash Function Visualizer Rust
2 ECDSA Digital Signature Implementation Rust
3 Merkle Tree Library Go
4 Build a Blockchain from Scratch Go
5 Proof of Work Miner C
6 HD Wallet (BIP-32/BIP-39) Rust
7 Bitcoin Transaction Parser Rust
8 Simple EVM Implementation Rust
9 ERC-20 Token from Scratch Solidity
10 Automated Market Maker (AMM/DEX) Solidity
11 NFT Marketplace Solidity + TypeScript
12 DAO Governance System Solidity
13 Layer 2 Optimistic Rollup Rust + Solidity
14 Smart Contract Security Scanner Python
15 Decentralized Storage Client (IPFS-like) Go
16 Multi-Signature Wallet Solidity
17 Flash Loan Implementation Solidity
18 Block Explorer TypeScript
Final Full Ethereum Client Rust

Happy building! Remember: in Web3, you don’t have to trust—you can verify. And once you’ve built these projects, you’ll know exactly what you’re verifying.