Back to portfolio
Technical & SecuritySimulated project

Smart Contract Auditor portfolio brief

A simulated technical & security exercise for Smart Contract Auditor. Treat it as realistic practice, not real client or protocol work.

Objective

Complete security CTFs and public write-ups

Expected deliverables

Audit planThreat modelFinding reportProof of conceptSeverity rationaleRemediation reviewScope and limitation statement

Recommended workflow

  1. Complete security CTFs and public write-ups
  2. Audit a small open-source protocol
  3. Write scope, threat model, findings, and residual risk
  4. Review the result against the rubric, then package it as a case study.

Constraints and safety

  • Use only public sources or clearly simulated data.
  • Never include seed phrases, private keys, or wallet secrets.
  • Redact private user, company, security, legal, or compensation information.
  • State every assumption you make.

Tools in practice

Foundry or Hardhat
Compile and test the target contracts, build attack hypotheses, run static analysis, and reproduce findings before reporting them.
Slither
Run static analysis to surface suspicious patterns, then manually validate whether each result is exploitable or a false positive.
Echidna or fuzzing tools
Define security properties and generate adversarial inputs that search for invariant violations.
GitHub
Review source, manage branches and pull requests, run tests, and leave implementation or security decisions in a traceable history.
debuggers
Trace failing transactions and test cases through call frames, storage changes, and revert paths.
formal methods where relevant
Express critical properties precisely and verify selected assumptions when the system risk justifies the cost.

What a strong submission shows

  • A public audit-style report
  • A CTF or exploit write-up
  • A threat model
  • A remediation review

Weak submission patterns

  • Automated scanner output presented as an audit
  • Findings with no exploit path
  • Severity chosen for drama

Review rubric

  • Accuracy of claims and sources
  • Relevance to the target role
  • Decision quality and trade-offs
  • Completeness of the deliverable
  • Clarity of communication
  • Honest limitations and next steps

Present it as a case study

  • Explain the problem, sources, decisions, ownership, constraints, output, review, and what you would change.
  • Show the final artifact before the process notes.
  • State what you owned and what belonged to other people.
  • Label the work as simulated, and keep any real contribution clearly separate.

Interview questions this project helps you answer

  1. How do you distinguish a design decision from a security vulnerability?

  2. What makes a finding critical?

  3. How do you communicate that an audit cannot guarantee safety?

Turn this into an application