Once i’ve started doing audits, it was a bit overwhelming for me to simply read the code, without any hesitation. I’ve believed there is some magic pill, system, framework, that would make from me LSR in one month. Unfortunately there is no magic pill, and most of the frameworks fit for the people individually.

However, for the last 12 month i’ve constantly tried to re-adjust my audit approach, to see what work for me best, and i highly encourage you to do the same. See, where do you have the gaps, what can be improved, and once you find what fit you best, you will get your pot.

Today i want to share some tricks that help me to handle audits efficiently.

Initially i thought that the difference exists whether you audit 10k SLOC, or 1k. However, more audits i do, more i come up with conclusion that you need to divide the system into peaces.

You need to learn how to divide the system into the peaces efficiently.

Here i would like to give some information, that would help you to build your personal approach towards audits.

1. Enter the codebase immediately and start to read it. Docs comes later. Don’t start from the docs, from my experience it is way better to start read code ASAP

2. Define the entry points of the contract. Is there deposit/withdraw/claim/stake functions? Take a brief look and get a contract superficially, how does it work and who are the key players there?

3. Start to read the code, make @notes/@audit marks. If you don’t understand what some feature does, here you can take a look on the docs, use AI to grasp it fully.

4. After the first set you have some knowledge related to what you audit. Here is the actual game starts. Read the contracts 2-3d time, don’t forget to make @notes/@audit marks

5. Assume couple days have passed and you are sure enough, maybe you even found some findings. But it is not the end, here you need to revisit all your notes and evaluate what is relevant.

6. Here we enter the battlefield of finding solos. Even you are sure enough you audited everything, there are some solo’s left for sure. Right now, divide the protocol into the flows and go into each flow as much as possible (in accordance with time).

   For example i like to use Notion (i know a lot of guys hate it and prefer pure vsCode), but i found out that i need to re-write my way of thinking to prove whether the finding correct or not.

   I divide the protocols into meaningful peaces and make 2 lines. ToDo Findings - is findings that i’ve filtered from my vscode notes and which i plan to include in my PoC. The PoC Findings are the actual brief proof-of-concept (not the final version but the solid proof of bug existence)

By following this simple system i manage to divide the system into meaningful peaces and divide my time accordingly. For example, 1 day for deposit flow, 2 day for claim flow, it depends purely on your confidence. Remember what Zach Obront said

You must be absolutely convinced that there are no bugs left.

Such confidence comes only from the huge amount of work done + experience. But to summarise, your audit approach must be divided into 3 phases:

1. Deep system understanding

2. Audit. Finding bugs.

3. Last round. Drain yourself with ideas.

Last point that i want to mention, that every time you approach you can’t simply plunge into the code, you still need to have some kind of meaningful strategy. Once, i’ve seen the article from the @jonataspvt , can’t exactly find it, but he showed his small strategy towards every audit. I’ve tried to re-write it based on my needs , and right now i try to follow it every time i do audit.