EVM foundation · Complete curriculum
EVM Engineering Bootcamp
Understand how Ethereum works from the inside, then connect it to a working application. This six-week curriculum starts with nodes and EVM execution and builds toward a token-swap app with live transaction monitoring.
You should be comfortable with basic Solidity and writing code. The articles are open to any curious technical reader; this course includes substantial implementation work.
What the course connects
Follow a transaction all the way through.
Read the bytes, understand the execution, and explain the result. Then use that understanding in a system you can interact with.
Understand what the tools are showing you
Read calldata and traces, work with nodes and RPCs, construct and sign transactions, and follow receipts, logs, and confirmations.
Bring it together in a full-stack project
Build an ERC-20 token and a fixed-ratio SimpleSwap contract, a wallet and swap interface, a backend API, and PostgreSQL storage. Track each transaction from pending to confirmed in the activity view.
This first swap project focuses on token approvals and application integration. Building an AMM and its pricing mathematics belongs to the advanced course.
Curriculum map
From protocol mechanics to a working system.
Explore the topics, practical work, and outcomes for each week. The final two weeks come together in one full-stack project.
Week 1Ethereum internals, nodes, and the developer environmentFollow a transaction from a wallet to execution and finality. Build a working mental model of Ethereum before relying on higher-level libraries.
What you’ll explore
Protocol foundations
- Ethereum as a state machine and the role of state transitions.
- Merkle trees and Merkle Patricia tries: organizing state and checking data integrity.
- EOAs, contract accounts, transaction fields, signatures, value transfers, calls, and deployments.
Execution and consensus
- The post-Merge split between the Execution Layer and Consensus Layer.
- Transaction flow through the mempool, execution, and inclusion in a Beacon Block.
- Client pairs, the Engine API, and the responsibilities of each client.
Inside the EVM
- Stack, memory, and storage: what each holds and how their lifetimes differ.
- Gas as payment, spam prevention, and prioritization; what a revert changes.
- ABI encoding, calldata, four-byte function selectors, and padded arguments.
Tools and nodes
- Foundry: forge for builds and tests, cast for RPC interactions, and anvil for a local chain.
- RPC endpoints, full/archive/light node models, and provider selection.
Hands-on work
- Build and verify a Merkle tree in Python.
- Compute ERC-20 selectors and decode sample calldata.
- Query transactions and block headers through an RPC endpoint using curl.
- Install Foundry, run Anvil, compile and deploy a contract, then use cast call and cast send.
- Write a deliberately failing test, inspect its trace, and update a contract and its tests after changing fields or function signatures.
What you’ll take away
- Explain how execution and consensus clients work together.
- Recognize a function and its arguments in raw calldata.
- Choose an appropriate node/RPC setup and work comfortably in a local Foundry environment.
- Use execution traces to explain a failure.
Week 2Smart contract foundations and Solidity-to-EVM translationConnect Solidity, wallet signing, ABI encoding, and low-level execution. Understand how a call reaches the right function and which account, value, and storage context it uses.
What you’ll explore
ABI and calldata
- Function selectors and the ABI encoding specification.
- Static values, dynamic strings and arrays, structs and tuples.
- Head/tail layouts, offsets, padding, and manual decoding.
Calls and execution context
- CALL, DELEGATECALL, and STATICCALL: reasoning about msg.sender, msg.value, storage, and state-writing restrictions.
- Internal jump-based calls versus external ABI-encoded calls.
- payable, receive(), fallback(), state rollback, and bubbling revert data.
Dispatch and serialization
- The runtime dispatcher: extracting a selector and routing execution.
- Compiler-generated non-payable checks and relevant opcodes.
- RLP serialization and its role in transaction delivery.
Wallets and keys
- Private keys, public keys, addresses, EOAs, and contract accounts.
- Wallet/provider responsibilities: connecting, signing, and broadcasting.
- Key custody and safely managing test accounts.
Hands-on work
- Encode and decode custom calls with cast calldata, including structs, offsets, and padded arguments.
- Generate test keys and sign messages with cast wallet.
- Connect a test-only MetaMask account to Anvil using its RPC URL and chain ID.
- Deploy contracts to compare receive(), fallback(), CALL, DELEGATECALL, STATICCALL, and propagated reverts.
- Inspect and disassemble runtime bytecode to locate dispatch and non-payable checks.
What you’ll take away
- Read complex calldata and relate it to the Solidity interface.
- Predict call context and explain why a particular execution path fails.
- Manage test accounts and connect high-level code to ABI, RLP, and EVM opcodes.
Week 3Transaction and message types in the EVMTreat the transaction as a signed protocol object. Understand the bytes being authorized, the fee model being used, and why submission to a node does not mean inclusion in a block.
What you’ll explore
What a wallet signs
- Canonical fields: nonce, destination, value, data, gas limit, fees, and chain ID.
- Nonce ordering and gaps; EIP-155 replay protection.
- Signing preimages versus transaction hashes, and the EIP-55 address checksum.
Transaction types and fees
- EIP-2718 typed envelopes and legacy Type 0 transactions.
- Type 1 access lists under EIP-2930.
- Type 2 transactions under EIP-1559: base fee, priority fee, and maximum fee.
- Fee estimation with eth_feeHistory.
Lifecycle and mempool behavior
- What eth_sendRawTransaction acknowledges and what still remains uncertain.
- Node-local mempools, pending versus queued transactions, and replacement policies.
- Immediate rejection versus an included transaction that reverts.
- Transaction intent versus receipt outcome: status, gas usage, and logs.
Hands-on work
- Construct legacy and EIP-1559 transaction fields manually.
- Compare latest and pending nonce queries.
- Inspect fee fields and implement fee estimation using eth_feeHistory.
- Simulate replacing a low-fee transaction with a higher-fee transaction using the same nonce.
- Compare malformed-transaction rejection with an on-chain revert, and decode real transaction calldata.
What you’ll take away
- Explain the serialized and signed transaction payload.
- Recognize the fee models of Types 0, 1, and 2.
- Diagnose nonce gaps, low fees, dropped transactions, and execution reverts.
- Implement replacement logic without treating the mempool as a global source of truth.
Week 4On-chain activity, logs, streaming, and monitoring systemsConnect off-chain authorization with on-chain execution, then observe the result. Learn to choose between signed messages, event logs, lightweight simulation, and detailed execution traces.
What you’ll explore
Off-chain intent and signatures
- Authorization messages versus state-changing transactions.
- EIP-191 personal signing and its message prefix.
- EIP-712 structured data, type hashes, and domain separators.
- Binding signatures to chain ID and verifying contract; ERC-2612 permit and relayer-submitted approvals.
Events and indexing
- State, logs, and execution history: what each can tell an off-chain application.
- Event signature topics, indexed fields, and ABI-encoded data.
- Filtering eth_getLogs by block range, address, and topics.
Simulation and tracing
- eth_call for results and revert data; debug_traceCall for a deeper execution view.
- Logs as emitted data versus traces reconstructed by node tooling.
- Following contract-to-contract calls and locating a revert inside a call tree.
Hands-on work
- Implement an end-to-end EIP-712 permit flow with off-chain signing and on-chain verification.
- Design a DeFi event and choose which fields to index.
- Query logs using cast or curl with address, block-range, and topic filters.
- Compare a failing call through eth_call and debug_traceCall.
- Step through EVM execution in Foundry, including calldata reads, jumps, and storage writes.
What you’ll take away
- Reason about authorization, signing, execution, and observable results separately.
- Design off-chain signature flows with explicit context binding.
- Build log-based indexers and choose the right simulation or tracing tool for a debugging task.
Weeks 5–6Mini DEX and live monitoring systemBring the course together in a full-stack token application: contracts, wallets, a backend, PostgreSQL, a frontend, and transaction monitoring.
What you’ll explore
ERC-20 mechanics
- Token balances as contract-maintained accounting.
- Token metadata, total supply, balance queries, transfers, approvals, and transferFrom.
- Owner-initiated transfers versus allowance-based spending by another contract.
- Decimals, precision, and integer arithmetic.
Application architecture
- Persisting wallets, token records, and transaction history in PostgreSQL.
- Generating test wallets and connecting them to on-chain addresses.
- Tracking a submitted transaction from pending to confirmed and updating the application state.
Hands-on work
- Deploy a custom OpenZeppelin ERC-20 token with a name, symbol, and initial supply.
- Build a SimpleSwap contract that pulls approved tokens with transferFrom and returns a reward token at a 1:1 ratio.
- Create PostgreSQL tables for wallets, tokens, and transactions, with APIs for creating/listing wallets and recording deployed tokens.
- Build wallet and native-balance views, plus a browser-based token deployment form.
- Build the approve-then-swap interface and an activity view that updates the database and UI after confirmation.
What you’ll take away
- Deploy tokens and correctly integrate the approve/transferFrom flow.
- Connect the contract, backend, database, and frontend layers of a DApp.
- Handle wallet interactions and make transaction progress understandable in the UI.
A question from the course
Same code. Different caller. What changes?
A contract’s behavior depends on more than its source code. The execution context determines who it sees as the sender, and which address it considers its own.
A caller invokes contract A. A then uses contract B’s code to read the sender and the current contract address. Compare a read-only external call with a delegatecall.
| How A invokes B | Sender seen | Current address |
|---|---|---|
| Static call | Contract A | Contract B |
| Delegatecall | Original caller | Contract A |
The static call runs in B’s context. The delegatecall uses B’s code while keeping A’s context, including the sender that A received. That is the starting point for understanding how a proxy can use another contract’s logic.
Before you run the next example, ask: if that delegated code writes to storage, whose storage changes?
Interested in this bootcamp?
Leave your email and I’ll get in touch to talk about the course and whether it’s right for you.
Prefer to write directly? bytebeetle1@gmail.com