Auditor's golden system
Write audit notes like this and find more bugs
Hey, it’s Arsen.
In today’s menu:
• The note-taking system most auditors skip
• USR token minted and dumped — price crashed to $0.05
• And more…
🏴☠️ Hacks / Bounties
• USR token minted and dumped — price crashes to $0.05 (Link)
• Auto-allocation bug turned USR exploit into bad debt (Link)
🗞️ News
• BattleChain testnet lets whitehats attack contracts pre-mainnet (Link)
• Balancer Labs winds down after exploit fallout (Link)
📚 Education
• Why audit process matters more than findings (Link)
• The Flashloan fee inflation bug that drained $250K on dTrinity fork (Link)
Deep Dive
You reviewed the code line by line.
You feel like you understand it.
But can you explain it from memory?
Most auditors can’t.
And the ones who can’t — don’t know what they missed.
Here’s what happens after a typical line-by-line read.
You feel like you covered the function.
You move on.
10 functions later — you “reviewed” the whole contract.
Then a senior asks: walk me through the codebase from memory.
Blank.
Or worse — you trace a bug back.
And realize you skipped the exact piece that would’ve caught it.
The problem isn’t effort.
Line-by-line reading is passive.
You see the code.
You make underlying notes.
That’s not the same as understanding it.
Writing a lot pushes understanding.
When you explain something in your own words and get stuck —
That’s not failure.
That’s the system working.
The stuck = gap = where the bug usually lives.
Most auditors ignore that moment and keep moving.
The ones who find criticals stop, follow the thread, and write down what they find.
Here’s the process I use, function by function:
Open a new note named after the function. Write the sub-structure first (flows/ideas). Skeleton before detail.
Explain every line in your own words — not quoted, explained. What does it do? Who provides this value? Who can control it?
When you catch yourself not understanding — stop immediately. Open the constructor. Write what you find. Link back. Continue.
Log attack leads in-place. When a “what if” hits, write it right there. Tag it [DOS?] [Access?]. Write the theory. Confirm or disprove it. Don’t let it disappear into your head.
Don’t fear rabbit holes. Your notes hold the context — your brain doesn’t have to. Go as deep as needed. You won’t lose the thread.
Here’s how it played out in a recent audit.
I was going through a reconstitute function.
Wrote: “governor checks the sender is trusted.”
Caught myself — who is governor? Where is it set?
Jumped to the constructor.
No validation on the input.
Wrote it down.
That one caught thread became a finding.
The function looked clean on first read.
The notes found the bug.
Most auditors treat notes as documentation.
A record of what they saw.
That’s wrong.
Notes are the audit.
Explaining every function in your own words, following every unclear thought —
That IS the process that finds bugs.
By the time you’ve written detailed notes on every function, you’ve processed the protocol twice.
The gaps are documented, not buried.
The attack leads are on paper, waiting to be tested.
Re-read in 20 minutes what took 4 hours to build — and see it fresh.
Arsen.
Reply with what you want me to cover next — I read every one.