EVM advanced · In development
Advanced EVM Bootcamp
Go from writing contracts to reasoning about how a protocol fits together. Explore custom tokens, upgradeable architecture, AMM mathematics, gas, and the ways a system can fail.
For people already comfortable writing Solidity contracts and Foundry tests. This course is still in development; the curriculum below shows the planned scope.
What the course connects
Design the system. Challenge its assumptions.
Move between architecture, state, financial mechanics, and the tests that put your decisions under pressure.
Reason beyond a single contract
Study token lifecycle hooks and permits, factory and proxy patterns, storage layouts, AMM swaps and liquidity, Yul, and account abstraction. Explore the trade-offs before combining them.
Build and examine a protocol
The planned capstone brings custom token behavior, upgradeable components, and DeFi mechanics into one project. Exercise it on a mainnet fork, use fuzzing and invariants to search for failures, review the code, and document the architecture before a testnet deployment.
Testing is evidence about behavior, not a guarantee that a protocol is secure. Understanding that boundary is part of the work.
Six-week direction
From token behavior to protocol architecture.
Read the planned topics, practical work, and outcomes here. Week one includes eight modules on advanced token engineering, from ERC-20 to hybrid standards. The course is still in development.
Week 1Advanced token standards, custom hooks, and extensibilityUnderstand token behavior beneath the default implementation: custom transfer logic, signature approvals, NFT trade-offs, metadata, and hybrid-token synchronization.
Modules in this week
- ERC-20 Internals and the Token Lifecycle
- Custom Tokenomics: Fees, Rebasing, and Reflection
- EIP-712 and ERC-2612 Permit
- ERC-721 Internals and Transfer Safety
- ERC-721A and Gas-Optimized Minting
- On-Chain Metadata and ERC-2981 Royalties
- ERC-1155 Multi-Token Engineering
- Dual-Nature and Hybrid Tokens
What you’ll explore
Custom ERC-20 behavior
- The _update override and where custom logic belongs in the token lifecycle.
- Fee-on-transfer systems, reflection, rebasing, and external-call risks in hooks.
Signature-based approvals
- ERC-2612 permit with EIP-712 structured signatures.
- Nonce and deadline handling for replay protection and relayer-submitted approvals.
NFT and multi-token design
- ERC-721 transfer behavior and ERC-721A batch-mint trade-offs.
- On-chain SVG/JSON metadata through tokenURI and ERC-2981 royalty signaling.
- ERC-1155 fungible and non-fungible token types in one contract.
- ERC-404 as historical context; ERC-7631 base-and-mirror architecture and synchronization risks.
Hands-on work
- Build an ERC-20 token with a dynamic transfer tax routed to a treasury.
- Implement permit and test an approval submitted by a relayer.
- Build an NFT collection with on-chain SVG output derived from the minter’s address.
What you’ll take away
- Choose a token standard based on behavior, integration needs, and gas trade-offs.
- Extend token implementations while reasoning about security and compatibility.
- Design signature-based approvals and on-chain metadata flows.
Week 2Smart contract architecture, factories, and proxiesSeparate deployment, logic, and state. Learn how to create contract instances efficiently and evolve a protocol without losing or corrupting its existing state.
What you’ll explore
Factories and deterministic deployment
- Factory contracts that deploy and track other contracts.
- EIP-1167 minimal proxies and shared implementations.
- CREATE2 salts and predictable deployment addresses.
Upgrade mechanics and storage
- delegatecall execution context and storage ownership.
- Storage compatibility, layout changes, and collision risks.
- Unstructured storage and assembly-based slot access.
Proxy designs
- Transparent proxies, admin separation, and selector clashes.
- UUPS implementations and upgrade authorization.
- EIP-2535 Diamonds: facets, loupe functions, routing, and contract-size constraints.
Hands-on work
- Deploy and safely initialize EIP-1167 clones through a factory.
- Upgrade a UUPS contract from V1 to V2 while preserving its state.
- Pre-compute and deploy to a CREATE2 address.
- Reproduce a storage collision in a controlled example, inspect the corrupted state, and correct the layout.
What you’ll take away
- Choose an appropriate deployment and proxy architecture.
- Reason about initialization, upgrade authorization, and storage compatibility.
- Calculate storage locations and debug delegatecall-related state corruption.
Week 3DeFi mechanics: AMMs, swaps, and liquidityMove from using exchange interfaces to understanding their underlying accounting, swap mathematics, liquidity positions, and price dependencies.
What you’ll explore
Constant-product pools
- x × y = k, pricing, slippage, and impermanent loss.
- Adding/removing liquidity, LP-token accounting, and swap output calculations.
Concentrated liquidity
- Uniswap V3 ticks, price ranges, and capital efficiency.
- NFT liquidity positions and range-dependent liquidity accounting.
Flash loans and arbitrage
- Atomic repayment requirements and callback flows.
- Aave/Uniswap integrations and arbitrage calculations that include fees and gas.
Oracles
- Time-weighted average prices and price-manipulation considerations.
- Chainlink feeds, stale data, and sequencer downtime checks.
Hands-on work
- Build a Uniswap V2-style pool with swap mathematics and LP tokens.
- Implement flash-loan arbitrage across DEXes in a local mainnet-fork environment.
- Add a guarded price feed to a mock lending contract and test stale-data behavior.
What you’ll take away
- Explain pool pricing and build direct integrations with pair contracts.
- Reason about atomic trades and their costs.
- Evaluate oracle dependencies and manipulation risks in financial contracts.
Week 4The EVM engine, gas optimization, and new transaction typesMeasure execution costs and understand the lower-level operations behind Solidity. Connect those mechanics with newer transaction formats and smart-account workflows.
What you’ll explore
Gas and Yul
- Memory versus calldata when passing arrays.
- Storage packing, caching, SLOAD, and SSTORE costs.
- Yul operations such as mload, mstore, and calldataload, with attention to the checks bypassed by assembly.
Transaction formats
- EIP-1559 base fees, priority fees, and transaction selection.
- EIP-4844 blob transactions and Layer 2 data availability.
Account abstraction and delegation
- ERC-4337 UserOperations, bundlers, EntryPoint, and paymasters.
- EIP-7702 authorization tuples, delegated EOA execution, batching, and sponsorship. Delegation persists until replaced or cleared.
Hands-on work
- Rewrite a Solidity operation in Yul and compare Foundry gas reports.
- Reorganize a contract’s state to explore storage packing.
- Construct an EIP-7702 authorization and execute a batch of token transfers in a test environment.
What you’ll take away
- Find and measure avoidable gas costs.
- Relate compiler output to EVM operations.
- Compare account-abstraction and delegated-account workflows, including their authorization boundaries.
Week 5Advanced security, MEV, fuzzing, and invariant testingMove beyond happy-path tests. Study how assumptions fail, reproduce attacks in controlled environments, and build test campaigns around properties that must remain true.
What you’ll explore
Exploit classes
- Cross-contract and read-only reentrancy.
- Signature replay, integer truncation, and access-control failures in upgradeable systems.
MEV and transaction ordering
- Sandwiching, frontrunning, and backrunning mechanics.
- Searcher behavior, Flashbots, builders, and bundled transactions.
Property-based testing
- Stateless fuzzing and randomized inputs.
- Stateful invariant tests that exercise sequences of protocol interactions.
- Defining properties such as collateral/debt constraints and interpreting failures within the tested assumptions.
Hands-on work
- Solve a controlled read-only-reentrancy challenge and explain the exploit trace.
- Model a sandwich scenario against a local DEX/mempool simulation.
- Build a Foundry invariant suite for a provided lending protocol and investigate counterexamples.
What you’ll take away
- Identify architecture assumptions that deserve adversarial testing.
- Explain ordering risks and how they can affect users.
- Use fuzzing and invariants to find failures and strengthen confidence, without treating finite test runs as a proof of security.
Week 6Final project: production protocol architectureIntegrate architecture, tokens, DeFi mechanics, testing, and optimization in a protocol project, then review and deploy it to a testnet.
What you’ll explore
System design
- Separating factory, logic, and storage components.
- Architecture diagrams, state transitions, user flows, and storage layouts.
Fork-based integration
- Testing against mainnet state through a local fork.
- Simulating liquidity movement between existing protocols and the new system.
Review and communication
- Peer code review and documenting architecture risks.
- Audit reports covering logical flaws, gas inefficiencies, and recommended fixes.
Hands-on work
- Prepare architecture diagrams and storage layouts for review.
- Build a capstone such as an upgradeable yield protocol with a token hook or a modular minimal-proxy DEX.
- Review another participant’s project and document findings and fixes.
- Automate deployment to a live testnet.
What you’ll take away
- Take a protocol from a design to an integrated, tested testnet deployment.
- Review another codebase and communicate findings clearly.
- Write technical documentation that explains the architecture and its trade-offs.
A question from the course
You signed a permit. Did any tokens move?
A wallet signature and a token transfer are different operations. The distinction matters when a vault or router uses a permit.
In this example, the owner starts with 1,000 tokens and signs permission for a vault to spend 125. A relayer submits that permission to the token contract.
| Token state | Before | After |
|---|---|---|
| Vault’s allowance | 0 | 125 tokens |
| Owner’s balance | 1,000 tokens | 1,000 tokens |
| Vault’s balance | 0 | 0 |
| Owner’s nonce | 0 | 1 |
The permission changed, but the balances did not. Spending requires a separate transfer operation, even when an application combines both steps in one transaction. The nonce has advanced, so the same signed permission cannot be used again.
Now ask: if the later transfer fails, does the permission survive? The answer depends on whether the two operations share one reverting transaction.
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