T1 · EVM Engineer
Progress from a working contract to knowing when it breaks and what failure looks like.
For contract engineers primarily working with the EVM.
“T1” here means this track. Course chapters are called “Chapter T8” with links; Chapter T1 concerns what onchain data actually is.
Who This Track Serves
Look at your obstacle rather than title. Any of four situations qualifies.
You can write contracts but cannot explain their safety. Testnet deployment, green tests, and coverage look good. Your strongest safety evidence is passing tests, although you know that is insufficient.
Real mainnet code is unreadable to you. Proxies, inline assembly, packed bits, and custom errors obscure whether choices are necessary engineering or unnecessary cleverness, preventing confident reuse.
Gas optimization depends on memorized slogans. You know calldata is cheaper than memory and variables should pack, but cannot calculate layouts or quantify savings from rearranging two variables.
You can define terms but not consequences. You recite delegatecall's caller-storage context but cannot give a concrete storage-collision example.
The dividing line: does delivery include “I tested it” or “I know its failure conditions and consequences”?
If you have never deployed to testnet, complete Part B stage two first. This track assumes a working repository.
Prerequisites
All 36 Part B chapters are ideal. For an earlier start, the Knowledge Graph's shortest path is:
- Chapter 6
- Chapters T1–T4
- Chapter T5
- Chapter 9
- Chapter T7
- Chapter T8
- Chapter T9
- Chapter T12
- Chapter T28
| Required reading | Graph rationale |
|---|---|
| Chapter 6 · An Onchain Transaction | T1 prerequisite: understand transactions as state changes before discussing order |
| Chapter T1 through Chapter T4 | State, signatures, transaction lifecycle, RPC: no shortcuts |
| Chapter T5 · EVM Account Model | T7 prerequisite; storage slots are this track's unit of cost |
| Chapter 9 · Smart Contracts | Another direct T7 prerequisite and the hard Part A dependency |
| Chapter T7, Chapter T8, Chapter T9 | Language, EVM costs, standards: the track's core starts here |
| Chapter T12 · Testing & Deployment | Depends on T7 and T9; fork tests become daily work |
| Chapter T28 · Smart Contract Security | Depends on T8, T9, T12; all explain its emphasis on order rather than syntax |
What You Will Learn
- Solidity
- Foundry
- Hardhat
- EVM Internals
- DeFi
- Security
Six topics form four groups of questions.
1. Language and Toolchains: Verifiable Rather Than Merely Compilable
Advanced Solidity ranges from inheritance linearization to custom-error revert data, safe unchecked scopes, and appropriate transient storage. These concern who pays how much, beyond syntax.
The two main toolchains complement each other: contract-language tests with fuzzing and invariants, and scripting-language deployment, orchestration, and frontend integration. Mature repositories often use both. Build each from an empty directory and explain their division of work.
2. EVM Internals: Gas as Arithmetic
Calculate layouts before deployment: slot assignment, packing conditions, mapping slots, and dynamic arrays. Then calldata, memory, and storage costs become calculable rather than memorized.
Proxies change whose storage delegatecall writes. Different layouts prevent implementation variables colliding with proxy variables.
Given somebody else's contract, identify two variables to rearrange and whether the saving is a cold or warm write.
3. DeFi: What Your Contract Composes With
You need less depth than Track T4, but must read major protocol cores and understand interactions that damage your code:
- Transfers without boolean returns, taxed tokens, changing balances, and non-18 decimals.
- Precision and rounding: favor the protocol, as Chapter T28 explained.
- Oracle failures: stale values, excessive deviation, and zero returns.
- Callback token standards introduce reentrancy even without ETH transfers.
4. Security: Automatically Running Safety
Chapter T30's four threat questions and three invariant categories become required for every project. Add stateful fuzzing, static analysis treated as filtering rather than judgment, and explain what multisigs, timelocks, and pauses prevent.
Final Deliverable
Mainnet contracts with fuzzing and fork tests.
The Capstone Project requires breadth across a full system. This track requires only contracts but greater depth. Start from capstone contracts and apply these five criteria again.
Others can run it. After cloning, one command installs dependencies and another runs all tests. Document variables, fork RPC sources, and fallback without archive nodes.
An unrunnable repository is effectively absent in hiring and collaboration; this comes first.
Fuzzing runs and has genuinely failed. At least five invariants cover all three categories. Retain one deliberately broken invariant's shortest failing sequence and random seed.
An always-green check can provide the same protection as no check while creating false reassurance.
Fork-test every external dependency. Include a case for every called external address, specifying chain, height, and why that height was selected.
Baseline gas and explain increases. Commit critical-function snapshots. Identify added storage writes or external calls behind increases.
Provide a threat model and upgrade path. Answer all four questions, including two explicit exclusions. If upgradeable, explain authority, delay, and shutdown.
For mainnet, use small amounts of your own funds and only versions passing the first four criteria. Testnet-only delivery with reasons to defer mainnet receives no penalty; it demonstrates judgment.
Assess Your Readiness
Storage collision: writing implementation slot zero writes proxy slot zero. If it holds the implementation address, an ordinary assignment can redirect execution.
Preserved identity: in delegatecall code, msg.sender and msg.value remain those of the outer caller. Callee permission checks may mistake this for direct invocation.
Bonus: a destroyed or replaced delegatecall target can leave the proxy pointing to empty code, where calls do nothing without reverting.
Cache reads locally. Only the first is cold; later reads are already warm, so you save two warm reads rather than two cold ones.
Writes usually dominate: combine them or pack small variables into one slot.
Explain cold-versus-warm costs and compare snapshots. “Memory is cheaper” alone is memorization.
Missing boolean returns cause decoding reverts; transfer taxes reduce received amounts; rebasing changes balances; decimals differ; callbacks introduce reentrancy; blacklists block transfers.
Use your actual balance change before and after transfer, rather than trusting return values or requested amounts.
Provide invariant lists and fuzzing runs, explicit threat exclusions, and fork tests for critical paths rather than only an audit report.
The first two explain boundaries; the third verifies within them. An audit is a fourth item and a snapshot.
No standard answer; check:
- Describe a path—actor, funds, call order—rather than a vulnerability name.
- Specify market or permission conditions that trigger it.
- State detection time. Without it, monitoring is missing.
Common Mistakes
“100% Coverage Means Enough Testing”
Coverage measures executed lines, not every call sequence. Individually correct functions can accumulate rounding errors or misalign state in particular orders.
Use coverage as a floor; confidence comes from stateful fuzzing and invariants.
“Smaller Types Save Gas”
Replacing uint256 with uint8 saves only when variables actually share slots. Otherwise masking and truncation can cost more than the original.
Measure, change, then measure. Link snapshot savings to specific layout changes.
“Upgradeable Means Safer”
Upgradeability transfers risk from code mistakes to stolen or abused authority, with potentially greater impact. One malicious upgrade can invalidate all invariants.
Question necessity first. If required, protect upgrade authority as the highest-risk asset with multisigs, timelocks, and a public process.
“Audited Means Safe”
Scope defines audit boundaries. Without a threat model, implementation correctness may be reviewed while economic assumptions are absent, as T30's emptied protocol after seventeen fixes showed.
Provide the threat model before auditing; convert findings to invariants afterward. Scope directs investigation; regression properties preserve its benefits.
Next Steps
- Reread with your repository: Chapter T8, Chapter T12, Chapter T30.
- Combine Track T4 · DeFi Engineer for finance, Track T5 · Security Engineer for professional security, and Track T3 · Onchain Data Engineer for trustworthy data.
- Cross into Track N2 · Crypto Product. Explaining why an operation requires two signatures often matters more than coding it.
- Expand into a complete system through the Capstone Project.
- EVM costs and opcodes change with upgrades; Staying Current explains monitoring them.