T5 · Security Engineer
Move beyond finding bugs to delivering a threat model others trust for decisions.
For security and auditing.
“T5” here means this track. Linked “Chapter T30” means a course chapter; Chapter T5 covers the EVM account model.
Who This Track Serves
You find defects but cannot justify severity. Missing checks look wrong, yet translating them into who loses how much relies on intuition.
You assess implementation but not economics. Familiar reentrancy, permissions, and precision issues are visible; valid calls using capital to drain a protocol are not.
Your report is a finding list. Teams fix suggested lines, but you cannot explain remaining failure conditions.
You use tools without knowing their omissions. Static analysis, coverage, and fuzzing lack an explicit map of covered and missing problem categories.
The dividing line: deliver protocol boundaries, including explicit exclusions, rather than merely findings.
Prerequisites
Security requires business understanding. Chapter T29's dependencies on Chapter 24 and Chapter T21 mean DeFi audits require oracles and liquidation knowledge.
- Chapters T7–T9
- Chapter T12
- Chapter T28
- Chapter 24
- Chapter T21
- Chapter T29
- Chapter T30
| Required reading | Graph rationale |
|---|---|
| Chapter T7 through Chapter T9 | T28 depends on T8/T9; auditing requires writing code and understanding gas |
| Chapter T12 · Testing & Deployment | T28 prerequisite; fork skills enable executable reproductions |
| Chapter T28 · Smart Contract Security | Vulnerabilities live in order and unguarded paths |
| Chapter 24 · Collapse and Attacks | T29 prerequisite; attack taxonomy rather than only examples |
| Chapter T21 · Oracle | T29 prerequisite; common single dependency and economic entry point |
| Chapter T29 · Protocol Security | Attacks using money rather than bugs; cost table |
| Chapter T30 · Audit | Threat questions, invariant categories, tool boundaries, report structure |
Also read Chapter T24 · MEV for ordering attack surfaces and Chapter T26 · Cross-chain for trust-assumption responsibility.
What You Will Learn
- Audit
- Threat Model
- Fuzzing
- Formal Verification
- Economic Security
Five topics form three groups plus professional standards throughout.
1. Threat Models and Audits: Decide What to Examine
Scope bounds an audit and follows the threat model. Within two days of encountering a protocol, identify attackers, desired assets, capabilities, and explicit exclusions.
Map money from entry points, mark trust boundaries, list dependency failures, and tabulate permissions and activation delays.
Severity combines reachability and impact. Without attacker prerequisites and affected assets/users, grading is guesswork.
2. Fuzzing and Formal Verification: Preserve Conclusions
Deliver automatically running properties. Stateful fuzzing finds sequence failures; formal methods suit short, precisely expressible, exceptionally costly logic.
Practice:
- Derive invariants from unfamiliar code and distinguish safety properties from accidental implementation details.
- Generate sequences reaching deep states rather than circling shallow ones.
- Tune using coverage and identify diminishing returns.
- Recognize model-bound proofs: a wrong model yields an irrelevant proof.
3. Economic Security: Money Without Bugs
Distinguish code auditors from protocol auditors through attack-cost tables: capital, time, transaction count, and extractable value per attacker.
Cover price manipulation and flash loans, governance windows and borrowed voting, liquidity cascades, reversed liquidation incentives, and dependency contagion.
The hardest part is knowing which cost to calculate. Ask how much it costs to buy each assumed condition.
4. Professional Standards
Real-system boundary violations are incidents rather than learning exercises.
- Read public code and reproduce locally or on forks. Never conduct interactive tests against unauthorized live deployments.
- Disclose real vulnerabilities responsibly through project channels, allow fixes, and publish after confirmation.
- Use testnets for asset-dependent validation; unavoidable real funds must be small and disclosed beforehand.
- Keep reproducible exploits in fork environments rather than publishing ready-to-run mainnet attack scripts.
Final Deliverable
A real protocol audit report with threat model, invariants, and reproduction code.
The Capstone Project builds your system; this evaluates somebody else's. Its workplace-equivalent format makes it particularly useful to employers.
Choose public code with manageable core size, roughly under two thousand lines, and an existing audit. The public report permits comparison after your own assessment.
Others can run reproduction code. Every finding has an executable fork test, one-command execution, and before/after state comparison.
Explicitly prohibit running these tests against live deployments. Without reproduction, a finding remains an unverified hypothesis.
Answer four threat questions with at least three exclusions. Include insiders such as multisig and upgrade holders, their goals, and capabilities.
Every exclusion specifies who bears consequences.
Provide invariants and completed fuzzing runs. At least eight cover all three categories, consequences, and automatic checks.
Record deliberate breakage and the shortest failing sequence. An unproven always-green check provides no assurance.
Provide an attack-cost table. Three attacker types minimum, with capital, time, transactions, and maximum payoff.
Conclude which attacks are profitable under current parameters. If none, explain whether capital, timelocks, or depth supports that result.
Justify severity through reachability and impact. Labels alone are insufficient.
State scope, files, commit, and exclusions at the start. T30's team fixing seventeen findings before being drained overlooked this page.
Assess Your Readiness
Threat models and invariants.
Findings document past mistakes and decay with each new commit outside their coverage.
Threat models define danger boundaries; invariants remain in tests, rechecking changes.
Findings are this engagement's output; models and invariants leave lasting capability.
Ask whether violation loses money or control.
Balances exceeding actual assets prevent withdrawals: a safety invariant.
An internal array matching user count may change with implementation without reducing safety.
AI often turns current implementation facts into purported invariants that all pass but protect nothing.
Manipulate thin collateral markets, borrow against inflated value, and abandon positions. Flash loans minimize principal requirements.
Borrow or buy votes, pass favorable parameters, profit after execution, then return tokens. Timelocks and borrowable voting depth determine feasibility.
Block liquidation or remove collateral-sale liquidity during volatility, accumulate bad debt, and hold positions elsewhere benefiting from it.
Every call can be valid, which implementation-only audits miss.
They verify properties already expressed.
Static analysis recognizes known shapes without business meaning; fuzzing violates written invariants; formal proofs apply within supplied models.
All miss entire attacker categories you never considered.
Revisit threat-model actors, especially unlimited-capital arbitrageurs and your own team.
Check:
- Define scope and threats before line-by-line reading.
- Map fund flows and authority, where most critical issues reside.
- Reserve time for explicit exclusions, often the team's greatest need.
Spending both days only reading usually produces just findings.
Common Mistakes
“More Findings Mean Better Audits”
Count reflects rough implementation rather than assessment depth. Twenty-three low findings can miss economics; six with models and invariants can offer more value.
Focus on remaining failure conditions; findings are byproducts of answering them.
“Running Tools Means Checking Everything”
Static analysis filters rather than judges; fuzzing tests written properties. Interpret outputs against threats.
Classify true findings, false positives, and false negatives. Infer missing categories from threat coverage—these are most dangerous.
“Auditing Is a Launch Gate”
A snapshot cannot follow changing code, dependencies, or markets. External upgrades can invalidate assumptions without your code changing.
Place invariants in CI and assumptions in monitoring, such as implementation-address alerts. Value depends on lasting automatic checks.
“Economics Is Outside My Code Audit”
Explicit scope exclusion is professional; silent assumption is dangerous. Most teams commission no separate economic review.
Document noticed but unassessed economic assumptions and recommend attack-cost analysis. Naming an unreviewed risk can outweigh several minor findings.
Next Steps
- Reread with your target: Chapter T28, Chapter T29, Chapter T30.
- Track T4 · DeFi Engineer's mechanisms are mandatory for DeFi assessment.
- Combine Track T1 · EVM Engineer for code depth, Track T3 · Onchain Data Engineer for forensics/monitoring, and Track T6 · AI × Crypto Engineer for model-driven attack surfaces.
- Before AI-assisted auditing, read AI Safety Stack and Chapter T31: AI accelerates output without transferring review responsibility.
- Cross into Track N5 · Crypto Founder, where audit experience informs when to spend security budgets.
- Build your own system through the Capstone Project.