Sign in Subscribe

You’re wasting 60% of your time during audits

By Arsen —
You’re wasting 60% of your time during audits

This is the most advanced part. And it’s where most auditors quietly fail.

Ask a random auditor:

“What is your audit approach?”

You’ll hear:

  1. “I read from up to bottom.”
  2. “I follow the flow.”
  3. “I just read the code”

That’s not an approach.

That’s just reading code.

Your audit approach is the difference between a beginner and a senior.

It won’t turn you into LSR overnight.

But it will:

  • Focus your time
  • Force your thinking to go deeper
  • Make your results compounding instead of random

Approach is personal.

But it’s not magic. It’s something you design, use, and improve for years.

Quality of your approach → quality of your findings → quality of your career.

Two Things Your System Must Do:

Over time I tried everything:

  • Drawing diagrams
  • Pasting code into Miro
  • Taking raw notes in VSCode

Some of it worked.

Most of it didn’t scale.

What I eventually realized:

Your system must do two jobs.

1. You need a second audit brain

A place where you:

  • Compress every thought
  • Park every question
  • Track every lead

In a way that doesn’t create noise.

Not a screenshot dump.

Not a 3000-line markdown file.

Not “I’ll remember it later.”

You need a place where you can reason about the code, not just store it.

Somewhere you can:

  • Distill each line into what matters
  • Ask “why” and “what if”
  • Compare variants
  • Capture attack angles

This is where you think

This is place which you refer to.

This is the place where you double prove your understanding

2. You need a system to memorize the codebase faster

Your working memory must stay light.

If your brain is overloaded with details, you stop seeing bugs.

You need:

  • A way to visualize the structure
  • A fast way to recall key flows and state transitions
  • A map, not just a pile of code

At one point, Miro was perfect for this:

  • I could see the whole codebase at a glance
  • I could skim flows quickly
  • I could audit from my phone
  • It led to real bugs

So yes — as a visual index + memory boost, it worked.

But it was still not my second brain.

I could see the code.

I couldn’t reason with it.

Reasoning > Reading

This is the one thing AI still sucks at and humans still win:

Reasoning about intent and attack paths.

You already know:

  • What the function does
  • Who calls it
  • When it runs
  • What it updates

That’s basic.

Now the real work starts:

  • What mistake would I make here if I was the dev?
  • Why did they pick this design and not the obvious alternative?
  • How do other protocols implement this? What’s different here?
  • What are the core invariants the system assume?
  • What is this function trying to protect against? What if that assumption fails?

That’s audit reasoning.

You’re no longer “understanding the function”.

You’re turning it into:

  • Hypotheses
  • Threats
  • Assumptions to break
  • Inputs to abuse

Once you start doing this seriously, you’ll notice:

Your head fills fast.

If you don’t externalize it in a compact way, you:

  • Forget leads
  • Re-think the same thing 5 times
  • Miss the one angle that matters

That’s why you must build a second audit brain.

I use Notion for this.

Not because it’s “cool”, but because:

  • I can layer notes (system → flow → function → line)
  • I can link flows, bugs, and ideas
  • I can quickly scan my own reasoning

You can use anything — Notion, Obsidian, markdown —

but the principle is non-negotiable.

Audit Management (Time, Depth, and Priorities)

Last piece: management.

Most auditors either:

  • Go too shallow everywhere
  • Or get stuck too deep in one place

Both kill depth.

In private audits, you must read every line.

That’s the baseline.

But that doesn’t mean every line gets equal attention.

You must decide:

  • Where to spend 5 minutes
  • Where to spend 5 hours
  • Where to come back with fresh eyes

Bugs live everywhere:

  • In simple init functions
  • In trivial-looking setters
  • In “boring” edge checks
  • And in the heavy flows you fear

But your goal in this course is not: “Find any bug.”

It’s:

Find deeper bugs on purpose.

That means:

  • You review everything
  • But you prioritize flows with systemic impact
  • You push yourself to sit longer where complexity + money + assumptions meet

We’ll turn this into a concrete system in Session 2 and 3.

For now, the point is simple:

If your “approach” is just “read and hope”, you’ve already lost.

You need:

  • A second brain
  • A memory system
  • A reasoning habit
  • And a time & resource allocation strategy

Otherwise, you’re just reading the code code and don’t use your energy effectively