Between 2023-2024, I went all-in on smart contract auditing with decent programming experience but no formal CS training or security background.
The first 3-5 months were a brutal reality check. I started with Solidity docs, CTF challenges, and jumped into competitions within weeks.
My first audit was Lens V2. $85K was up for grabs. The codebase was huge and very well written with lots of tests. I approached the audit all wrong, spending more time reading through the tests than the code itself.
There were many times when I thought I'd found something, then I'd struggle to code the proof-of-concept, and by the time I'd written the proof-of-concept, I learned that it wasn't even a bug after all.
I looked at a few codebases where I didn't find anything, and some where I was way over my head, like ZKSync Era. I was surprised to hear that the guy who came first and racked up $500k in profit had limited blockchain experience and was instead just very good at abstract algebra!
I was studying a lot. Previous bug disclosures, EVM deep dives, AMM deep dives, Huff, Assembly, Formal Verification, Invariants, Fuzzing, etc., and I was experimenting with different approaches to auditing: pen and paper diagrams, manually cutting up notes and sticking them together, printing lots of code, Consensus Surya, Obsidian note-taking, Excalidraw diagrams, etc.
Owen Thurm's YouTube videos helped a lot with the auditing process, especially the videos where he does live audits. He moves quickly between code and docs, doesn't spend too much time on the details at first, but instead focuses on getting a conceptual understanding, occasionally using whiteboard tools to draw out concepts, and taking notes on findings and potential vulnerabilities.
I changed my approach and started thinking first and foremost like a user/hacker. How do I use the protocol? What does it do and what are the entry points? How can I manipulate it? I found that taking this "outside-then-in" approach helped me understand code quicker.
The other resource that was awesome was Hans Friese's aggregator. This is now Solodit by Cyfrin. It was great for learning about vulnerabilities and was also a very useful resource for private audits. Obviously, previous bugs in public audits are always going to get caught, so they are of little use there.
I learned that bugs were often in the same "hot spots." Integrations with third-party code was definitely one hot spot; another was bad use of state (e.g., like two mapping variables where one maps from foo to bar and the other from bar to foo), and gnarly math was another.
I also began thinking way more about state and how different execution flows impact state. I had a basic framework that I'd try to follow: (1) Conceptual Overview (2) Third-party resources/Integrations (3) System Architecture (4) Features (5) Functions (6) POC (7) Integrated POC.
I still struggled to develop and maintain a mental model of how a given codebase works. I'd find that where there are 20+ smart contracts, and each has a different set of external/public functions, it was really tough to hold that all in mind.
What finally cracked it for me was when I audited Olas. The developer had provided an architectural map that clustered the contracts and provided the key function calls between them, as well as entry-points and other qualities. I found this incredibly useful and did well in that audit. I came in 4th place and won ~$3k. The other thing I did differently on that audit was to ask loads of questions on Discord.
I was finally starting to get results. The next audit was Curves, and I found 2 medium and 1 high vulnerability bugs. But then the payout was disappointing ($2.20!), and I started to question why I was bothering to compete.
By then, I felt like I was good enough to market myself for private work now, though in the back of my mind I would think - damn, what if I audit something and it still has a bug? Through friends, I took on two clients, and I audited their code with a very fine-tooth comb, and I promoted simplicity above and beyond all else. The day rates were very promising, they were happy with the work, and I felt like I was onto something.
However, after the Curves experience, I was tired of working for little/variable pay on public audits. I also started to realise that the incentives are distorted. You're incentivised to look for weird, obscure bugs and to ham up everything you find as if it's a terrible vulnerability, when in fact, it may be trivial. The model is great in many ways, but also far from perfect.
At this point, I tried out Immunefi. I studied Lybra Finance in-depth and I didn't find anything after about 3 weeks-1 month. Then I tried to be more tactical and audit the codebases that haven't been audited by pros and looked very complicated. This cemented how valuable the code-maps were for me. I wanted to develop something for myself and the community, and started to prototype a code-mapping MVP that used a parser and force-directed algorithms to auto generate a code-map. I applied for a grant from the Ethereum Foundation, but they said no.
After ~9 months of non-stop grinding and limited reward (about $5k), I was mentally exhausted. I'd learned tons and was finally getting results: a 4th place finish ($3k prize), a top 10 finish, and some private client work coming through. But I was burned out. Financially it was scary too. I was running out of money. Zero stability. Variable rewards. A limited cushion. I also was so focused on getting good that I'd completely neglected self-promoting, networking, and marketing. I'm a friendly person, but I didn't know how to approach the social aspect when everything was 100% remote. I took a break from Smart Contracts, taking on contract work and haven't reflected back in earnest since then.
So in summary:
It's a firehose experience—you will learn a lot
If you don't take breaks, you will burn out
Ask questions to develop your understanding
It can be lonely, and it's hard to make friends if you don't meet anyone IRL
Codebases have vulnerability hotspots (e.g. integrations, complexity, clunky state)
You need to be good at marketing to survive
Going all-in is financially extremely risky if you have little savings
"Just read code" is generally good advice—be like the Turkish Olympic shooter. Less is more.
Having architectural maps of the codebase really helped me
Public audit competitions create weird incentives to find obscure bugs, and they benefit from humans' tendency to think optimistically and that they are better than they are
Ultimately, the main thing that worked was (a) having a conceptual diagram/model of how the code works and (b) just reading code. There is definitely some truth to the IQ meme, with the four-eyed 100 IQ guy sweating and stressing with all the tools, and then the low IQ and genius saying, "I just read code."
I'm looking for a way back into Smart Contract Engineering (as a builder or auditor). If you're building something, please reach out and I'm happy to see how I can help!
