This is the fundamental stuff that you will need on your journey as an auditor. Here, you will read about what the pro players do and why they do it. Let's begin.

1. Report everything.

2. Write good issues.

3. Spend as much time as you can.

4. Close the cycle

5. Think outside of the box.

Report everything

One extremely common mistake that most auditors make is catching a bug and not reporting it. That may seem stupid. Yes... yes, it is.

However, most beginners are not sure what a bug is and what is not. Some people think only major issues are bugs, like stealing some funds or breaking the whole contract, and so on. However, really simple bugs are also bugs, and they usually are the bugs that pay the most. These bugs can be a simple discrepancy between the docs and code, small errors, things that are "strange" but don't cause any issues. An example is a recent audit of mine, where a MED is a slight discrepancy between the docs and the code. The bug was worth some money, not because no one knew it or that it was an "advanced" exploit, but because they didn't report it as they thought it was informational at best.

That moves us to the second point. Most people are afraid of submitting stuff. I am questioning Sherlock, as they are the guys that punish people for submitting false bugs. However, some people are transferring that feeling of being wrong when they submit an invalid bug to other platforms, like c4. On platforms that don't punish bad reports, I would suggest reporting everything that you find as "strange". Put the big stuff as MEDs and the small stuff as LOWs (however, make the report good so you can argue for escalation if that LOW is a MED at post-judging QA). There is no penalty for submitting invalid stuff (unless you submit 15-20 awfully invalid findings, but you are not that stupid... right?). Of course, try not to spam the judge with crappy reports and half-baked findings.

"You miss 100% of the bug you don't report."

Look at another perspective, the perspective of the developer. He is paying for the audit, and as such, you should provide him with as many bugs or inconsistencies as possible. Reporting something "strange," which may be a bug or may not be, is you trying your best to make the code as secure as possible. Because if something "strange" is left out, on future updates, it can be the reason a bug pops up.

Write good issues

Now, while we are on the topic of issues and reports, it is really important that you write as good reports as you can. That skill purely affects your payout, as you can be a really good auditor, but bad reports will consistently get your findings invalidated or marked as 50% (half the payout). And if you are really good at writing those reports, you can get "selected for report," a nice title with a 30% reward increase for this issue.

Here, I am going to give you the short version of "How to get selected for report every time” and if you want more details, check my other article about writing the best report there is.

1. Make it simple - Be sure that, even if the judge hasn't looked at the codebase yet, he will know what you are talking about.

2. Use ChatGPT - Make the report yourself and use GPT just to structure it better and fix the grammar mistakes.

3. Do a POC if you have time. This is avoiding the 50% mark and making you really close to being the selected report. However, just a POC won't make you selected, as you need a really good-looking report. And for God's sake, make those POCs in a Gist, don't just put 500 lines of code into that report.

4. Use fancy math - Use markdown mathematical formulas ($$ \frac{1^{(n-1)}}{n} $$) if there is math involved.

5. More links, the better - Every time you reference a function, make it a link. Firstly, they add some color to your report, making it less blunt, and secondly, they make it really easy to follow with the main code.

6. Make good resolutions - After doing the report, think of what's the best solution. If it's some code that needs to be redone, do a diff, that makes the solution seem extremely simple.

7. Use tables for examples with a lot of prerequisites - save space and looks really good.

8. Use the solidity tag instead of jsx - that may be obvious, but some of you mules are still marking your Solidity code with jsx.

Spend as much time as you can

When you are done auditing and you think you are finished, I want you to know that actually, you are 50% done, if even that much. There are always more bugs to be found, more ways to break the system, and more tricks you can pull to score those fine As on QA reports.

Why is that, you may ask? As described by the best auditors on Twitter, they only catch about 50% of highs and 35-50% of mediums. So why do you "finish" the audit with 6-7 bugs? What makes you think that you have found every bug you can find?

We often wrap up audits and call them finished because we looked at everything, our minds are exhausted, and we can't think of any new ideas. We already know the code by heart and every aspect of it. The audit gets hard as we are forced just to think and think of what could go wrong in a system that by now seems empty of bugs. However, no matter how many bugs you have found, there are always more. You need to stop listening to your mind telling you to jump ship to the next audit, focus on the thinking, and be there looking at the code.

Most times, you are able to find one or two more bugs. Even if you found one, these bugs are often the most valuable. This is because there is another really important concept:

"If it's hard for you, it's hard for everybody."

This means that when you reach the point that you want to quit, other auditors have reached it too, and they have chosen to quit.

One really good piece of advice I've heard from Owen is after you have finished the audit, submit everything, read the code one last time. Read it line by line, the same way that you did when you were starting the audit. Most likely, you will catch a few more leads.

Close the cycle

We need to close the learning cycle as quickly as possible. Imagine it as a large circle, the faster you close it, the smaller it becomes. We need to make it as small as possible in order to do the most laps, where with every lap you get better and better. This is advice for anyone who wants to progress quickly, because the more you repeat the same mistakes, the more they will slow you down.

Everyone advises to "review your past audits," but no one teaches you how to accomplish it. That's why today I am going to give you the most straightforward advice that anyone could follow, maximizing your learning from every past issue.

Get yourself a note-taking app, I use Obsidian, and we will start making notes.

1. Make sure you do it as soon as possible.

2. Write the audit name + summary. Write the date and name of the project ('2077-12-coconuts') and a short description below (like a summary).

3. Write every issue with your own words and link it to the original report.t. Avoid laziness and write each issue in your own words, that's the primary learning mechanism.

4. Write three or more questions on how this issue can be found again.

5. Close the tab and try to name every issue and how it's done. This is the secondary learning mechanism. Your brain makes memories not just from reading but from pulling information out of itself.

6. Read all the issues you weren't able to explain.

If you wish, you can repeat steps 5-6 until you know every issue by heart (it will take 2-3 turns). However, we have already achieved maximal learning with minimal effort. This kind of summary will likely take 30 minutes to an hour, and you will have reviewed every issue, whether you found it or missed it. The important thing is to know how these issues are found and what their structure relies on.

Think outside the box

Finally, but most importantly, you will need creativity for this job. That is the hardest part, yet the most proficient one. Because it doesn't matter that you spend all day in order to find that finding, it won't matter that this is your only issue, and it won't matter if your report is mediocre if you are the only one reporting this issue. At the end, if you want to call yourself one of the best, what will matter are your skills at finding the hard-to-find bugs.

This here is what defines good from great. Your ability to be creative and think outside the box, for your brain to work in ways that no one else can. This is why this is the hardest thing you can do, and of course, the one that pays the most. This is all great, but "How is that done?" is the question you are asking yourself.

To think outside the box, firstly, you will need a box. These are the fundamentals, like solidity, how transactions work, how big protocols work (UNI, COMP), and so on. You will learn them with time, as some audits will require you to know how certain protocols work. Focus on learning things that are important and useful for what you need at the moment.

You will need to view the system as a whole, not function to function interaction, not contract to contract or protocol to protocol, but the whole web3 as one giant sphere of possibilities. How the contract you are currently auditing will interact with other contracts and the network, this is where the floodgates of creativity will open.

Here is where I will end, as I have not yet reached this part. I can write more stuff about it, I can say more things that you can do, that you will need, but those will be just guesses.

I hope you enjoyed the reading. Give this article a tweet and tag me at 0x3b so we can share this knowledge faster. See you next time.